≡ Menu

Business Change & IT projects often end in embarrassing, costly failure: they don’t need to. Here’s how.

“Insanity: doing the same thing over and over again and expecting different results”. While there’s some dispute over who said it, Benjamin Franklin or Albert Einstein, it seems to ring true.

And it’s just as true in the world of the projects that commercial and public sector organisations undertake to move themselves forward in some way, such as; business change programmes, cost reduction programmes, business process redesign, ERP Enterprise Resource Planning system implementations or complex IT projects.

We tend to go about them in the same way over and over again. We organise and carry out our projects in ways declared “Best Practice”. We train our staff in “Best Practice” methods and the consulting firms we engage, tout their “Best Practice” credentials.

And the results according to sources such as industry analysts, is that 60 to 80% of these projects are doomed to fail. That is, the business benefits expected by the organizations paying for the projects, will not materialize.

My own observation of 30 or so client projects within some of the world’s largest corporations – and not so large private and public sector organisations, is firstly, that the private sector is no more successful than the public sector in this regard, and secondly, the real failure rates are probably higher than the those reported by the analysts. And there is I will suggest, good reason for that disturbing state of affairs.

But first let’s remember what those project failures mean for the organisations involved.

The most obvious is the financial millions in wasted funding. Plus there is the disruption to business, and the time and cost of the ensuing damage limitation and rectification work. Then, there is the human cost in terms of wasted time and talent, the frustrations, the disillusionment with management leadership and consequent distrust of future improvement initiatives.

That’s not to forget the delays and lost opportunities in putting in place the performance improvements, costs reductions or increased competitiveness the organization wanted in the first place.

After declaring that we will “learn the lessons” from these failed projects, the odd thing is, that we then set about the next round using exactly the same “Best Practice” methods as before, but armed with the earnest hope that “this time – for some reason, it will all be different!”

Many authorities on projects and programmes list 10 to 12 factors they say lead to the high failure rates. Their lists range across factors such as: poor project management, lack of senior management support, failure to identify requirements, poor communication, and so on.

Certainly, those factors can be involved and be important. But a conclusion I’ve arrived at is that they are not fundamental to the failures.

We are all guilty
This is where I have to confess to being a sinner myself.  I am by no means an innocent observer. My own rude awakening was as a Project Manager of an ERP system implementation some years ago.

At the time, I happened to read a column in the Computer Weekly newspaper. The columnist pithily asserted “any project manager who refuses to quantify their objectives, is either incompetent, a charlatan or just plain stupid”.

Being a project manager who had not quantified my objectives, I somewhat took exception to this assault upon my affectionately held personal qualities.

‘What could this idiot mean?” I raged. “Why did I need to quantify my objectives? My objective was clear – implement the new system. One or maybe two, new systems. There, quantified! Job done!”

I should have noticed that being enraged meant a nerve had been touched. It took me a few weeks to realize that I was the idiot; not the columnist. The point being made was… why are we as a business, implementing a new system?

What are we trying to achieve? What do we expect to get out of the expense, the technical work, the new ways of working, the staff training, the disruption and all the other paraphernalia of a large system implementation?

Okay, so I’m a slow thinker
After a bit more pondering – which admittedly took me several years, I realized that the whole point… [drum roll]… is, to improve the business; to improve the performance/ capabilities/costs of the business. There is no other purpose.

It’s not about delivering “stuff”; the “stuff” is simply a means to an end. It’s not enough to hope that delivering “stuff” will somehow make the organisation better. It’s about business results. The project objectives are about some form of improved business performance.

Now, that columnist’s point made sense. In fact, it made vital, crucial sense.

The real question was – how much improvement did we expect or want the project to make to the business? From what existing level of performance, to what improved level of performance – and by when was it to be achieved?

Which aspects of performance did we want to improve – and how would we specify, quantify and measure those improvements? What numeric scales of measurement would we use? That gives a level of clarity rarely seen in project objectives.

As the project manager, I could try claiming (as so many project managers do), “my job is to implement the new system. It’s not my job to improve the performance of the business”. But that’s exactly what the business is really paying for. That’s the purpose of the project. This is where we come back to ‘Best Practice’.

Many corporations and organisations internally promote and follow a ‘Best Practice’ approach to business and IT projects. It’s based on what is called a ‘waterfall’ model.

If your organization is mid-to-large sized, it is probable you are following a waterfall model. In the UK, the dominant project management method in the private and public sectors is PRINCE2®. PRINCE2 is based on the waterfall model and is positioned as ‘Best Practice’ by the UK Government Cabinet Office.

The ‘waterfall’ model has a structure in which typically – an idea for a project is proposed, a business case is written to justify funding, and the project planned and structured as a series of stages. Stages such as analysis and design work are planned and carried out, followed by development work and maybe procurement, a pilot implementation and then full implementation. Given the failure rates, it’s tempting to add ‘Post Mortem’ at the end, although that’s not yet an officially recognized stage.

