Adam Thilthorpe wrote an interesting blog on earlier this month on “What can CIOs do to avoid project failure”.
Focusing on project methodologies, Adam pointed out that there’s no silver bullet to project success but factors such as poor specification and making the wrong choice of project methodology are common contributors to project failure.

Over the years, I have worked on many projects, with a varying range of eventual success.  It seems to me that there are five broad categories of project failure.

Political Failures.  By this, I mean projects done for the wrong motives or where the decision to proceed has been made by the wrong people.  In particular, I always worry about top-down projects that don’t have ultimate end-user buy-in, or set out with incorrect expectations.

If the project strategy supports the customer organisation’s overall goals and strategy, and the project objectives are aligned to deliver the right results and in the right timeframe, then that seems to me to be a good baseline for probable success.

Process Failures.  In this category, I include projects where the primary cause of failure is insufficient planning or lack of clear project accountability.  This can include problems that stem from a weak or insufficient evaluation process.  It’s important to understand and control the process and set a clear decision-making structure from the outset.  Direct board responsibility from the project sponsor is crucial, as is a process to manage the key stakeholders.

Project Design Failures. It’s important to ensure that the right preparation is done before a project starts, for example to define required outputs with certainty (unless the initial decision is to adopt an agile development methodology).  Also, over-ambition – in terms of doing too much at once – seems to me to be a significant cause of potential project failure. 

Development should be prioritised for the average not for the exceptional cases.  It’s important to take time to choose what type of deal or relationship best fits into the customer enterprise’s business strategy and design a project around what it wants to buy, not what a particular service provider wants to sell.  

Project Operational Failures.  Red flags during operations on IT development projects seem to me to be: the slow pace of early specification work; joint development of business requirements and architecture; large waterfall specification projects, making it hard to see problems early enough; and combining multiple and competing suppliers in a single project.  Projects need a clear leader directing the project not merely documenting it.  It’s important to have contingency planning and make proper use of testing.

Supply Management Failures.  Fewer than 30% of outsourcing clients have formal plans for managing the long-term relationships with service providers.  It’s important that customers deal with disputes early and try to ensure continuity of personnel from the pre-project phase into the delivery phase.  Also, it is important to have defined processes for problem escalation, and isolate problems early from business-as-usual.  

Finally, there’s the factor of human nature.  Project teams can “go native” where a gap grows between those within the project and those who own the need that the project is designed to fulfil.  End-users become disenfranchised and their concerns are not understood or addressed.  It’s the Magnus Magnusson factor – i.e. “I’ve started, so I’ll finish”.  Parties to a project should be prepared to recognise problems early, react and adjust or change tack entirely – not just plough on regardless.

Alistair Maughan is a partner and head of Technology Transactions at Morrison & Foerster, an international law firm.  Follow him on twitter at