Risk Management: Documenting the RisksBy Bruce F. Webster | Posted 2008-10-10 Email Print
In IT projects, Bruce F. Webster writes, you have to be honest and vocal in pointing out legitimate risks or else your budget, team and client are all going to end up losing the project battle. Being honest about project issues upfront can help win over clients trust and show your team that managing for success begins with a smart, organized approach to risk mitigation.
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. 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. 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. Next week, I’ll give an example or two of risk management done right in an IT project.