When Projects Go Wrong
When a project is going wrong it is hard to see if the project can be salvaged or will fail. An intelligent and experienced project manager can see the signs, but that comes with experiencing failed projects and taking stock. Winston Churchill once said ‘Success consists of going from failure to failure without loss of enthusiasm.’ I point this out because all experienced project managers would have had at least one failure in their past and would have learned to see the signs.
I want to share some of the lessons I learned while dealing with a failed project.
Essentially you need to be keep your eyes open, talk to everyone, be brave, take responsibility, review the pluses and negatives, and plan for the possibility of failure.
It is a short list, not complete, but important .
Look for the signs. Often they will not be obvious, they need a bit of drilling down, observing project team members (they could look stressed), delays occurring too soon, or you may sense that something is wrong.
Walk the floor, it is an important activity for a project manager, and when at times like this they need to talk to everyone involved. Good and open communications would have been setup at the beginning of the project (this is a norm) but essential when the project is failing. You need to know everything as you will be explaining to stakeholders why the project has gone wrong, this will be made a lot easier if you have good communications established.
Make the call. This is the time for a project manager to step in and rescueor salvage something from the the project. The ‘can do’ attitude project managers have, they can’t help it as it is an important element of their makeup, can mean they do not believe that this is a project that is doomed. It is a big deal to make that call, the project is failing, but once you know it is you need to be brave and pull the plug.
Do not finger point. ‘Success has many fathers, but failure is an orphan’ This is very true when a project is failing. Often members of the project team scatter for cover, but remember the project manager is the one who called to end it and they will have to assume responsibility and not make excuses.
Review the project, the players, evaluate the good parts. There is a need for a post mortem, you need to know the who, what, when, why and where, this will be an invaluable lesson for you to carry into the future. Salvage the products that are good and usable from the project, it could give some meaning to it, even though the principle objective was not met. You need to review your own performance, be objective, who wasn’t cooperative, for example, did a vendor fail to do their job? Do not forget the politics, a player was not working with the project, this can happen in any organisation and could be the sole reason for the failure.
When planning a project there should be exit points added. The pre-defined checkpoints are a good place and there should be discussions with the stakeholders, this reduces the potential of unpleasant surprises and allows for communication of any dangerous events. When planning have alternatives ready, a project may fail but something good could be made of it. Once in an infrastructure project an escalation in hardware prices meant the capital budget was too low. The solution was to find a supplier of IaaS instead, not the desired result and it fell short of the functionality predicted, but it worked, and actually changed the company’s IT strategy.
I can go on about budget phasing, deep evaluation, audit trails, and so on but for now the above lessons will help with making the correct steps. Take the opportunity to study other failed projects, for example, ICI Quest ERP project in 2002 that ended with ICI selling off the flavouring giant for a fraction of its original value to a competitor a year after the project was started. Even giants get it wrong, not that you should be complacent with that knowledge, the target is always a successful end of the project.
