The risk register, if it's done at all, is a dead end. You do it, probably up front, and rarely revisit it. And, you don't budget (or, are not allowed to budget) for the response plans, and like a dangling participle, the RR never connects to the real project (aka, baseline).
But, hey check a square: the RR is done! (And, so is risk management. Whew! that was hard stuff)
Second issue: Evaluating the quality of an estimate, or evaluating the quality of incomplete information--as from a sample--is said to be "not risk management". It's estimating or it's decision-making or it's sampling or it's quality management, but it's not risk management.
And third: without a formal process--like the six steps in the risk management knowledge area of the PMBOK as an example--there's no risk management going on, or there's no risk management that can go on.
Well, the first issue is troublesome, but not fatal. As many have said: "It's not the plan, it's the planning that has value". If''ve you got no funding, and an insensitive sponsor, then your risk response plan is "accept the risk". But, having done the planning, you'll be that far ahead if the risk event actually occurs. Not great, but usually not fatal.
The second is just misunderstandings. There're no facts about the future; only estimates in the present of what the future could be. There's uncertainty in every estimate, and thus by definition, there's risk. Risk management ideas apply, even if you don't do a risk register for every estimate. And, by the way, nobody does except for those estimates that have material strategic impact to the project. Otherwise, you fall back to reasonably accepted practices, like 3 point estimates and Monte Carlo simulations. That's risk management, even if it's estimating also.
The third is another form of misunderstanding. Everyone thinks about and manages risk every day, from driving to work to putting hot coffee in your lap. It doesn't take a formal process, but the mind, either working in System 1 or System 2, rapidly steps through identification, prioritization, evaluation, and response. You may not be conscious of the systematic way you process risks.
Of course, what about safety engineering and design? Doesn't that incorporate risk management in projects? And, don't leave out the "ilities". Mean time between failures (MTBF), mean time to repair (MTTR), and other "ilities" are all based on statistical uncertainty and statistical models. Where would projects be without the Poisson or Exponential distributions?
And, what about post-project business risks? These reflect back into the project as effects on performance, functionality, feature, and aesthetic appeal. Shouldn't these risks be "risk management" to the project manager?
And, on an even larger scale, every alert project decider considers the consequences, to include the affordability (or not) of consequences, in everything decided. That's risk management also. It's just not written down.
So, everyone's a risk manager, all day, every day!
Bookmark this on Delicious