When and why good projects go bad

Dana B. Harris still remembers the loss he felt when his project was canned -- and it happened 20 years ago.

Harris was working on sonar acoustics software for the U.S. Navy's Arleigh Burke guided missile destroyers. It was highly advanced, mathematically challenging software, and Harris "was really into it, really excited about it."

But 1990 was a bad year for the defense industry. The Cold War was ending, and a diminishing threat meant diminishing budgets -- and, ultimately, a diminished project. Abruptly, Harris' part of the initiative was shelved.

"That was pretty depressing," says Harris, who now works at IT services provider Computer Sciences Corp., where he is manager of CSC client United Technology Corp.'s global program management office. "Not having the excitement of developing that kind of software, it was like I'd lost something. I remember that feeling very, very clearly."

It particularly pained Harris that his team's work was simply junked. "Our efforts, our work, were just cut," he says.

Stung by the cancellation, and worried about the health of the industry, Harris wound up leaving defense entirely to start a business working on commercial application software.

It's hard not to get emotional when lengthy, high-profile technology projects are unfairly killed, mercifully euthanized or launched with flaws.

"A lot of your job satisfaction comes out of seeing your product go live, being used by your business and customers," says Ken Corless, executive director of enterprise applications at management consultancy Accenture PLC. "If you've been on something for 19 months, working 80-hour weeks for six months, and you're supposed to go live in six weeks and the rug gets pulled out, you feel pretty bad."

If companies were Star Trek, IT would be Spock, or so goes the myth. And that myth does have some basis in fact, says Bill Hagerup, a senior consultant at Ouellette & Associates Consulting Inc., a Bedford, N.H., firm that offers guidance about matters related to the human side of IT management. In general, techies "tend to give short shrift to people's feelings," he says. "I know I'm stereotyping here, but our strength is thinking. We're great problem-solvers; we tend to forget feelings."

Hagerup, who spent years in corporate IT, distinctly remembers his depression over a long-ago project that failed to meet expectations. He was a lead analyst on a project at a health insurer, working long days and weekends. Despite the extra effort, the project timeline was simply too short, and what his team delivered at the deadline was about 60% of what the business expected.

There was no joy in IT-ville, not even an "attaboy" for the effort, Hagerup says. Some negative feelings about a poor outcome were probably inevitable, but it would have helped if there had been some empathy for the IT team, he says.

He wishes IT management had sat down with his team and let them talk through their anger at the unreasonable deadline and the lack of support. Even some simple words of appreciation for their efforts would have been a big help, Hagerup says.

* Push for due diligence at the start of a project. Fisher's team discovered after the fact that other banks using the same development software hadn't been able to get past the first phase of their projects. That should have been a red flag that the software was more of a tool kit than a full-blown development platform.

* Set early milestones. That way, you can flush out potential bad bets in vendors before too much time and money have been invested in them.

* Watch out for negativity. "Once people get negative on a project, it becomes a force multiplier," Fisher warns. Remind skeptics that once a project has been signed off on, "they need to get on the bus."

* Don't let your project fail before its time. Team members can become discouraged if the project runs into bumps. Fight that by refocusing people on specific pieces of the project. "You pull together, you all move forward, you get it done, and it's a success," Fisher says.

As his group eventually proved, the project's scope was too large for its initial deadline. Failing to complete it on time shouldn't have generated such a pervasive sense of disapproval, yet it did.

Hagerup and his team, which numbered about 10 people, went into a techie variation of the classic Kübler-Ross grief cycle -- denial, anger, bargaining, depression and acceptance -- spending several productivity-sapping weeks in the depression phase.

By talking informally at lunch and commiserating over beers on Friday nights, "gradually, we came out of it," Hagerup says. "We circled the wagons a little bit, took strength from each other and reminded ourselves it wasn't our fault."

Over time, Hagerup's team even got the project close to achieving its initial goals, though they never got credit for it, he adds.

He thinks his team would have come out of its funk faster if managers had talked to them about what had happened and how they felt about having their project regarded as a failure. But that reaction "is just not in the playbook of the typical CIO," Hagerup says.

But in fact, "people take it pretty hard" when a project that's going well is killed anyhow, says John F. Fisher, a former CIO who is now chief value officer at NET(net) Inc., a software contracts adviser based in Holland, Mich. "They feel like, 'Could I have done something better? How could we make it work for the business?' Well, you can't. And that frustrates a lot of IT people."

And then there are the big, troubled projects that need to be put out of their misery. Emotions run higher on projects seen as significant, Fisher observes, and the prospect of being out of a job amplifies the anxiety.

