Understanding it ...First
At the end of this risk statement metalanguage is perhaps the most important piece. Think about it. Effect on objectives. Project objectives, that is. All of our risks (and that includes threats as well as opportunities) should be focused on the effect that they have on the project's objectives. Not general things like the country's economy, or being nice to people, but specifically an identified project objective. If the risk has no effect on a project objective, kick it out of the risk register. You should be able to make direct connections between the effect of a risk event taking place and a project objective or perhaps more than one objective.
Each risk statement needs to mention what that is.
Continuing backwards through the statement. <uncertain event> means whatever is the root cause of the risk. So this could be:
we could misunderstand the government requirement
we may be able to learn from the interaction with this new subcontractor
we might have an unexpected interoperability issue with these two vendors
Note the probabilistic nature of these assertions, indicated with the italicized word.
And, at the head of the risk statement we find:
The definite cause is the trigger. This does not have an uncertainty element with it, as does the uncertain event.
So here we would find causes like:
- We're using brand-new software
- We're outsourcing production
- We are working within the environment of a newly-merged company
Note the lack of uncertainty here. We are declaring that these things are true.
So although this may lead to some longer risk entries than you are used to, all of them should look something like this:
"Because we are using brand-new software, unexpected integration errors may occur, which would lead to spending more time and money than we planned for.
"Because we are working in a merged-company environment, we might be able to combine project management practices, which could reduce the project planning time significantly."