Skip to main content

Author: Danie van den Berg

Skipping the As Is…?

“You don’t drown by falling in the water; you drown by staying there” – Edwin Louis Cole

The world we live in is speeding-up… How do people in the ‘change business’ who create systems and processes, keep up with these ever and rapidly changing demands? By the time that most teams have created solutions that meet customer requirements and needs, their needs have changed!

As part of traditional SDLC (Software Development Lifecycle) methodologies, conventional analysis wisdom states that when one performs analysis on an environment for purposes of changing it, one always starts with assessing the “As Is” or “Current state”. (Knowing where you come from before you head into the future…). One would then typically perform an analysis of the “To Be” or “Future State” of the environment (this is the desired solution that you would like to have in place). Lastly a gap analysis would be done between the “As Is” & the “To Be” scenarios.

As Is –> To Be –> GAP analysis

This gap analysis would typically be done to assess what can or cannot be re-used from the current environment and therefor you’d know what needs to be created, developed or acquired. Other benefits of understanding the current state, include the identification of current weaknesses and risks, the opportunity to socialise the anticipated change and to prevent the repetition of mistakes.

There are some negatives to this kind of approach…

Firstly, this is typically a time consuming process. Since many organisations do not have their current business and solution processes documented, it is often quite an involved process just to understand the current status quo. Also – the more complicated or older an environment, the more time consuming this exercise typically turns out to be.

Secondly, you could most likely expect to encounter some resistance from current stakeholders. These people might fear that the change will negatively affect them, they might even fear for their jobs. They might therefore not be willing to share information about their current environment willingly. This might skew the true nature and accuracy of the current state.

So when would you skip the “As Is” step?

If you are fairly certain that you are going to re-use your existing processes, the traditional approach described above makes sense, but if you know that you need to start thinking completely new, why not jump straight into the “To-Be/Future State”?
The question to ask here is, if I could have anything (my best case scenario) what would it look like? This is when your thinking needs to be divergent and new.

Benefits of jumping straight into the To Be solution, are:

  • You are not restricted by current process, technology, legacy constraints. Future-state solutions should (in a perfect world) not be limited by your current state limitations.
  • The focus is on the future, not on the present.
  • You are de-linking where you came from, from where you are going. This is beneficial in that you have an opportunity to look at something from a fresh perspective, almost like an entrepreneur would.
  • Since “To Be” scenario thinking is essentially a creative process, the focus is initially not on finding problems, but rather on coming up with creative solutions.

Advertisement

True innovation is not constrained by current thinking. I marvel at some of the innovations coming from Elon Musk companies. His thinking around the concepts for the Hyperloop and the tunnelling traffic decongestion solutions (are certainly not based on current thinking. Maybe “out-of-box” thinking means to completely think in new and transformative ways…i.e. discarding your current thinking.

When asked how he comes up with solutions to problems, Musk talked of using a concept in physics, called the ‘first principle thinking’. He says he uses this instead of ‘reason by analogy’ (by comparing things). First principle thinking is essentially breaking problems down to their basic core/fundamentals and then building solutions around each core problem.

What he describes there, is very different from trying to solve problems with your current solutions. It focuses on the problem first and then seeks to create unique solutions for each problem. It might very well be that in trying to solve each individual or core problem, that we realise that there are solutions available that have been found before (I.e. in which case we can of course re-use the solution so as not to re-invent the wheel) but the point is that you don’t automatically assume that your current solutions will solve future problems.

To assist us in the To Be solution creation, there are a variety of techniques available to us from the world of Business Analysis. These are helpful to facilitate discussions and get helps get the creative juices flowing among those meant to come-up with painting what their future world would look like…

  • Brainstorming – Brainstorming is a technique intended to produce a broad or diverse set of options.
  • Story Boarding – is used to visually and textually detail the sequence of activities by summing up different user interactions with the solution or enterprise.
  • Business Model Canvas – can be used as a diagnostic and planning tool regarding strategy and initiatives. It is comprised of nine building blocks that describe how an organization intends to deliver value.
  • Mind Mapping – Mind mapping is a form of note taking that captures thoughts, ideas, and information in a non-linear diagram.
  • User Stories – User stories capture the needs of a specific stakeholder and enable teams to
    define features of value to a stakeholder using short, simple documentation.

If you have chosen to ‘skip” the As Is step (for the reasons I’ve listed above) and you’ve come-up with a “To Be” solution, you can optionally then look at your current environment from a perspective of possible re-use or synergies… The sequence is the other way around though:

To Be –> As Is –> GAP analysis

Agile methodologies are very nicely aligned to this kind of thinking, where, by shortening the duration or cycle (iteration) of development, teams have a more realistic chance of delivering on something that meets the ever-changing needs of the customer. This also means that the ‘customer’ gets more involved in the analysis/design/development process. Because they are more closely involved, they know sooner if something is not relevant anymore and any throw-away work, is minimised due to earlier identification of outdated thinking…

I recall working on a very large bespoke project, where the decision was to completely do away with the As Is step. It was felt that the current state was so far removed from where the organisation wanted to go and that the time and effort on it, could be better spent on the future of where the organisation wanted to go. By making this bold decision upfront and by committing the right resources and stakeholders from the onset, the project saved a lot of time and money and they were able to engineer a completely new landscape, that were tailor-made around the needs for what was relevant for their immediate future.

So next time before embarking on a very costly and time consuming “As Is” analysis exercise, it might be worth your while to consider the true value of such a decision.

It’s normal that humans generally hesitant to let go of their current way of doing things. It’s a comfort zone thing. We feel safe. Nothing wrong with that!

But sometimes, if one comes to the realisation that the comfort zone becomes a risky or dangerous place, you have to gather up the courage to break free from it.