Harry Hall paints a dreary scenario for you to ponder at his blog. He wants you to imagine you are a project manager on a software development project where everything has gone wrong. The defect level of source code has risen above the defined threshold or trigger point for the third consecutive week, the test region has been very unstable, the best programmer had a car accident and will be out two to three months, and the users continue to request numerous changes in the functionality of the software. This is where the tale branches off into two parallel universes in which different IT directors take over as risk owner. Yep, you have just stepped into the Twilight Zone of hypothetical IT scenarios.
The first director, codenamed “OC” for “out of control,” plans little in advance and tackles each challenge head-on, devoting all of his energy to one issue at a time and then hurrying on to the next problem. I like to imagine OC wears a Metallica T-shirt as an undershirt. The second director, codenamed “IC” for “in control,” recognizes that IT processes function as an integrated whole and tries to craft solutions that address multiple problems at once while effectively distributing available resources. IC probably listens to U2 in the car.
Hall then asks you which of these two universes is preferable to you as the project manager. It is likely you picked U2 fan IC. A mature risk manager knows how to leverage risk identification tools, such as looking at past lessons learned, interviewing stakeholders, reviewing risk checklists, and brainstorming risks with IT managers. Risk action owners are needed:
For large projects, it would be difficult for a single risk owner to execute numerous risk response plans simultaneously. This is where the risk action owners come into play. Risk owners define the risk response plans. The action owners execute the response plans when the risks occur.