Pace vs Haste - Finding the right pace for change initiatives

Some years ago a friend drew me a picture of the life of a project. Many of the things he illustrated resonated loudly, especially as a way of illustrating what not to do. I have used this diagram a number of times since and thought I would share it here now.

I will be interested to know if it makes sense to my readers.

We start with two components of the diagram. The first illustrates the relationship between the level of unknowns and therefore risk to the successful completion of the project and the effort put into resolving them. By effort I am talking about the real thinking, problem solving and decision making needed to illuminate aspects to make them into "knowns", and not just about the number of meetings one attends, reports written or the size of the team assigned to the project. While one has a software bug, its resolution is an unknown and it is a risk. Once you know how to solve it you are almost there and the risk reduced. Once it is solved and proven, then it becomes a "known" and is no longer a risk.

At the beginning of the project we know little or nothing, by definition this is a new endeavour, and we have spent no effort in resolving the unknowns. By the time we reach the end of a successful project we should have put in all the effort we need to and have no "unknowns".

This is illustrated in a pair of stacked graphs like so

The horizontal scale is clearly time and this now allows us to track progress. Broadly speaking the more of the right effort put in the fewer the remaining unknowns and the less risk.

Now lets illustrate a project. This is slightly simplistic, but is effective and shows five phases,

• Initiation - ie agreement of the business case, planning, resource acquisition, etc.
• Design - ie working out what the solution needs to be and how it will work
• Build - ie producing everything that is needed to execute the design
• Test - ie check that it all works as it should, alone, together and with the rest of the world
• Implement - ie make it live and part of business as usual going forward

Of course many project plans look more complex than this, but this is a generalised view and works for this illustration.

The duration of each phase will differ for each project, but I assure you that every project will need to go through each, however briefly. For this article and at this stage of the argument each phase has the same duration so please bear with me.

Now in an ideal world some effort will go into resolving items during initiation, at least enough to develop a fair plan of action. A lot more into the design work with more being resolved during the building phase. This would mean that there would be relatively little in the way of issues and rework to come out of testing and virtually nothing during implementation. By implementation pretty much everything is running sweetly.

In this case the graph may look like this

See the two red lines moving in concert from the start to the finish. A good question is how much needs to be known before moving to the next phase. That is really a matter of judgement and experience, but the simple answer is enough to proceed with reasonable confidence. This sets an appropriate pace for the work.

A number of methodologies use formal gateway reviews to control the movement from one phase to the next. This endeavours to capture broad experience, but when poorly applied can in my experience add inappropriate and unnecessary rigour and actually detract from the endeavour.

This is something of an ideal illustration. In the real world there are often two compounding issues that impact matters. The first is the push for early action. While it is good to build an early momentum, this is often translated into "ticking things off quickly" and thereby rushing the early stages ie haste.

In the model that looks like this

Too little preparation and a poor and incomplete design are the usual manifestions. This means that most of the effort to resolve the unknowns takes place in extended build and test phases. This can be painful for the project teams and frustrating for the business as it sees early "advances" eroded by delays and rework. This erodes confidence.

With strong management and hard work the experience of implementation could be largely unchanged, but in practice implementation suffers as well. This is especially true when the second item kicks in and that is the lack of real management effort to resolve items early. This can be delayed decisions, a bravado to just carry on an hope it will come out in the wash so to speak, or indeed a just a lack of focus from key people.

This means that unknowns are resolved later in the process and the model looks like this and places the majority of the discovery and thus the project pain in implementation.

I wonder how much of this resonates with the reader. For many of the people I have used this with (usually interactively with a whiteboard) it has been something of an "Aha" moment. They start seeing the cause of the discomfort they have experienced and maybe contributed to.

The best way to resolve this is to utilise the experience of change professionals. By all means push them and challenge them, but be aware that a) there are lines beyond which the matters start deteriorating and b) that everyone has a part to play, even if it is about putting in the right effort at the right time.

Trying to rush the early, foundation phases is rarely a good thing.

Keep a good pace, show progress and exercise good judgement, while avoiding haste. The irony is that in the project of the model each scenario starts in the same place and ends in the same place, but the journey is very different and can be painful.

As a sponsor or project manager, to a large extent the choice is yours!