Between the stages – each of which can take several months, there is usually a management review in which managers typically review documents produced by the project team.

It’s called ‘waterfall’ because each stage follows on from the previous, in a step-by-step, linear, downhill manner; water not being noted for naturally travelling back uphill. Eventually, something – some form of deliverable or “stuff” emerges at the end of the process.

Mr Royce tried to warn us
The waterfall model is a conceptually simple and logical process. Unfortunately, in all but the simplest of projects it usually doesn’t work in real life. Mr Winston Royce, credited with originating the waterfall model, did warn about this characteristic; but to no avail.

Real life tends not to cooperate with step-by-step linear processes. It would be like driving from London to Edinburgh and determined to do so in a straight line. Try explaining that to the traffic police!

Real life – including driving from London to Edinburgh and staying on the road, demands sensing and responding to changing circumstances as they happen. It’s a learning process in which we are learning continually in the real world, about what works and what doesn’t; building on what does and correcting what doesn’t.

The management reviews of paperwork in the waterfall model can’t and don’t substitute for validating the project’s basic assumptions and actual effectiveness in the real world.

The waterfall structure is such that the “stuff” being delivered only gets its first exposure to the organisation’s real world realities towards the end of the project – when it’s too late to change course.

On knowing all the answers at the start
It’s also worth recalling that business change and large IT projects in complex organisations are themselves are far too complex for it to be humanly possible to foretell with precision at the start, exactly how the project requirements and the business environment will evolve during the course of the project. Although the waterfall model assumes the exact opposite.

Back to fundamentals
I’m suggesting that rather than the 10 to 12 or so reasons for the distressingly high rate of project failures, there are really two fundamental mistakes, namely:

Mistake 1: we plan to deliver “stuff” rather than quantified levels of business improvement. And we usually compound that basic error by proposing the solution ‘stuff’ before we’ve gained a clear understanding of the real problems or obstacles to performance improvement

And then…

Mistake 2: we follow a ‘waterfall’ project management model which does not provide for testing every few weeks or months that the project is either actually addressing the real problems, or even capable of making business improvement in the real world. We rely instead on untested assumptions and expectations.

 So what can we do?
While there isn’t space in this article to explain all the practical details – that’s for another article, here are the key principles, starting with the launch of a project…

 “Here’s the solution; now, what’s the problem?”
Most organisations decide the favoured solution first, and then set about justifying it.

Instead, let’s ask the critical question “what business improvements do we want to make for our organization?” This means deciding the improvement objectives before deciding what the solution will be.

That’s a key mindset change in itself.

And then further, ask “expressed in terms of numbers, what level of improvement do we need? By how much and by when?”

What would be the minimum acceptable level of improvement? That is, what level of improvement must we attain in order to have succeeded?

What would be the target level? What level above the acceptable minimum, do we plan to achieve?

Now we have a clearer idea of what improvements we want to achieve, we can get a clearer idea of what the obstacles are between where we are, and where we want to be.

We can gather potential ideas (solutions) for achieving the improvement aims, and meaningfully start evaluating those candidates in relation to their costs and their likely benefit contribution to achieving our improvement aims.

It can take some hard thinking to answer those questions. It’s so much easier to think in terms of delivering “stuff” – but as we’ve seen, avoiding the hard questions is costing organisations immensely in financial, business and human terms.

As a test, ask the following question about a proposed or ‘inflight’ project in your own organization. But please do so with caution. The answers will be illuminating but can discomfit those who are wedded to their favourite solutions, and would prefer the question to remain unasked!

The question is: “what performance improvement do we expect this project to make, and by how much (in numbers) do we expect that improvement to be?”

Even if you go no further, simply asking that question, will immediately give you penetrating insights into the rationale of a project, and its likely success. But you can go further.

Designing the project…
Structure the project to deliver – within a few weeks of starting, some useful and real improvements to the business,  and then onwards, in regular delivery cycles of say, every 4 weeks.

Measure how well what was put in place actually worked compared to what you expected, and use what you learn to improve the next delivery cycles to the organization. Rinse and repeat!

That is, structure the project as an iterative process of improvement cycles. Measure the actual improvement made in each cycle, and use that feedback to adjust the next delivery cycles to keep the project on track to delivering the overall needed levels of improvement.  That way you enjoy early business results, and receive early warning of risks, new emerging objectives or faulty expectations before any serious damage or project failure.

And there may be some schooled in ‘Best Practice’ who will protest that it’s not possible to deliver projects this way. The question for them is “are they saying it can’t be done, or are they simply saying they don’t know how?”

Or, we can keep doing the same thing over and over again – and just hope that unlike the last time, this time – for some reason, it will be different!


PS: to help you and your organisation introduce a business improvement-led projects approach – the simplicity of which, I admit took me several years to grasp, there are various explanations of the techniques elsewhere on this site. Or to discuss via email, contact us


{ 0 comments… add one }

Leave a Comment