There are countless reasons why project fail, which you’ll doubtless be able to Google if you haven’t experienced them for yourself already. Poor requirements definition, lack of leadership, weak controls, over-ambition and poor communication are among the reasons cited. But the real reason that many projects fail is because they are projects.

They fail because they’re difficult; that’s why they’re projects.

You don’t create a project for things that you know are easy. Maybe if you started creating projects for each person to start-up their PC each morning, you’d have some impressive project KPIs… This isn’t about being flippant, however, it’s about setting expectations. You run projects to exercise some degree of control so that you understand when something will be delivered, at what cost and who needs to be involved in delivery. Other work can be written off as business as usual, but a project needs its own attention. So you already know that it’s going to be tricky, that you’re not sure how best to address the problem… why then do you think that by putting in some kind of methodology everything would be hunky-dory?

They fail because the controls you have in place tell you they’re failing.

What the methodology does provide you with are the controls to monitor the work you’re doing. You should be able to monitor effort, milestones, risks and then manage these. But more importantly, if things are going wrong, the controls should be telling you sooner rather than later, so you know your project is slipping. With business as usual where the controls don’t exist, you don’t know things are going wrong until it’s too late: for example, you’re losing market share.

So the fact that it’s a project means that it’s more likely to go wrong and it’s more likely to tell you that it’s going wrong. So why are we so surprised when it breaches tolerance?

It’s not about defeatism: we have worked on successful projects. But let’s challenge the expectations before the blame-storming begins. Could we have implemented the system without running a project? Did we get any benefits from running the project at all? What can we learn from this project that went well, that we can implement in future?

To run your projects successfully you need honesty, clarity and experience. The first step is to be honest, clear and experienced enough to recognise that it ain’t easy, and that decent project management will tell us just how tough it is.