A common feature of troubled projects is that their risk statements (if they exist) are too generic. In other words, they could apply to any project, with any deliverables, at any time. Rich ID’s what drives this mistake — at least, IMHO:
Well, when you as a project manager are assessing your risks, you need to ask – repeatedly – how each risk could add to (as in opportunity) or take away from (as in threat), your project objectives. Sometimes PMs start their risk assessments before they really know what those objectives all are….
He also passes along some practical advice on structuring the statements themselves (from David Hillson and Peter Simon’s, “Practical Project Risk Management“):
Risk Statements are highly-structured sentences, with an “if-then” flavor, which convey clearly what the risk at hand is all about. Each risk statement should include a Definite Cause, an Uncertain Event, and an effect on a Project Objective.
Too many PMs “fight the last war” or lean heavily on “best practice,” so their instinct may lead them to the ol’ copy-and-paste method of risk ID. Using a risk or project review to subject risk statements to the “if/then” test will encourage PMs to focus on actionable risk events (rather than catch-all CYA risks).
Read Rick’s post for more specifics…