Why Bother With Current State?
Recently I found myself walking some senior managers through a requirements document I had prepared when one surprised me with a question I did not expect.
They wanted to know why there was so much of the document devoted to describing the current state and the various challenges and deficiencies the organization faces in the relevant process. It’s a fair question, but after a decade of business analyst work, I had started to take the importance of detailed current state documentation for granted.
So why bother with current state?
For one, current state documentation is how we demonstrate to our stakeholders that we’ve been paying attention and that we understand what they’ve been telling us. This helps to build relationships with stakeholders, but more importantly, it keeps us honest. It’s an opportunity for our stakeholders to audit our knowledge of their challenges. If we aren’t working from an accurate understanding of what the problems actually are, what are the odds that our requirements will drive us towards a solution that addresses the underlying issues rather than a symptom? I always challenge the business analysts that report to me to explain the problem before they start talking to me about their requirements for precisely this reason.
It’s also necessary background for our solution providers. Let’s envision two distinct scenarios.
If we’re working with software developers to implement a change request or enhancement to an enterprise system and we give them a laundry list of “the solution must” statements, the few that can stay awake all the way through a requirements review are not going to be able to provide any special insight.
They may still develop a fully compliant solution, and if your requirements are darn near perfect, you might even deliver a solution that passes user acceptance testing on the first try. But I wouldn’t be optimistic.
Imagine instead a requirements review meeting that begins with a detailed explanation of what a day in the life looks like for the person we’re developing this solution for, where we focus on the challenges this enhancement or change is meant to address. Then we start talking about the functional requirements, and our developers are engaged and using their own reasoning and logic to see how these requirements relate back to the problem.
It’s been my consistent experience that the vast majority of software developers find this to be far more exciting, and that only makes life easier for everyone. This is especially valuable if you’re working with folks on an internal team that you’re going to continue to work with again and again on future projects. I think you’ll find this often leads to some great suggestions that you wouldn’t otherwise benefit from, too.
Alternatively, if we’re going to be bringing in consultants to assist in selection or implementation, whether hardware or software, the need for current state documentation is even greater.
Without detailed current state documentation, how are we going to bring the outsiders up to speed? It’s faster and more accurate to work from a well written, edited piece of documentation that already contains all of the relevant and applicable flow charts rather than trying to explain the background as you walk through the requirements. It’s especially nice if you can provide the documentation in advance and they can come in with the gears turning and their questions ready on Monday morning.
When we’re working with external solutions providers, we also may not have the opportunity to “fix it in testing” (not that should we be relying on that). This is especially true if we’re selecting or implementing hardware solutions.
For example, you might provide a great set of requirements that allows the vendor to suggest a wonderful touchscreen computer… that you then go to implement in a manufacturing environment where the employees must wear protective gloves that render the touchscreens inoperable. If only you had explained who was going to be using the computers and what for, the vendor might have known from experience to ask the right questions and may have suggested alternatives or at least provided you with the foreknowledge to order compatible gloves.
It also always takes longer to re-explain misinterpreted requirements than it does to start off by explaining what’s happening in the first place. No matter how great your requirements are, they’re always going to be subject to interpretation, and nothing helps to ensure the intended reading better than a shared understanding going in. This is true regardless of who you’re working with to arrive at a solution, but if you’re working with external consultants or developers, it becomes that much more expensive to spend time going back-and-forth. Later on when it’s time to explain why the project ran over budget, it’s going to be bewildering to a stakeholder who is familiar with the current state as to what was so confusing about the requirements. This reflects poorly on all involved, and unnecessarily so.
So, why bother with current state? Because it will help you get to a better solution, with less effort, less re-work, less expense, and provide an all-around better experience for everyone from the stakeholders to the solution providers.