Taking on Current State Analysis
Business Analysts may feel pressured by the organizations in which they work to deliver requirements quicker.
It may be tempting to skip steps in order to deliver a product quicker, however Current State Analysis should never be skipped.
Current State Analysis is an integral process with which Business Analysts should become intimately familiar. The following cases illustrate the importance of a shared understanding of current state among all stakeholders in a project.
Case #1
Not too long ago, I was pulled into a discussion about a Continuous Improvement item that had been in “In Requirements” status for 3 years without being closed. “I need someone who can do use cases for this,” the Business Systems Analyst told me.
She went on to explain that the Business was having difficulty explaining their requirements to the Developers and the Developers were upset that the business kept changing their requirements. The developers outlined solutions based on the requirements given but the Business never felt satisfied with the solutions. Needless to say the Steering Committee was unhappy with the entire situation and was pushing to get answers about whether or not this was even a viable ticket. I brought out a use case template that I had used in the past and quickly discovered that there was not enough information to allow me to understand why the solutions kept failing to meet the user needs.
I started doing interviews so that I could understand the current workflow that was causing distress to the end user.
Case #2
Another time, a Continuous Improvement Item was handed off to me. The structure of the company was arranged in such a way that the development team was aware of continuous improvement items before a BA was involved. Often the developers had a solution in mind prior to requirements being written, this time included. Because of unfamiliarity with the exact process that was being modified, I indicated that I needed to understand current state prior to writing requirements.
“Everyone knows current state,” he replied. “The system isn’t working for this process. It’s right there.”
I stuck my ground. “Give me until tomorrow to get current state outlined” I pleaded. He reluctantly agreed and left me in a room with a whiteboard and a junior developer.
Case #3
There was an instance where I had spent hours interviewing stakeholders about how the integration was supposed to work. I understood the business need clearly. The information is needed to be fed into one system so that it could narrow down choices based on criteria set up on the back end of another system. I diligently documented the process in each system and discovered that changing one piece of information would cause the whole structure to collapse. I raised the risk. The team responsible for the transition told me that these weren’t risks. What had I missed?
In a world where systems evolve quickly and companies transition from Waterfall to Agile methods of project management, one thing that doesn’t change is the need for a shared understanding of the Business Problem., In the cases I illustrated, it was through Current State Analysis that the true requirements were discovered
In the first case, I created a non-traditional system diagram to show how the user input triggers combined with system functionality led to undesirable results because the developers and the end user had a different understanding of a single word. The developer used the word to define a Process (verb) while the end user saw it as an Object (noun).
The original requirements documents did not point out this difference or the relationship between them.
Outlining the current state allowed us the opportunity to redefine the ask and stop playing the blame game. The development team finally understood why they felt like the user kept changing requirements and the user finally understood why the development team couldn’t give them a solution.
Oftentimes in Business Analysis the old adage holds true that“ A picture is worth a thousand words.” A current state diagram does not have to be fancy. My simple method is to keep a notebook next to my desk where I draw sloppy pictures that help me articulate what I am seeing. When a Waterfall Project requires it, I translate my scribbles into a Visio diagram that can be added to the ticket or the Requirements Package. In a more Agile approach, my simple sketch may be enough to move us from point A to point B.
In the second case, the junior developer and I walked through the system and the code together to understand where the change needed to be made and why. We called a meeting to walk through the current state with all stakeholders in the room.
As we walked through the system and explained what the system was doing at each step, it turned out that not everyone did understand current state.
Because the developer and I had worked through what the system was doing and why together, we were able to move to a mutually acceptable solution more quickly.
In the third case, I had not walked through current state of the full process. My logic kept failing because of one missed piece in a system that I did not have access to, instead of relying on other people to tell me what the system did. After weeks of frustration, I finally had the end user walk me through the entire process from end to end. My mistake was glaring at me. By not having a complete understanding of current state, I could not make any solution work without asking for an unnecessary platform change.
Although often dismissed as “time-consuming” or “obvious”, Current State Analysis creates a shared understanding of the process that is essential to the success of Business Analysis work. Whether it’s formalized in a presentation, written on a cocktail napkin, or communicated in Morse Code Current State Analysis is invaluable to the BA process.