Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
26 January 2010

The blame game

By Andrew Clifford

If everybody does exactly what they are meant to in a project, and delivers on time and to budget, the project is almost certain to fail.

Project failure is endemic in IT. Something like 70% of all IT projects fail, and we constantly ask ourselves why.

A large part of the reason is the inherent complexity of IT projects. The technology itself is hard enough. But we also have to deal with business change, organisational politics, and resourcing the project with suitably skilled staff.

We do what we can to manage this complexity. We employ experienced project managers and designers. We draw up plans. We set objectives and budgets. We monitor and control.

But then I think we make a fatal mistake. We believe the plans.

The plans we have for an IT project are only ever a pale approximation of what we need to do. In all but the simplest of cases, IT projects require a huge exploration of the unknown. The design, the process, the business context, the political landscape, all evolve as the project progresses.

Unfortunately, we seem to be driven to the opposite mindset. As soon as we have the first whiff of a plan, it is set in stone. And then, as if suffering from collective insanity, we act as if the project plan is perfect, and the project will only fail when someone makes a mistake.

This is the start of an elaborate blame game.

As soon as there are any problems in the project, or even any positive developments that could take the project forward, then the certainty of the project is threatened. Rather than responding positively, every disruption is seen as a problem. Every problem must have a cause. It must be someone's fault.

But this is such stupid thinking. Projects do not succeed simply when nobody makes a mistake. Projects only succeed when everybody exceeds the requirements of the plan. We need to do more than the defined tasks. We need to change the design time and time again. We need to take on more responsibility. We may even need to take more time and spend more money. We need to avoid laying blame on others, and respect that they too are struggling under difficult conditions to get the project to succeed.

We need people who can work in the demanding, fluid environment of IT projects. Who can work from and contribute to an evolving view of the project, and are not deluded by false certainty. But the culture of blame drives the opposite behaviours. It drives a work-to-rule mentality, where people will not work beyond the plan. It drives dishonesty, where important issues, even positive developments, are hidden. It promotes those who are wiley and thick-skinned and enjoy the blame game, rather than the quietly competent who can make the project truly succeed.

Avoiding a blame culture is the opposite of avoiding blame. We need to realise that we can never be entirely certain, and that a responsive and flexible approach is more valuable than slavishly following the plan.

Next: In praise of HTML

Subscription

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Find out more