Dana B. Harris still remembers the loss he felt when his project was canned, and it's been 20 years now.
Harris was working on sonar acoustics software for the 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's part of it was shelved.
"That was pretty depressing," says Harris, now at Computer Sciences Corp., where he is manager of 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 our 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 Accenture. "If you've been on something for 19 months, working 80-hour weeks for six months before 'go live,' and you're supposed to go live in six weeks and the rug gets pulled out, you feel pretty bad."
Thinking about feelings
Problem is, when IT people feel bad, they tend not to talk about those feelings.
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, which consults on 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 downheartedness about a poor project outcome was 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 for the project. Even some simple words of appreciation for the effort they had given would have been a big help, Hagerup 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 air 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.
Through informal talks at lunches or commiserating over beers on Friday nights, "gradually, we came out of it," he 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.
Failing to communicate
Every killed or troubled project has its own particular tale of woe. Some suffer because of unforeseen events -- the end of the Cold War, an economic downturn, a merger, a shift in business priorities.
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 not to 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 the entire blame for the project failure. "So one side is unhappy, and the other side is gloating," Krigsman says.
Emotional finger-pointing is "uncalled for, unprofessional and unnecessary," says Harris, who oversees multiple programs that encompass some 202 projects. A better solution is a smart postmortem -- his firm uses a root-cause analysis process -- to show exactly where the project failed and determine rationally what steps to take to avoid mistakes in the future.
Taking the news hard
Projects that are killed when business needs change might seem like the easiest for team members to shrug off, since it's no one's fault.
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 for the former Continental Illinois National Bank to update its European operations.
Fisher, who was European systems manager at the time, 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 was going to be unable to fix its 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 who were there," Fisher says. He had to lay off about a dozen contractors in London, the project's base, and junk a data center, since the package 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 firm money and time.
Later, though, he realized that he and the remaining members of his group were tainted by the project's failure. They weren't added to the team working on the new package, despite their having gained what would seem to be valuable experience.
He personally 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.
Falling on your sword
When she was running IT at a law firm, Sharon K. Gietl signed off on a LAN upgrade, even though it involved some brand-new technology from Cabletron. Her network manager was excited by the technology and was an enthusiastic backer of the project.
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.
She fell on her sword, telling her managers that IT had made a mistake by picking an untried technology, and outlined a new approach, including an Ethernet backbone. Cabletron would provide new equipment at no additional charge and would help install it. She also 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.
Ripping off the Band-Aid
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, which produces the annual CHAOS report on failed IT projects.
Johnson advises IT managers to wait a couple of weeks before sitting down with staff to assess what went wrong -- just don't wait too long. If you do, people may already have rationalized what happened or forgotten what went wrong.
In the end, IT 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 salve for employees grieving over a dead project is "how quickly you can 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'll learn a lot of lessons from troubled projects. "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 says, but it doesn't have to keep a good IT person down.
Lessons learned
What failed projects can teach us
John F. Fisher, currently chief value officer at NET(net) Inc., a software contracts adviser, learned some valuable lessons years back when, as an IT executive, he had to pull the plug on a failing attempt to build an international banking platform for the former Continental Illinois bank.
* 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 toolkit than a full-blown development platform.
* Set early milestones, to 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.
Michael Fitzgerald is a freelance writer based outside of Boston.