A problem defined is a problem half solved
Albert Einstein
Have you ever been in that situation where a colleague has passionately described the perfect technology solution, talking about features, cost estimates, or even a vendor who can deliver? The passion and the vision may have been great, but did anyone ask, “what problem are you trying to solve?” If there is no problem to solve, then there is no reason to invest time in a solution. The authors have seen this often: organizations build solutions for problems that do they do not fully understand.
To understand the challenges to be solved, one needs to understand the existing situation (i.e., current state). Yet, organizations tend to balk at the need for this type of analysis. They assume their understanding is complete (when it is not). Nor do organizations appropriately focus on the context of the situations that drive the need for change. A typical protest is that an organization is implementing a new future state, so there is no need to document the current state. The authors believe current state analysis is indispensable to any effective solution definition. While it may be challenging, it is 100% doable.
Why Assessing Current State is Indispensable
All organizations execute processes. They generate demand, onboard customers, deliver services, and hire new associates. While organizations carry out a multitude of processes over and over, day in and day out, they typically know less than they might think. Processes are often messy. They:
- cross multiple operational functions
- have numerous hand-offs among individuals or teams
- include plentiful, undocumented sub-steps
- do not take full advantage of automation
Dozens or hundreds of stakeholders may participate in a process, but rarely does anyone readily understand a complex process end-to-end. In many cases, the end-to-end process is not documented. Without alignment to what is being done today, it is unlikely that effective process improvement is possible for tomorrow.
A simplistic example on YouTube makes the point about common (mis)understanding of a process. The sandwich example may feel foolish, but it is a useful illustration. Even the most mundane process turns out to have dozens of possible steps. If not documented in plain language, there will be different interpretations. Without clarity of process, then alignment, efficiency, and quality may be elusive.
Not If, but When
For any significant change, current state analysis either happens up front as part of a deliberate plan, or mid-project as unplanned, catch-up work. We prefer up front and planned. Software selection is a favorite example of ours. Choosing a tool does not include any process, right? One just needs to create a list of requirements and interview vendors. However, requirements come from the work we want to do. The work we want to do comes from a future state. The future state is built on analysis of the current state. Even software selection can be improved by current state mapping.
We are familiar with a company that decided to purchase and implement a back-office accounting solution based on assumptions about how customers would be billed. No current or future state process analysis was done. After ten months and half a million in expenses, the team determined that the billing assumptions were wrong, and that the selected software did not meet the company’s needs. But it was too late, and the company was stuck with the purchased software solution. The team ended up taking a Frankenstein approach (heavily customizing the software into doing something it was not intended to do) to meet their need. Not only did this result in a suboptimal solution, but the heavy customization exposed them to a future technical debt risk (see Why is IT so hard post #2).
It’s all about Context
As one dives into problem solving, understanding organizational and operational context is useful. Are there new compliance requirements that must be considered? How does the process align with strategy? Are there external processes that have an impact? What are the needs of the constituents that are not being met today? Processes do not happen in a vacuum. Solutions should not be developed in a void disconnected from operations. For example, we talked to one organization that had planned to refresh desktop phones. Before ordering new devices, the company took time to ask how phones were currently being used. They learned that the desk phone refresh was unnecessary. Context had shifted. Many constituents preferred to route calls to their personal mobile devices. Fully understanding the “Why” helped the organization avoid solving a non-problem.
Taking time to define the organizational context for a change is valuable. It will help to drive a shared understanding, define the voice of the “customer,” call-out strengths, weaknesses, opportunities, and threats; and it can help to set up preliminary solutions. Once this short exercise is complete, effective analysis of the current state is more attainable.
Workshops Not Required
Current State Analysis does not necessarily require weeks of effort. The in-person workshop series certainly has its place – but many current state analysis exercises can be done with much less fanfare. That does not mean the analysis should be done in a cursory or unstructured manner. It just means that many problems are limited in scope, and the effort to define the problem is lower.
But the effort is not zero. Consider the common example of automating a daily data feed from one system to another. Though limited in scope, a Business Analyst would ask many questions. “What fields are extracted from the source system today? How is data quality enforced? How is missing data handled? What time of the day do users need the data loaded into the target system?” And so on.
This interrogation is just current state analysis. For experienced resources following sound methods, this is hours of work (not days). A skilled Business Analyst paired with knowledgeable subject matter experts (whoever executes the current state process) can make great progress in a short amount of time. The result will be a fully defined and documented problem. Everyone will see the same picture. Stakeholders will be smarter. The future state design will be closer to right the first time. The team will avoid frustrating re-work during the technical design and build.
Conclusion
Whether the problem is complex and multi-layered, or quite simple and limited in scope, current state analysis is invaluable. Current State Analysis can be challenging, not because it requires technology skills, but because it requires time and commitment and critical thinking. Current state, even when complex, is knowable. It is a matter of asking the right questions, of the right people, and taking the time to document in a manner that is clearly understandable.
Current state analysis goes best when facilitated by someone with experience, using proven methods and frameworks. But it is not rocket science. Organizations that are serious about building better solutions through better problem definition can develop the capability. As hard as current state analysis might be at times – as one defines the problem at hand – solving undefined problems is impossible. So, keep these seven powerful words handy, and don’t be afraid to use them: “What problem are we trying to solve?” If you do not work to define your current state, you will find that IT is hard.
