At times, every technology organization will struggle to define a problem they want to solve. After four years serving in public sector IT and more than 20 spent in private sector IT roles, I can verify this is a common thread across the field.
Organizations waste resources when they resort to initiatives that fail to address a root problem. They end up chasing only symptoms. So many times, I have seen it happen.
Even before problem diagnosis, the most difficult and important step must occur. This initial step is called “problem definition”. As usual, I tend to create a process. The process begins (this should be no surprise to frequent readers) by asking a series of questions to help identify the problem.
The more inclusive a team is in gathering answers from the entire technology organization, the higher their probability of successfully identifying the root problem. The problem definition process also serves to determine the scope of the project which leads to the solution.
It is worth noting, the word “team” can expand to also include external shareholders. Technology gains a level of buy-in from shareholders through organizational inclusion. Shareholders improve our understanding of the problem and eventually serve a role during the project, as the team will utilize those resources in their efforts.
So, what are the questions I would ask? I will use this blog to outline my process. On a side note, this process does not work when your wife wants to remodel the kitchen… It has been tried. This may, however, prove that when defining a problem, emotion and subjectivity should not be part of the process.
Step One: Identify the root problem
Establish a specific need for the team to address:
- To improve service levels?
- To improve customer experience?
- To provide ongoing support for a system?
- To automate workflows? * To meet growing capacity?
- To address the high cost of support?
- To increase efficiency and productivity?
The energy put toward defining the problem is the most important factor in finding a suitable solution. With application development projects, for example, the amount of effort put into defining requirements is directly related to the customer’s satisfaction level with the resulting application.
Too often technology teams speed toward the perceived solution because they mistakenly believe there is not enough time to accurately define the problem. I did this when I started programming in college. My first step was to write the program, then I created the flowchart, only to find out I would have had a much easier time if I had started by following all the steps that come before writing the program.
Step 2: Assess the Problem
In the common thread I notice, an IT team starts a project without initially gathering the baseline data. Do they even know the specific problem that needs to be addressed? Logically, I would continue my process, asking questions to help the team gather meaningful data.
- How do we measure the benefit of the resolution?
- Do we have a data reporting plan in place to ensure accurate standard and ad-hoc reporting?
- Can we leverage existing technologies by inserting essential new technologies into the overall architecture?
- How will the new solution affect existing technologies and processes?
- Are we focused on the heart of the problem, and not simply the solution?
- Have we examined current and future processes and procedures?
- Have others tried a similar solution in the past? If so, have we researched these solutions?
- Can we improve the desired solution if we consolidate and connect services to reduce the number of redundant infrastructure/database services?
By assessing the problem upfront, once the project is complete, the team should have an accurate set of criteria on hand to judge if the resolution was successful. My team is painfully aware, I like to measure and collect data out of sheer curiosity. Sometimes it spotlights what we are doing well and other times what we need to improve. Both are worth the time and effort because it helps us meet the goal of creating value for our customers.
Step 3: Envision a Roadmap
A roadmap should include a comprehensive view of the strategy with input from stakeholders. At a high level, break up the path into logical, achievable, benefit-driven time-boxed goals.
- Convey a purpose, vision, and strategy
- Take a holistic approach to ensure no harm to other existing solutions
- Create a plan that identifies existing processes with gap analysis
- Engage stakeholders
- Create alignment across all functional teams
- Prioritize the largest pain-points
- Assign a timeline
The roadmap informs stakeholders of the technical approach, gap analysis, and workflow sequences. Some stakeholders may communicate data and reporting requirements, or integration needs within the IT agency and other agencies. Once an agreement is reached by the affected groups, move to the next level of detail. Hint: This step should include a detailed communication plan.
Step 4: Establish a team
This entire process is dependent upon the formation of an effective team. An effective team represents each area that is affected by the problem and each team member fully understands the project direction and goals.
Central to an effective team is having the right project manager. A project manager is someone who can articulate what needs to be done and who works to gain acceptance from the key stakeholders throughout the project. The project manager must be the single source of truth and transparency to stakeholders, and they must have the trust and confidence of the project governance board.
Step 5: Execute the plan
Realize this: No project can be effective without a thorough understanding of the problem. Proper analysis of the possible go-forward strategies, thorough process assessment, and a detailed roadmap are essential to developing an effective solution.
As always, I appreciate the efforts you put forth every day to provide the highest level of quality service to our customers.
Ed