5 Common Pitfalls in Current State Analysis

Understanding the current state is arguably the biggest step for a Business Analyst or Product Owner on a new project to take.

Projects, processes, and systems have a rich history that is typically complex. The larger the organization, the more complexity that is in play. User perceptions, stakeholder expectations, the political landscape and many other factors help or hinder the ability of the Business Analyst to acquire an understanding of the current state.

1. We’re Wasting Time – Skip Current State Analysis Entirely

Understanding the current state is a major step in many projects. In today’s fast-paced environments, it is quite common to skip current state analysis completely or simply brushing over it with the justification of starting the project faster and current state analysis is a time waster or not needed. Fully avoiding current state analysis can lead to some interesting results in the project not solving the core problems and merely adding functionality on top of a weak foundation.

It’s hard to figure out where you are going unless you know where you are starting.

It is quite common in the Agile world that the Product Owner or Business Analyst has a complete understanding of the systems, processes, and environments of an organization. Most organizations have a wide variety of systems and processes that span many different teams within the organization. Taking the time to allow the Product Owner or Business Analyst to perform a current state analysis is essential to keeping a sprint moving forward quickly. Lack of current state analysis becomes immediately apparent during the user acceptance of a product at the end of the sprint. The lack of understanding of the current state causes the business solution not to work or address current business issues.

Organizational Readiness or Organizational Change Management are at a disadvantage. Not being able to acknowledge and articulate the need or “Why are we changing?” questions lead teams within organizations to not accept the change quickly. Acknowledgment of current issues and concerns is a good step in starting the Organizational Change Management and Communication strategy for the project. Without current state analysis, it is difficult for the Business Analyst or Project Owner to put together the Organizational Change Management and Communication Plan needed to propel the business solution forward quickly into the organization (think in terms of business solution adoption).

2. Uncontrolled Venting of Current State Issues

Like the roof on your house, we all need to vent. Venting can be a negative experience, or it can be turned into something positive. Holding feedback sessions with stakeholders, business partners, and customers can give you valuable feedback on the current state. Collecting this information will allow the Product Owner or Business Analyst the ability to see patterns or common themes of issues. Holding on of these meetings is tough. It’s human nature to jump to conclusions and offer solutions. The purpose of this type of meeting is to vent or explain what is currently happening. It’s not about pointing fingers, blame-storming, or finding fault. Set these expectations right at the start of the feedback meeting. Be sure all attendees understand the purpose of the meeting and that it is not for finding solutions.

Facilitation of these types of meetings is difficult. Individuals can feel attacked or blamed in these meetings, so it is important to create a safe environment to collect the current state issues safely. A good technique is to create a board where individuals can write their current issues on post-it notes and past them on the board. Let everyone know it’s okay to duplicate issues or concerns. This event is a listening meeting. Once the list of current issues is obtained, send it out to the group for them to review it. Others may chime in after the meeting with issues.

A distinct problem with a listening meeting or feedback meeting is over complaining and not being able to move past all the complaining or a single issue. The Post-It note technique above will help, but as a facilitator of this meeting, you will need to be on the lookout for an entire group of individuals being unable to move forward to other issues. To move forward through this roadblock, acknowledge the issue has been captured and that future analysis on the issue may be required. Follow up with users to recognize the issue both verbally and in writing. Set their expectations around when a deeper dive will be performed on the issue.

3. It’s Documented This Way, But Nobody Does It That Way

It is quite common for the Business Analyst or Product Owner to encounter the documentation divide when trying to undercover the current state. The divide occurs when the documentation doesn’t reflect the reality of how the users are interacting with the current state. It is not to say that reviewing the documentation is altogether wrong. Observation of stakeholders, sponsors, and users as they interact with a system or process provides in-depth insight into the current state. By observing respectfully and not telling the individual being observed they are doing it wrong, it is possible to see the solution in the real world. Real world systems or processes follow their documentation perfectly as organizations and their environments change rapidly.
Poorly documented systems are on the flip side of this pitfall. Tribal knowledge in utilizing the system rules the day. Observation is a good technique to address this pitfall however in situations where little or no documentation is provided for a system or process, the expectations and understanding of the user, stakeholder or customer can vary significantly. A context diagram or high-level diagram of the current state solution is highly recommended in this situation to ensure the user, stakeholder and customer all view the system or processes purpose in the same way. A lack of common understanding of the current state within the organization will make future efforts to improve it tough.

4. Upstream and Downstream – Not Understanding Integrations

Most systems integrate with other systems in an organization’s environment. Sometimes they integrate directly as in data is passed from one system to another in an automated way or indirectly by having a user manually take data output from one system, manually adjust it on an Excel spreadsheet and import it into another solution.

It is important that the Business Analyst or Product Owner understand the integration points that are direct and indirect so that future changes to the system don’t break current systems that are feeding or are supplied by the current state.

Direct and automated data feeds are typically the easiest to uncover. Middleware, file transport or come another method will have a support system in place and an operations team or individual. The Business Analyst and Product Owner should be able to use the context diagram technique or data flow technique to uncover data inputs and outputs. System architecture or development teams usually have this information on hand for disaster recovery and day to day support.

Indirect integrations are tricky to uncover because they are done manually by one or two individuals without documentation or awareness from others that utilize the system. Often the pitfall is thinking that the integration is automatic only to discover it is performed manually by a user. Other indirect integrations are performed on the down low as a way of moving data to different systems. Interface diagrams and process flows can uncover some of these indirect integrations. Reviewing the reporting or files that are created as output from a system is also helpful in locating indirect integrations. Creating an inventory of all reports and data feeds is a good technique to figure out where data is flowing out of the system.

5. We Don’t Have Issues – You Just Need More Training

Denial of issues occurs quite frequently. The issue becomes the elephant in the room that no one will talk about or look at for fear of the difficulty in solving the issue.

These types of elephant issues are typically created by a lack of funding to resolve them, a refusal to address the issues because they are too costly, or a desire not to look bad. Denial can hold back a Business Analysts or Product Owners understanding of the current state significantly, and it is difficult to break denial quickly.

Acknowledgment of the issue or the elephant in the room is the first step to trying to understand the issue. Clearly stating the elephant issue exists is quite effective even when the politics of your organization would prefer you not say anything about it. Knowing the size and dimensions of the elephant issue will ensure the future business solution will be designed in a way not to repeat the mistakes of the past or to recreate the elephant.

We have all encountered the “If you just read the instructions there wouldn’t be any problems” statement. It’s typically followed by, “We just need to train users more.”

Both of these pitfalls can be addressed by taking the existing documentation, going to observe end users, and noting where in the documentation the user is not following the documentation. Gently ask users non-confrontationally why they are doing it differently. “I am curious as to why you did it that way” approach is best.

Asking the question, “Why didn’t you do it the way the document said?” can be more confrontational and produce an adverse effect. Business Analysts and Product Owners will need to thoughtfully observe and challenge to gain deeper insight into the rationale for deviating from the documented process.

Many Pitfalls

There are many pitfalls in establishing an understanding of the current state. These are the top 5 pitfalls typically encountered, but they can vary widely on a project to project basis. As tempting as it may be, skipping current state analysis produces issues later when designing and proposing a business solution. Even in cases where a solid understanding of the current state can be assumed, Business Analysts and Product Owners assumptions should always be verified. What’s your current state?