In the mid-1980s, Fisher was involved in putting the brakes on a two-year project to build an international banking platform to enable the former Continental Illinois National Bank to update its European operations. He was European systems manager at the time, and he came on board after the project was already under way. Despite moments of glory when things looked promising, it became clear that the platform lacked several essential features and that the project's 45-member team wasn't going to be able to fix the problems cost-effectively.

Fisher recommended pulling the plug. "We were all committed to getting it done, and we had a lot of conversations about whether we could we save it," he recalls. But the answer, in the end, was no.

"It was a very difficult decision; it had an impact on a lot of the people," Fisher says. He had to lay off about a dozen contractors in London, the project's base, and junk a data center, since the system was built to run on Prime minicomputers purchased especially for it. Nobody from Continental's IT staff lost their job, though some people on the business side did.

As for Fisher, "I felt good at the time," he recalls. He was, after all, saving the bank money and time. Later, though, he realized that he and the remaining members of his group were tainted. They weren't added to the team working on the new system, even though they had gained what could have been seen as valuable experience.

He received a much lower end-of-year bonus than he had in previous years, despite no drop in the bank's overall financial performance, and some of the team members were shunted to less interesting, lower-profile assignments for a time.

But the equipment wasn't working, and the network kept failing. "After a month of trying to make it work, with the lawyers ready to throw IT people out the window, we pulled the plug," says Gietl, now CIO at The Doe Run Co., a metals and natural resources provider in St. Louis.

Some founder because of a bad combination of technology, ambition and skills. But whenever projects stumble or even die, and people feel wounded, it usually has something to do with that most persistent of people problems: communication.

Michael Krigsman, CEO of Asuret Inc., an IT project management consultancy in Brookline, Mass., sketches out a typical chain of miscommunication that often plagues problem IT projects:

Team to project manager: "Have you seen this deadline? We couldn't finish if we worked without sleep from now until then."

Project manager to CIO: "The project has some, um, issues. We're, uh, going to need more time."

CIO (wagging finger): "Make it work."

CIO to business side: "I've spoken to the project manager, and the team knows they have to get it done."

"The implication is, 'If you don't make it work, we'll fire your sorry ass,' " says Krigsman. Once a top manager refuses to budge on a deadline, a series of Dilbert moments typically follow, as IT people carry on as though nothing is wrong until the project's impending failure becomes impossible to ignore.

In particularly dysfunctional IT organizations, Krigsman says, groups then engage in a game of "project-failure chicken," each vying to not be the first to admit they can't make a deadline. Where multiple departments are unable to meet the project goals, the one that blinks first often takes all of the blame for the failure. "So one side is unhappy, and the other side is gloating," Krigsman says.

Emotional finger-pointing is "uncalled for, unprofessional and unnecessary," says Dana B. Harris, manager of United Technology Corp.'s global program management office, who oversees multiple programs that encompass some 202 projects. A better solution is a smart postmortem -- his company uses a root-cause analysis process -- to show where the project failed and determine rationally what steps to take to avoid future mistakes.

She fell on her sword, telling her managers that IT had made a mistake by picking an untried technology, and she outlined a new approach that included an Ethernet backbone. Cabletron agreed to provide new equipment at no additional charge and to help install it. She demoted the network manager, who later left the firm.

While morale in IT was terrible during the project, she says there wasn't much in the way of postproject depression. "They were happy that we had a network that worked," says Gietl. Her transparency eased some of the tension, Gietl feels, and though the lawyers joked pointedly about "computerless Fridays" for a while, having a network that worked well proved to be the best salve for the failed-project wound.

Accenture's Corless would applaud Gietl's forthright approach. IT management can best help its employees by dealing with dead projects directly and quickly.

"Rip the Band-Aid off -- tell people live and in person," he advises. "Don't shift the blame by saying something like, 'I wouldn't have canceled it, but this is what the COO wants to do.' That says you're not part of the leadership team." Such managers lose a chance to build credibility and rapport with their teams.

On the other hand, managers need to be careful about plumbing feelings right after a project has failed. "You'll get tempers flaring. People aren't thinking straight," warns Jim Johnson, chairman of The Standish Group, a Boston-based IT research firm that produces an annual report on failed IT projects called the "Chaos Summary."

Johnson advises IT managers to wait a couple of weeks before sitting down with staff to assess what went wrong. But don't wait too long; if you do, people may already have rationalized what happened or forgotten what went wrong.

In the end, managers need to remember that what gets IT people going is the chance to learn new things and develop new skills, says Corless. To that end, the best way to help employees grieving over a dead project is to "quickly get them into [another] meaty and interesting role," he says.

Wise managers will gently remind staffers that there will be other projects and that they can learn a lot of lessons from troubled ones. "These projects teach you to be adaptable, to deal with frustrations, resource shortages, and so on," Corless says. Project failure may not be fun at the time, he adds, but it doesn't have to keep a good IT person down.