As-is Analysis: Why Bother?

There’s been an ongoing debate on the usefulness (or otherwise) of current state or as-is analysis. I would say there’s no one-size-fits-all answer to this question. It depends. 

I once worked on a project where as-is analysis was skipped. We skipped it because the current processes were extremely flawed and there seemed to be no value in wasting time trying to understand the flawed processes. I should, however, mention that with this project, there was a time constraint and there was also a member of the team who knew the way things worked back to back. This team member was key to answering most of our questions and participated actively in the design of the new system. 

For most process and business improvement efforts, I believe it’s necessary to take some time to understand how things work. As-is analysis is particularly useful in cases where:

1) The team members are in a new domain and do not have a complete picture of how things work

As an analyst in a new domain, it’s important to understand the industry jargon, business peculiarities and the culture of the people you’re dealing with. Without this understanding, the project is in danger. 

Let’s imagine you’re visiting a city for the first time - how do you know if the quickest way to get to your destination is by bus, train or simply walking? By taking a look at where you are on the map (as-is analysis).

It’s like knowing you have a problem (where you are), knowing where you want to go (to-be) but not understanding the most efficient way to get there – knowledge that as-is analysis could easily provide.

2) Too many mistakes have been made in the past and you would like to correct those mistakes or avoid them in the future. 

Have you ever heard the phrase, “I’ll know what I want when I see it”? Knowing what you don’t want in many cases, can help you eliminate options as early as possible. Understanding past mistakes empowers the BA to proffer workable solutions, instead of making blind recommendations, which barely scratch the surface of the problem.

In understanding the current state, there are some specific areas the analyst should focus on:

Business Processes: What business processes currently exist in the domain? Examining the current process provides insights into current roles, activities, triggers and paths. In studying the existing process, you’re looking at removing unnecessary activities and approvals to improve the future state. Understanding the number of processes that are interrelated will ensure that an “end-to-end” solution is achieved. Understanding what activities or roles are necessary will also help to frame the design of the to-be.

Business Rules: What are the business rules under which the company operates? As-is analysis helps to understand the business rules, opportunities for exceptions and possibly, update the rules that are out-of-date so that everyone is on the same page.

User Requirements: In understanding the current state (by an analysis of existing software/documents) or asking questions, requirements are bound to surface. A deep understanding of the current state can help the business analyst come up with additional requirements and their acceptance criteria.

Problems: What problem are you trying to solve? It’s important to understand exactly what the problems are so that you don’t underestimate their gravity or worse still, proffer solutions that don’t address the core problem. What do I mean? A project may be initiated with the preconception that the existing system is faulty. What if you plunge headlong into the project, introduce a “better” system and the desired outcome is still not achieved? Not all problems can be solved with technology; some problems stem from the prevalent organizational culture or attitude, inadequate worker skill levels and as such, introducing a different technology or software will not make these problems go away. Having a deep understanding of what the problems are will also prevent wastage of resources.

So, why bother with current state analysis?

• It provides a starting point/baseline for improvement. You won’t be adding much value if you came up with a “solution” exactly like the previous.
•  As-is analysis provides insight into the scope of the problem by helping to identify gaps and processes that require further analysis. It’s important for conducting gap analysis and helps the analyst understand the impact of making changes to certain processes, projects, stakeholders and systems (Impact analysis).
• As-is analysis identifies process/system elements that can be reused.
• It provides insight into the scale of the project. For example, the number of users, stakeholders and systems that will be affected.

Despite the usefulness of as-is analysis, some believe that there’s no real need for it because it limits the analyst’s creativity in offering solutions. This is similar, in a sense, to the argument against prototyping. Another reason some companies kick against it is because information on “best practices” are widely available thereby reducing the need to analyze the opposite.

If you do decide to devote some time to as-is analysis, it’s important not to spend an excessive amount of time on it – make it quick and don’t get lost in the information you obtain. You do not need to make a project phase out of it. For instance, conducting as-is analysis can be as simple as perusing documents on the current state of business processes in your spare time. 

Don't forget to leave your comments below.