The Importance Of Knowing Your Current State In Detail

Small wonder that the new name for user testing is “requirements identification”! (heavy dose of irony). 

Before even selecting the solution you need to know your current state in detail. Every variation, exception, once-a-year event and odd-ball circumstance needs to be known and either eliminated or accommodated in your solution. Otherwise, late in the project either the solution has to be changed to accommodate missed requirements, or expensive ongoing workarounds need to be devised and installed for perpetuity to fix 'gaps' that are discovered.

For example, a bank’s expense payment system was defined to level-3. The solution was pre-determined as the incumbent vendor’s software module. Delivery of the project was well underway when a staff member asked, “What now happens to the executive expenses?” Apparently, there was a parallel, hidden process that dealt with the expense claims and queries of the executive team that operated outside of the normal process. This special process had not been picked up at all. In order to process the executive expense claims without changing the process the solution adopted in this case was to keep the old system that was to have been replaced, and put all of the other expense claims through the new system. So the major justification for the new system – to replace an obsolete system – was negated by inadequate requirements gathering.

There are many forces against doing a good job defining the current state.

• Implementers of all types just want to install the solution and change the business to fit it.
• Executive management want to see ‘action’ and don’t want to see time 'wasted on the past’.
• Business analysts find exploring the current state ‘boring’ and ‘unrewarding’ as it is not creative.

These forces need to be resisted as the current state is

• a definition of what happens today, good or bad, every aspect of which needs to be either eliminated or accommodated in the future state
• a definition of how the organization operates today and is, therefore, the starting point for the business change program
• a discovery process as usually no one actually knows how the current processes work in detail across the business – the results are often astounding – “Do we really do this everyday?”

It takes three weeks to define the current state in detail across a whole company. To some this sounds too long and to others too short a time – but this is based on over 20 research and experience.

The best people to define the current state are the people who live and breathe it on a daily basis – the incumbent staff. They need to be taught how to document their current processes, variants, exceptions, odd-ball events, etc., in detail using simple process maps – this training takes half-a-day.

When the staff document their own processes they often see that they are stupid, wasteful, inefficient and cannot wait to improve them. Resistance to change disappears when people see that much of what they have been doing is so worthless.

I remember reviewing a 24-page end-to-end process chart where the next value-adding step to one on page 2 was on page 23! This is what you find – processes that have morphed and mutated with no logic or control to become wasteful, inefficient and, at times, pointless.

Which leads to the other advantage of defining the current state in detail – you can identify each process’s strategic intent.

• What is this process really trying to achieve?
  
• Why do we do it at all?
  
• Why do we do it this way?

These questions allow break throughs that consistently reduce process and operational complexity by over 40% and thereby reduce project cost and complexity by around 20% - before a solution is even on the horizon.

20% less project time, 20% less project cost, 20% less ongoing operating costs — are all potential prizes of detailed current state definition and analysis as well as faster, more effective change implementation.

Before going anywhere near a solution, you need to define your current state to the level where the problems currently are so that you can either eliminate or accommodate them. Ignoring them doesn’t make them go away, they just come back later in the project and increase both project and operational time and cost.

Willcocks and Margetts showed many years ago that 40% of projects fail to deliver any net improvement. All pain and no gain. Failing to define the current state is a major reason why this appalling statistic is still true today.