Opinion: How to Fix a Failing IT Project - ' Fear of Failure '

This was a project that was in trouble for a combination of reasons, but mostly because the original team that had proposed and started the work had selected an inappropriate technology as the core of their efforts, and had failed to create a design that could possibly have worked with the selected technology. By the time we arrived, the original team had gone (it had resigned almost as a group to go into competition with us, as it happened), and their replacements were truly struggling. The client was mad at us thanks to the change in personnel, the ensuing loss of momentum, and the lengthening delays as the new team came to see that the project couldn't possibly be completed as proposed. They were about halfway through the budget, three quarters of the way through the original schedule and maybe 10 percent of the way through the work.

We took a week to do a complete project review and to try to repair the relationship with the client. The review gave us two options: Start again with a new and appropriate technology, or redo the design so that, with considerable engineering effort, the original technology could be made to work. The redesign would consume a large proportion of our best engineering talent for about six months, but would then be reasonably straightforward, provided that there were no major changes in requirements and the technology vendor delivered the next release of their technology on time and to specification. Starting again would be more expensive: The client had already purchased a lot of software licenses that would end up as wasted cost, and the design effort would have to be almost completely scrapped and redone. But it would be less risky, since we would not be so dependent on software capabilities that were not yet delivered.

As we tried to repair our relationship with the client, another option arose: Walk away. It soon became clear that the client intended to force us to keep to our original budget and to the original technology proposal. We would not be allowed to start again, no matter how much sense it made and how adversely it affected the project schedule. After a further two weeks of negotiations, I recommended that we walk (and pay a fairly hefty penalty). But I was overruled by my bosses, who decided to eat the overrun in order to maintain a business relationship with the client and preserve our reputation. So we put a new team leader in place (a volunteer from my group who was willing to take on the remediation commitment (in part because the client was in his home town and he would get a year working from home out of the deal).

For those of you keeping score, here's what happened next: The requirements changed a lot, and the vendor was late with the next release, which also failed to meet specification in several critical areas. The project finished three years late and cost us more than $20m over the original budget to complete. A restart would have taken a year and cost us under $10m. I still don't know why the client wouldn't let us start again. They would have received a better answer sooner. Oh well.

Story Guide:

Lessons Learned

Next page: Lessons Learned

Next: ' Lessons Learned ' >>

test

>>> More Past Opinions Articles          >>> More By John Parkinson