06 Dec IT project failure: Pulling the plug is hard to do
Madison, Wis. – Knowing when to pull the plug on a failing information technology project – before it becomes an expensive mistake – is perhaps the most difficult judgment call for chief information officers.
It has led to multi-million-dollar failures in government and the private sector alike, but many companies continue to struggle with the decision and have not developed a good way to apply the brakes.
Yet if CIOs fail to pull the plug, especially when big dollars are involved, they run the risk of not getting a second chance. A CIO’s reputation for reliability and his ability to manage big projects comes into question by constituents and higher-ups alike.
It also has budgetary impacts. If upper management loses confidence in the CIO’s ability to take on large efforts, the money for important strategic initiatives could suddenly dry up.
That’s why it’s well worth making the attempt to erect roadblocks. In WTN’s discussions with state CIOs, we found a number of decision-making approaches. Perhaps none of them are foolproof, but they provide some guidance for avoiding expensive mistakes.
Swinging gates
David Cagigal noted a recent WTN CIO profile in which Todd Oberg, the CIO for Runzheimer International, said the company has established a gate process in which each project stage has a set of requirements that are established and assessed by “gatekeepers” who evaluate whether projects should proceed in terms of cost or value or deliverables.
Cagigal, chief information technology officer for Alliant Energy, understands and appreciates that approach, but he believes organizations still could encounter the same dilemma about when to slam on the brakes.
The early decisions are easy, he said, and that’s were the gates work – evaluating feasibility and establishing expense reporting in gate one, developing alternatives to prove out and then vendor RFP in gate two, and contract negotiations and vendor selection in gate three. But if the project falters after the point of signing a vendor contract, the decision isn’t as cut and dried.
In the case of a two-year, $2 million project with $1 million spent after one year, how do you shut it down when half of the project cost has been invested?
The more money sunk into a technology project, the greater the tendency to rationalize. “When you have so much invested and spent, it’s hard to pull the plug,” Cagigal said. “It’s an area that causes great stress.”
In some cases, stress comes from investing good money after bad. In the worst case scenario, you pour $2 million into a $2 million product and you still have $1 million worth of work still to do. That’s the kind of situation that could end up taking four years and $4 million.
Unfortunately, many of the early enterprise resource planning projects unfolded that way, and hapless chief information officers felt they had no choice but to stay the course on a technology that held so much promise for lowering maintenance and enhancing reporting capabilities.
That, in turn, can lead to a job or career change. Since it’s difficult for original authors to walk away from an investment and admit defeat, it sometimes takes a fresh pair of eyes and a different administration to come in and set a new direction. “I’ve heard courageous stories where CIOs have done that,” Cagigal said, “but typically it’s the second CIO who pulls the plug because the first one refused to admit defeat.”
The aforementioned gates are essentially a scoping exercise that includes a cost-benefit analysis, according to Alex Yarmulnik, vice president and chief information officer for Midwest Airlines. “The biggest gate is right there,” he said. “What is the payback? Can it be measured? If not, and it’s not strategic or nobody has a good feel for it, we’ll pull the plug.”
Some projects looked good at the feasibility stage and the discussion phase, but upon further evaluation are not pursued because the payback is not clear. Yarmulnik estimates that roughly 80 to 90 percent of the plugs are pulled at that moment-of-truth phase involving return on investment.
Another time a plug is typically pulled is when a project lacks business sponsorship. “Remember, these are all business initiatives,” Yarmulnik said. “If we feel the business is not engaged and the sponsorship is weak, we will at least slow down the project to point where there is very little activity and see how the business reacts.”
Coping with scope
Cagigal acknowledges to a couple of cases at Alliant Energy where, if he had to do it over again, he would have scoped projects differently or selected a different vendor. He said one project should have been “chunked up” into smaller pieces, which he views as a good risk-mitigating practice. By dividing a large, expensive project into more manageable pieces, a CIO can walk away from it more easily and measure success compartment by compartment.
It is possible to plan a project in a way that if Phases I and II are completed, and you decide not to proceed because you have reached a point of diminishing returns, the organization still can derive some benefits,” Cagigal said. “If you need all four before it will work, that’s not good.”
The second project was undermined by a vendor issue pertaining to requirements. As Cagigal explained, when you deal with vendor, their product typically is a general design. Had the company used it general manner, it would have been okay, but customization got them in trouble.
“Why do you need to be different to warrant a customization and add more dollars?” Cagigal asked. “It takes a strong change-control process to mitigate a loss, and so you should be able to chunk up general design of a vendor product and say, ‘I’m only going to bite this piece off and refrain from customization.’”
To abort a project in mid stream, it’s important for CIOs to be able to forecast a loss at the conclusion of each phase. This judgment call is based on what has been accomplished, and how much more still needs to be done.
Perhaps more importantly, no CIO should make this decision in isolation. In Cagigal’s view, it’s better to develop a consensus of the project team, the leader, the customer, and even the vendor in some cases. That may be counterintuitive, but vendors are leery of writing provisions that waste customers’ money, so generally they are agreeable to well-defined exit points.
Detached view
Steve Cretney, vice president of business and technology services for Total Administrative Service Corp., said the exit point ideally is built into the project plan. That plan, he noted, is crafted by people who not only have the motivation to succeed, but sometimes also have the motivation to create the perception of success. That’s why Cretney believes it’s important to involve a different group that is less biased and perhaps more engaged with the business.
“Here and in a past [professional] life, we created checks and balance with the business in terms of progress and spend results,” Cretney said. “We used the business staff along with the IT team to validate that progress is being made.”
Through what Cretney called a “dashboard” process, a steering committee that includes senior management will review all projects on a month-to-month basis. The committee looks at major components of the projects to discuss where they are coming up short, where they are ahead of schedule, and the cost picture. “We engage that group on whether we should keep going or not,” he said. “The project champion is not in this group.”
According to Cretney, CEOs and CFOs tend to help solidify the situation better than people intimately involved in the project because “nobody wants to have egg on their face at the end of the day.”
Options are an option
Sam Valanju, CIO of Johnson Controls in Milwaukee, is somewhat skeptical about putting stop signs in the project design.
“We don’t bake in failure,” he said. “It’s really about looking at options.”
Valanju said there are three options predicated on setting stringent criteria for “go” or “no-go” decisions, and for getting some business value out of the initial phases. Benchmarks and milestones are established for each project, and projects are never killed entirely.
The three alternatives are to break the projects into phases, elongate them, or limit their scope.
The decision to elongate, or spread it out over more years, typically occurs when spend exceeds estimates and the company wants to limit spending on a fiscal-year basis, he said.
Accepting the results of an initial phase, without immediately advancing the project, is predicated on getting the most value out of early phases. In Valanju’s view, the early stages should provide “must-have” value, whereas subsequent phases would offer “nice-to-have” value that does not need to be immediately pursued.
The reduction in scope alternative is another form of phasing, but a more abrupt one that involves a permanent reduction in project scope because other projects have more value going forward.
In addition, the decisions are never made in an IT vacuum. These judgments necessarily involve management and project steering committees, which Valanju views as critical to avoiding the usual pitfalls.
“It’s really not an IT project,” Valanju noted, “it’s a business project that is managed by IT.”