Opinion: How to Fix a Failing IT Project

My last two postings were about the difficulties of estimating the cost in time and money of software development projects, and the perils of planning them. This time I want to look at what happens when one or both of these processes fails, and you end up with a train wreck, yet you still have to finish the project. How do you avoid turning a failed development project into a death march?

About 15 years ago, I spend almost 18 months running an organization whose only job was to fix broken projects, mostly large, complex corporate information systems projects my firm was developing for very big companies. It was not fun work, but at the time it was extremely important to my employer. My firm needed to stop a rash of expensive project overruns (and unhappy clients). and it also wanted to boost the confidence of project teams that if they got into trouble, someone would be there to help them out. We wanted our teams to look for opportunities to “push the envelope” in their development pace, because that’s where the highest margins were, but not to routinely crash and burn.

I got the job because I had a good track record delivering tough projects and because I’d led my employer’s efforts to develop a world-class approach to project management. The thinking of my bosses seemed to be, “Well, you seem to know how to do this, and anyway, we’re using your ideas. So go explain to the troops how to make the project work.” Not that all (or even most) of the ideas were mine of course, but that’s what you get for being in the lead.

The result was that I got to parlay some of my successes and consequent reputation into some operating principles and rules of engagement.

First, as a matter of principle, we never simply “shot” the project team. I’d seen this done all too often in past lives, and it was my observation that the problems we were there to fix were seldom the team’s fault, even if they were active contributors to the failure to recognize and solve the problems. I wasn’t being entirely altruistic here. Fixing broken projects requires willing collaboration and a lot of effort from the team and the client, and knowing that you’re going to get whacked doesn’t exactly foster willing collaboration or much effort. I did reserve the right to move some folks out of the engagement if they were truly the source of the problem, but in practice we only had to do this once, early on in the program.

Second, we would not solve the problem by requiring even greater effort and sacrifice from the project team. Our people are generally highly dedicated and already work hard. That wasn’t the problem. We needed to work smarter, not harder. And I didn’t want to create (or extend) a culture of “heroic fire fighters”: Too often, when you do that you get people starting fires so they can be heroes when they put them out. I wanted a culture that valued excellence in meeting demanding targets and creating satisfied clients, not in rescuing bad situations.

Third, we agreed to look at any project referred to us, but we were not obliged to agree to help. This was in self-defense. I only had a small team and we could easily have been swamped by engagement managers who wanted an easy way out of a transient difficulty or an awkward client relationship. In the end, we reviewed just over 300 projects (about 20 a month) and agreed to intervene on about 25 (about 8 percent). I personally worked on about half of these. We gave a lot of (I hope good) advice to the rest of the engagement managers and many of them came back to ask for additional input from time to time, so I don’t believe we turned anyone away who really needed us.

Of the projects where we intervened, we successfully fixed all but one. By success, I mean explicitly that we got the team back on track, re-engaged successfully with the client, delivered what they needed, and did all of the above very close to the original schedule and budget.

Before I go through some hard lessons learned, I want to talk a little about our only “failure.” This happened about halfway through the program, by which time we felt we could fix anything. Circumstances showed us just the opposite.

Story Guide: