Active risk management: doing IT projects wrong

IT projects are typically full of risks. There can be many human factors, many external factors, and many unknown factors, all of which can interact in unexpected ways. Because of that, it is critical that you actively identify, track and manage those risks. But to do that means that you have to be willing to stick your neck out, be vocal and point out risks that the business side may not want to address.

Some years back, I was consulting for a client that had several IT projects going on in parallel. My primary task on getting a particular project back on track, but I was also asked to oversee the architectural effort for another project that was just starting up. The client was developing this second project for an outside customer and was in negotiations with the customer regarding both schedule and cost. For simplicity sake, I’ll call this second project “KAID”

In early November of that year, I attended the first major KAID project meeting. The program manager for the project — that is, the client employee working directly with the customer — laid out the schedule which he was going to give to the customer: we’d start coding at the start of December (i.e., in about 4 weeks), we would finish coding by the start of March (about 3 months later), and we would finish testing and deliver the system to the customer by the start of April (after another month).

He asked one by one for a show of hands around the table for those who supported that schedule. To my amazement, hand after hand went up around the table from the IT project manager, the senior technical leads, the subject matter experts, and others.

When the PM got to me, I pointedly kept my hand down and said I wouldn’t sign up for the schedule – both because there was no foundation for it and because I saw a number of major risks with the project. The project manager looked a bit startled at my rather firm refusal to “go along,” but then finished his way around the table.

When I got back to my cubicle, I wrote up a memo detailing (as I recall) about a dozen major risks I saw with the KAID project and the proposed schedule. Here were some of the risks:

• We didn’t yet have a sufficiently complete set of specifications and requirements for the system that would allow us to even begin to estimate the work required.
• We didn’t have an architecture for the system yet, much less key design solutions.
• The system was to be developed using an obscure and specialized programming language.
• None of the team members had ever developed in that programming language; they had been to a two-week training course in it back in September, but had done no work in the language since then.
• Why? Because the development tools – integrated development environment (IDE), libraries, and so on – were not yet available commercially. Version 1.0 of the development suite was scheduled to be released at the start of December. (That alone should be enough to make any software engineers and team leads reading this shudder.)
• Also, no other vendor was providing development tools for that language, so there were no alternatives if any problems cropped up with the version 1.0 development suite.

And so on, and so forth. For each risk, I assessed both the probability of the risk coming to pass and the likely impact on the project if it did. I distributed this memo to the entire project team, with cc’s to the division head and the technology manager just under him.

The response? While some of the engineers on the team sent me private e-mails thanking me for pushing back and for writing the memo, the client told me — in just about these exact words — to “shut up and architect.” The client wasn’t willing to risk the business with the customer by being honest about the risks, uncertainties, and unknowns surrounding the KAID project.

About two months later — in early January — I dug out that same memo. By then, halfway through the planned coding period, the schedule had already slipped a full month (33%). All but one of the risks I had identified had come to pass, all with negative results for the project and its schedule. I then sent an annotated copy of that memo to the original distribution list.

By April, the “end of coding” date had slipped from the start of March to sometime in June (double the original schedule). The client no longer had need of my services, and so my involvement with the KAID project ended. I had a farewell lunch with the division head and his technology manager. We agreed that a lot of the bumps during the past nine months were typical for major IT development efforts. But I did say that they should not have ignored the risks back in November; the ultimate consequence is that the customer thinks that you’re incompetent, dishonest, or both.

A month or so later, I got word from one of the KAID engineers that the “end of coding” date had now slipped to September — triple the original estimate. Not long after came the news that the customer had pulled the plug entirely on the KAID project.

As someone said years ago, if you don’t manage risks, they will certainly manage you. In my next post in this series, I’ll give an example or two of risk management done right in an IT project.

[Adapted from an article originally written for the online version of Baseline.]

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.