You can run but you can't hide -- Why we still do as-is analysis

"Do we really need to do as-is analysis?" I seem to hear this more and more often from project sponsors, project managers, or even management consultants. Just recently, for example, I was told by an associate from a Big Four consulting firm that there was no need to document current state as part of a business and IT transformation program on the order of $200 million, with hundreds of participants across the institution.

It always catches me a bit by surprise that this is even a question. From my professional experience, I start from the assumption that as-is analysis is essential, and the more so the bigger the effort. Clearly, however, I need to be able to justify this position better -- here's an attempt.

I'm confident that in any project, solid understanding of the current state will eventually become important. It is a question of when and how, not whether to do as-is analysis. I've seen projects defer this work, but sooner or later it always comes back.

At the latest, as-is analysis will become essential at one of the following points in a typical project. It might be useful to ask, do you think you will need to:

• Propose a business case, problem statement, or value proposition that is compelling because it is well grounded in current issues?
• Choose between alternative solutions by comparing impacts relative to current state?
• Prioritize increments of work (e.g., features in an MVP) based on what work will most address pain points (i.e., provide value) in current state?
• When part of an implementation turns out to be unexpectedly challenging, design a workaround based on current process?
• Validate that the design is still relevant to the organization (including changes that have taken place) and consistent with the business case and priorities?
• Plan change management based on how different users are impacted by changes from current state?
• Prepare to train or support users based on knowing how they will need to work differently compared to current state?

If the team answers yes to any of these -- and I can't imagine a team saying no to all -- then some as-is analysis is going to be needed.

By skipping the opportunity to engage groups of stakeholders in as-is analysis, a project may also miss out on:

• Helping stakeholders get to know and respect each other's concerns so they can collaborate better later
• Helping the project team build shared language and understanding of the business that helps them work together
• Digging into root causes that could significantly change the initial stated project scope

So where does the drive to avoid as-is analysis come from? I think it is based on misunderstandings of current methodologies that may appear not to require as-is analysis. Teams applying these methodologies may even feel pressured by their management to demonstrate that they can work faster by skipping "traditional" analysis work that doesn't appear, in itself, to create value.

Agile: Poorly understood or implemented Agile practices create a lot of misunderstandings. A common one is that business analysis, including as-is analysis, is no longer needed. In mature Agile teams, this work does in fact occur in several places: the Product Owner role brings deep as-is understanding to their prioritization of work for the team; the team does "just in time" as-is analysis to define and execute on user stories; and/or the project team does story mapping (or other up-front planning) that is rooted in understanding current state compared with the proposed functionality. The as-is analysis may be distributed differently, but as always, the more clearly the whole team understands current state, the faster it can work -- and without that, an Agile team is no more likely to create value than any other team.

Lean: Here again the highly iterative approach and the emphasis on always striving toward a future vision can make it look like as-is analysis is not happening. But in practice, every Lean effort I've participated in has started with convening stakeholders to map out their as-is process or value stream and identify pain points or opportunities to eliminate waste. That shared understanding of the as-is helps the team prioritize, work together, and communicate with sponsors going forward. The core Lean principles of Go See, Ask Why, Show Respect reflect this.

Design Thinking: Shifts in terminology can also obscure the real work. Design Thinking emphasizes terms like Empathize, Ideate, and Prototype over fuddy-duddy terms like "analyze" or "document". Now, I accept the spread of Design Thinking as a valid critique of and response to past experience: wherever teams in the past failed to think about and engage their customers, work collaboratively, or tap into people's creativity, that was certainly a mistake. Nevertheless, teams using Design Thinking are definitely doing as-is analysis when they interview people, define personas, identify challenges, and refer to the current state to assess feasibility of ideas.

SaaS: Software as a service products are often marketed with the promise that they deliver "out of the box" business processes that represent best practices and enable an organization to simply adopt higher maturity, more automated processes. This is often paired with a prototyping approach in which stakeholders are asked to give input on working software as a way of skipping formal requirements analysis and documentation. In my experience, this just means the as-is analysis is being shifted around or deferred.

In responding to prototypes, stakeholders are effectively being asked to bring their knowledge of the as-is and do an impact assessment or fit-gap on the fly. If there is not already strong shared understanding of the as-is, the prototyping sessions will raise lots of questions that the project team will then need to follow up on -- again doing as-is analysis, just later. And while prototyping sessions can guide the configuration, the project team still needs to do work such as change management and training that requires a shared baseline understanding of the as-is in order to be able to communicate well with a broad user base.

So the next time a team says they're not planning to do as-is analysis, please dig into what is really meant. Most likely the team has simply adopted another way of naming and doing this work, and it's good to just clarify how the shared understanding of current state will be created and carried forward in that way of working. The team may also be making a sound decision to defer deeper as-is analysis until it is really needed. But in the worst case, the team may think it can skip analysis in a way that will result in taking the project off track, doing expensive rework, or missing opportunities to collaborate.