If you sponsor enough IT projects, it is likely you will most likely be faced with the decision of whether or not to kill a project. The decision is almost invariably a difficult one, with a desire to see the solution achieved vying with a realistic assessment of the project actually achieving the desired outcome. Emotional factors such as corporate face-saving and an the irrational value typically assigned to sunk costs complicate the intellectually challenging task of accurately predicting the final cost and final success of the project. In this installment, I hope to provide sponsors with some thoughts about making that difficult decision as to whether or not a project should be terminated.
Also, be aware that all of these points will also have merit in keeping an eye on projects to see if they are on track or starting to tempt fate. Many projects that ultimately need to be killed either shouldn't have even started or could have been saved had people caught the warning signs earlier.
One of the first things to realize is that, unfortunately, IT project failures are not uncommon. If you are in a large organization, it is a virtual certainty that projects have failed, even if those projects were not killed outright, or labelled as failures, Many projects actually seem to take former Senator George Aitken's advice about Vietnam, namely to "declare victory and go home." The point is: do not make the mistake of thinking that the project failure is truly unique, do not let the fear of being "the only one" to have a failed project prevent making the right decision.
The next thing is to remember that sunk costs are just that: sunk, unrecoverable. Do not fall prey to the idea that too much money has been invested in a project already. That line of thinking results in such irrationality as allocating another $1 million to a planned $500,000 project that is already $2 million over budget (and usually the major debacles add another zero to each of those numbers).
The third thing is that most people involved with the project, whether from IT or the business,will be more optimistic and will want the chance to succeed. Rosy scenarios of a project getting back on track by these groups aren't a deception so much as they may be a delusion. Don't be afraid to challenge the assumptions underlying a sanguine forecast, and make sure that they understand that the most important thing is to do the right thing by the enterprise, regardless of what that means to a project. A future discussion will cover effective and appropriate techniques for challenging assumptions and projections in more detail, but I would encourage business managers to trust their instincts, have an open mind but maintain a healthy bit of skepticism, and approach the discussions with probity, curiousity and objectivity.
The last thing is: don't let your own optimism and desire to succeed allow you to become complicit in the charade. Remember, it's just business, and their is no progress without some level of risk.
That clears up the psychological issues that may stand in the way of making the best decisions about whether or not to kill a project. Now we can turn to how to assess whether or not a project needs to be terminated or whether that troubled project can be saved.
The first thing to verify is that the project ever made sense, and make sure it still does. The quick bullet points for that check are:
- Does the project fit into the business strategy, either directly or through a derived objective or tactic? Sometimes projects are taken on because they seem like a good idea, but that good idea can't be mapped back to a key business goal. Sometimes business goals change. If the project doesn't make sense for the business, it doesn't matter whether or not the project is in trouble, it probably should be ended.
- Is the project technically viable? Sometimes an initial estimate of a project suggests a more optimistic view of the technical challenges that must be overcome. Make sure the project is still feasible. And when assessing feasibility, be realistic. If you're at a manufacturing company, you usually shouldn't be undertaking a project that requires solving a complex or theoretical computer science problem.
- Do the users/customers of the project still support it (if they ever did)? If this was a project dreamed up and pushed through by a technologist that solves a problem no one thinks exists, it's probably a good candidate for the chopping block. It is also possible that the problem was solved by another corporate initiative, or a change in business operations, regulations, etc. Make sure it still matters.
- Are the project sponsors committed? This means you. If you're lukewarm on the project, it's probably better to kill it. A troubled project usually needs a lot of sponsor support to get it back on track. If you don't think it's worth your time, don't waste the company's money, kill it.
So let's assume that you have four "yes" answers to the above questions. Now it's time to look at the actual state of the project. Get real numbers from the project manager or program office. Maybe do some of the old MBWA (management by wandering around) to get a sense of things from the team. People lower in the organization usually have less at stake politically and will answer with their true sentiments. Bear in mind, however, that neutrality and objectivity are no more common than Eeyores and Pollyannas. I have had people work for me who are convinved a project will fail right up to the point the system goes live. I prefer these people to the Pollyannas, as long as their high-strength risk antannae don't demoralize others, and as along as I know the filter to apply to their feedback.
In any event, start checking the project metrics:
- Project schedule Is the project off schedule? By how much? Is there a history of schedule extensions? Is the schedule endpoint staying close to the same while internal dates are moved forward? An example of this would be a schedule that had milestones of 10/1, 12/1 and 2/1 and a project completion of 4/1. If the project is still scheduled to be completed on 4/1, but the milestones have moved to 12/1, 1/1 and 2/1, that's probably not a good sign unless there is a clear explanation of how recovery can take place.
- How's the budget look? Is the budget burning faster than forecasted while producing fewer deliverables than expected? Bad sign. However, if the budget is burning slower than planned and the project is behind schedule, this would be expected: it is simply not getting the resources it needs. This is most likely fixable, but don't let the project drag on. Projects that go on too long develop other risks, like staff turnover, atrophy, changes to requirements, etc.
- Project Risks and Issues Most projects maintain a risk and issues list. (If your project doesn't have one, you should probably think about getting a new project manager.) Give it a read, how many "showstopper" risks are there? How many risks could end up blowing-out the schedule or the budget? I am a firm believer that here is no progress without risk and every project has risks. However, while risk aversion in a business context is usually irrational compared to risk neutrality, risk-seeking behavior is the most insane of all. If a project requires a seemingly large number of things to go exactly right to be a success, that's not a good situation.
- How's the Team? Anyone who has ever managed a team knows that a motivated and competent team can often make the seemingly impossible a reality while a demoralized team has a difficult time achieving the mundane. If the team is fired up to succeed and they don't seem like they need psychiatric help, that's very promising. On the other hand, if the team seems like just dragging themselves to a project meeting is a chore, it might be time to kill the project. Failing attitudes produce failed projects. Make sure you're paying attention to the whole team, and have a good sense of reading them.
Ultimately, at this point, you should have a pretty good sense of whether or not to kill the project. If you're still unsure, you might want to look at an article from Computerworld that discusses the ProjectHALT process from the Center for Project Management. It has a scoring system, similar to what you might see in Cosmopolitan to know if it's true love or just a crush.I'm obviously not a fan of boiling such a complex decision into a set of numbers, and generally feel that such tools merely create the illusion of objectivity while masking the elements of good business decision-making. However, if you're in an organization where "it's a number, it must be true" is a common attitude, it might be helpful.
Good luck, and I hope your projects are going well.
If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.
Comments