Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

5 Must dos for recovering failed projects


NovopayAs I was writing my last post on Novopay, I was also contemplating how one can rescue such a project. The minister in charge, Stephen Joyce has announced a $5M fund for addressing the issues. How would this work in real life? Reports are rife that the government wanted to get its money back from Talent2. That, along with the fact that relationships are already at breaking point, are not good success factors for the project. So 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 instil on 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 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 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 the project. The current status is a reflection of many decisions taken through the course of it. 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. If the changes do happen, it risks those people losing their authority as they have been “proven” wrong in hindsight. To top manager from the public service, Education Secretary Lesley Longstone has already resigned. If the same has not happened from the supplier Talent2, that needs to happen.

Aim for small wins

In a major failure it may sound couter 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 like Novopay 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 the chance of it all coming crashing down because of weak foundations. Identify how you are looking to improve, set target of small improvements often 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 folds. One of the major reasons projects fail is because communication is poor. Having large teams working on it is therefore more risky than the original projects. 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 based on the additional cost. You may find there is more political will to spend in trying to fix something than re-doing it correctly or abandoning it. Be careful to be seduced by that. It is difficult to contemplate ditching a system like Novopay as that cannot be done without a replacement to pay the teachers. Supermarket chains, farms and IT industry contains a lot of similar requirements with a considerable part time contract staff alongside permanent staff with various levels of skills and entitlements. A fully functional system that does 90% of the requirements may be better than an error prone system designed to deliver all of the requirements.

Have you worked on recovery of a failed project? I will be interested to hear your feedback on Novopay or even failed projects in general.

Related articles

5 responses to “5 Must dos for recovering failed projects

  1. Pingback: 5 things to do when projects go wrong | Project Management in Practice

  2. Javier Geronimo May 24, 2013 at 3:02 am

    I was part of a team that was called in to resuscitate a failed project, two months behind schedule. At the high-level, management provided assurance to the Client the project would be completed, within reason, as close to the original date. At our level, we reviewed the SOW, tech poroposal, and cost proposal. We also interviewed the subcontractor who initially started the job. We felt we could collect historical information that would be uuseful going forward: which we did. We were able to identify the source of the problem. It had to do with a poorly written technical proposal resulting in a poorly written cost proposal. Unfortunately, the Client’s frustration was wrongly aimed at the subcontractor. Regardless, we used his knowledge during the initial stage of resuscitation which was critical to completing the remain deliverables. Winning over the stakeholders confidence was critical to a harmonious work environment. Though the project went in to a cost overrun and the project completed just a few weeks past the original delivery date, the company saved face and the Client was appreciative of our commitment to providing a quality product.
    A side note: This project was or still is used as a scenario for new hires to discuss on what they would do. completing the remain deliverables.

  3. Pingback: How do I make decisions under pressure? | Project Management in Practice

  4. Pingback: When Project Managers can be dangerous | Project Management in Practice

  5. Pingback: What the Americas Cup teaches us about management | Project Management in Practice

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: