Can't resist re-posting this recent blog post from another Project Manager (with some edits by me), as it more or less reflects my own thoughts on the subject. I have given his name in the title and the link to the original blog post at the bottom of the page. I hope these would be enough by way of acknowledgement
How can one rescue a failed project? What are some of the things that need to happen before you can achieve any improvement?
Acknowledge the failings
When doctors treat patients with substance abuse, the first thing they try to instill in the patients is the acknowledgement that a problem exists. The environment around failed IT projects is exactly the same. It lurches from one problem to another while trying to apply band aids to keep things going. Until parties are willing to admit that problems exist, there is no hope for a resolution. If you keep doing the same things, there is no chance of the result being any different than what it is today. It is very likely that some within the project saw the train wreck coming and may even have voiced it. Seek those out to understand what went wrong.
Divorce emotional investments
One of the basic practices of IT is that software developers do not test their own code. It is not because they are not capable. In fact, they should be more capable than anyone else. However, as human beings we are predisposed to not finding holes in our creation. Same is true for the management of a project. The current status is a reflection of many decisions taken through the course of the project. Many in the management will feel the decisions were correct at the time with the information they had at hand. You need to remove the management decision makers from both the supplier and customer to ensure progress. Leaving them intact will risk required changes not happening
Aim for small wins
In a major failure it may sound counter intuitive to look for small wins, as the problem is a sizeable one. Most adults are reasonably sensible and not easily taken in by bulls**t. They are well aware that a major failure is not going to be resolved quickly. What you need to achieve at all costs is some confidence among your user base that improvements are underway and they can see a light at the end of the tunnel. Bigger your ambition is, more balls are in the air and higher is the chance of it all coming crashing down because of weak foundations. Identify how you are looking to improve, set target of small improvements and communicate honestly.
Throwing more resources is not always the answer
As Fred Brooks Jr has pointed out, the most reliable software is written by one or two man bands. The need for quicker output requires many more developers and as a result introduces complexities several fold. One of the major reasons projects fail is because communication is poor. Having large teams working on the recovery attempt is therefore more risky than the original project. It is a common tendency in projects to throw more resources at a problem. That is just about the worst things you can do in a failed project. With smaller wins, go for smaller teams.
Be prepared to abandon the project
For all the best will in the world, sometimes you will not be able to retrieve failed projects. Cost of retrieval may be higher than doing another project from scratch. It also may not give you the benefits you were after because of the additional cost. You may find that there is more political will to spend in trying to fix something than re-doing it correctly or abandoning it. Be careful not to be seduced by that. A fully functional replacement system that does 90% of the requirements may be better than an error prone system designed to deliver all of the requirements.
Link:
