It goes against the grain for many of us but sometimes its right to give up on a project. The 1994 Standish Group survey report on project success called “Chaos” has been oft quoted as evidence that many projects are unsuccessful. The report noted that somewhere over 80% of projects are either cancelled before completion, do not deliver what was intended or run significant over budget or over schedule.
The report noted that about 30% of projects are cancelled and it had a couple of noted hideous examples. Recently a new survey conducted by CIO Insight magazine asked a series of different questions including whether or not the most recent project that CIO’s considered the most significant was completed successfully or not. Interestingly, over 50% of respondents said that their most significant project of the last 12 months had been successfully completed.
What is left unsaid about both of these reports is the importance of cancelling a project. The examples sighted in the Chaos report point to projects that cost millions of dollars and delivered nothing when cancelled.
There is a time to cancel a project and there are warning signs that it may be time to stop the party.
First of all, as my friend Ian Koenig once said to a group of project managers, “If the horse is dead, dismount.” He’s right. There is no use trying to help a dead horse. Some people will try to change riders or saddles or reorganize the horse. No, if the horse has expired, it’s time to get off. Mostly you’ll know when that is. There can come a point in a high-tech project where you simply know that the perceived benefits simply don’t warrant the expenditure of resources that you’re putting out on it.
‘So, is my horse dead or only lame?’ you ask. If you need some clues, here are a couple of places you can look:
The champions have left. The original sponsors of the project; the people who had the vision that started the ball rolling have moved on for whatever reason. The new sponsors have inherited this project but without the same fervour as their predecessors. It’s time to have a serious sit-down with the new sponsors and determine if they’re truly committed to what you’re in the middle of building.
Costs and Schedule are out of control. The defence industry has a great standard for dealing with variances on projects. It’s worthwhile sharing with everyone. The idea is that on a regular basis (perhaps monthly on a major project, or weekly on a shorter one) any work packages, which are way off their original plans, must be dealt with. A “get-right” plan must be implemented which shows how the project will get back on track or a change in the original schedule must be accepted that includes the impact of the changes in schedule. There should be less than a dozen of these to deal with at a time or the time required to resolve each variance exceeds the time until the next review. If you have a project which is going later and later and later or costing more and more and more, then you’ve added an element of risk that you might not be able to handle. It’s time to sit down with the project plan, scope out the real work remaining and see if you should continue or give it up.
Risks increase. If you are using risk management software, then this might be apparent in the reports you produce. For the rest of us, you’ve got to look to more physical signs of risk. Changes in personnel for example, can kill a high tech project. Any changes in the physical development environment such as personnel, management, budget or changes in the original plan such as a major scope change – perhaps because of technology is worth pausing to consider. Scope can sometimes change because more people get involved than were there at the start. Design by committee is not uncommon but it carries the potential to add risk to the project as everyone on the committee lobbies for their own pet functionality. If the project has now become much more complicated because of the increase in risk, it may no longer warrant doing.
The world has moved on. Some projects simply can’t keep up with technology. It sounded great when you started but technology is no longer where you were when you did the original design. This can result from updates in hardware, in software, in competitive products, in market perception of what it is you’re doing. You might have created a nuclear mousetrap but if it doesn’t have a web interface, you probably can’t sell it at the moment. If technology or market demand has headed out beyond your ability to keep up, then you’ve got to consider putting the project on the shelf.
There seems to be a big stigma about cancelling a project. The Standish Group considered cancelled projects to have failed. I’m not so sure that’s the right assessment. In some industries, say pharmaceuticals, it’s considered quite appropriate to cancel R&D projects, which are not expected to bear fruit. It’s not a problem, just considered a characteristic of the industry.
In a high-tech field, perhaps we should adopt some of that thinking. Highly trained (and expensive) resources should be working on projects that have a high degree of probability of success, not on projects where the final result won’t match the investment.
If you do find yourself in a position where you think it’s time to pull the plug, go about it in a methodical fashion. Pull the people involved together: management, the sponsor and the client first – then the project personnel. Make sure that that everyone understands the reasons the project should be cancelled and take care of outstanding concerns like legal or human resources issues as people and money are reassigned.
