Assurance up, project failure down

You never have to look too hard or wait too long for a project failure although a definition of project failure is surprisingly tricky to pin down. That should not surprise anyone given that if you look hard enough, you can find quite a bit of controversy on what a project is¹.

I’m at the more pragmatic end of the scale – in order to have the biggest successes, you need to fail every now and again. It simply is not economic to do so much diligence that project success is all but a formality. The juice is simply not worth the squeeze.

Looked at this way, a failing project can be more usefully framed as a project which moves beyond authorised assurance or risk boundaries. A failed project is one that stays there. I appreciate that conceptually, this could result in a project which far exceeds its stated objectives being labelled a failed project. This really is more of a conceptual issue than a real world problem.

In my experience project assurance is notably undernourished in most delivery settings. Undoubtedly too, some projects go to great lengths to avoid anything that even resembles assurance.

The model below illustrates what I feel is the significance of project assurance. In fairness, there is no evidence whatsoever to support the figures. That said – can anyone assert the figures are wrong? In the words of the British statistician, George Box “All models are wrong, some are useful”.

It needn’t be difficult though. The APM has developed a toolkit[1] for assuring projects and it’s as good a place to start as any.

Do tool-kits (like the APM’s) help? They could and they should, but they don’t. Whatever has been published previously didn’t accomplish all that much in any event. One reason for this is the inevitable asymmetry between those that would benefit from project assurance, those who are actually in a position to provide it and the respective interests of both.

The project plan is almost never used to track or assure project progress. Historic information is often removed and the Gantt chart itself is miserably unfit for the task.

But it doesn’t have to be this way. A little project assurance goes a very long way in deterring project failure and may be all you need to prevent project catastrophe.

Project assurance needs to be embedded within project plans so that they become a singular entity. To unify the plan itself with the data required to provide confidence that the plan is achievable (or better still, being achieved).

Maybe I should add here that project assurance is worthless without the appropriate governance arrangements to stop underperforming projects before they can do real harm.

Elsewhere, I have written about project failure and the Gantt chart’s shortcomings. I’ve also offered a view here that there are dusty corners of the project management domain which simply don’t innovate usefully.

There’s a theme here and it goes right to the heart of Omnivisto’s purpose, vision and mission.

Omnivisto believes in project plans that are intuitive, compelling and engaging. Omnivisto believes than any plan must be optimised for mobility. The smart phone and tablet are where plans are needed most and where they can do the most good. Plans must support the information needs of all stakeholders, prioritizing information and insight over detail and data. Assurance and governance must be baked in.

If a plan isn’t all of these things, why bother? Assurance up, project failure down. It really is that simple.

Barnaby Davies is a project and programme management professional. Omnivisto is a company with a bright vision for how portfolios and programmes can be tracked, managed and delivered.          

[1] https://www.pmi.org/learning/library/conflicting-project-notions-12010

[2] https://www.apm.org.uk/media/35530/assurance-toolkit-final-v2.pdf