Strategies for Success When Failure is Thrust Upon You 

Sometimes you can't avoid it - the project that no-one wants to touch. The majority of project management articles, and checklists (10 Key Project Management Principles. The 50 worst mistakes in project management! And so on and so forth) deal with preventative measures designed to avert problems before a project starts. After all, Sun Tzu reminds us constantly through the writings of management theorists that most battles are lost before they are fought.

However, not every project management engagement begins at the start of a project. Many PMs have had experience of inheriting a project in progress, where the original business case bears no relation to the reality of the current project, the team that specified the system have all moved on, there's no clear owner, and there's no-one really interested in the project other than a department / organisation / senior manager who don't really know what they want, but do want its delivery to be your primary purpose in life.

Essentially you have three choices:


It was while pursuing the last course of action after being assigned what I felt was an irretrievable project early in my career that I heard the words that have stayed with me ever since: reporting what I felt were serious challenges to a project's viability to a very senior manager for whom I had a lot of respect, he listened, looked at me, and said, 'This isn't a democracy. The decision's been taken (it was his boss' project). You need to get on with it.' At least I knew where I was.

How do you get back on track when your project is a train wreck? How do you establish whether the project is worth continuing? How do you retain your sanity when various people, capitalising on the fact that you (probably) don't have an exhaustive knowledge of the intricacies of the project from its inception, doorstep you and demand that their requirements be met as a priority.

The challenge is to hone in on the purpose of the project - strip away the obfuscation, political manoeuvring, and vested interests, and what should remain is the original idea that gave birth to the project that you now own.

There are projects on which the disconnect between the communication about the project's status and the reality of the situation is total:

Incoming PM: 'So the project's on target to meet its milestones?'
Outgoing PM: 'Yes.'
Incoming PM: 'How many users do we have currently?'
Outgoing PM: 'Well, no actual live users.'
Incoming PM: 'Ok, do we have a product: an operational system?'
Outgoing PM: 'Not as such, but the supplier has promised that it'll be functional next week.'
Incoming PM: 'And how long has the situation been like this?'
Outgoing PM: 'Er, nearly three months.'
And so on, and so on.

There are several options when faced with what looks like an impossible scenario. It might be tempting to run and hide in the PRINCE2 templates of risks and issues while the project stagnates around you, but the essential point of project management (and the PRINCE2 framework for that matter) is to keep the good ship Project on course towards its agreed destination while giving the project manager the controls to be able to deal with technical difficulties in the engine room, storms of organisational high pressure forcing you off course, and the occasional iceberg of unnoticed but critical requirements lurking just off the radar.

To eke out the nautical analogy still further: look at the state of your ship and ask yourself the following questions?


Projects invariably pick up baggage and requirements as they go on, and crisis points present the opportunity to assess these in a way that just isn't possible when everything appears to be progressing smoothly. In terms of managing crisis points, the process set out below can be a great help when conducting an emergency evaluation of requirement sets / work packages / deliverables in order to focus on the purpose of the project. It introduces the concept of de-scoping, which can be an effective antidote to scope creep (especially if used in tandem with a tightly-defined specification with delivery-related payment gateways). Essentially it means that if a project component does not contribute to the overall success of the project, it is removed.


De-scoping aspects of a project is like pruning a rose bush - if you don't do it you end up with a straggling plant, covered in weeds that takes up space and resources, which no-one wants in their garden.

In a crisis situation, if you cut the project back to its core, a renewed and vigorous project may grow from the stump, better defined and better equipped to survive. If nothing grows back and no-one minds too much, the project belonged on the compost heap from the outset.

Sometimes it's extremely difficult to de-scope project components on the basis that they're deeply embedded, or are the personal interest of a senior manager, but if you don't mind upsetting the odd apple cart (and if you do mind, you might be in the wrong job), you should be able to reduce the risk and impact to the project, and enhance the likelihood of its success.

Be brave, cut off the dead branches and the sickly offshoots going nowhere, and in a short time your project has the best chance of being in full bloom, and the envy of the garden.

Anthony Lewis is Managing Consultant at end to end consulting, a project management firm specialising in managing and advising on technology-based projects across the private and public sectors.