Has everyone had enough of risk context yet? According to Google, I see that a grand total of 58 persons on the planet searched for “risk context statement” last month. OK, this post goes out to you 58!

In previous posts we’ve covered the reasons why you need to establish context (if you contemplate conducting a risk assessment) and the elements of a risk context statement. I can share with you now some of the common pitfalls I have encountered over the course of preparing and facilitating many risk ID sessions in a variety of organizational settings:

1. Lack of Planning: Hands down, the most common pitfall in writing context is trying to make up for poor planning. You feel you have to take an educated guess at what the project team plans to do, because the organization in question does not really have a mature planning practice and associated terminology. The idea of individual tasks, objectives, broader goals – and the future vision and mission these are all serving – are not clearly conceived and documented. I have seen this in both public and private settings.

Now, there is no need to drown in paper, but I feel there must be an ordered documentation of what the organization (or department) in question intends to accomplish, how they want to go about it, and how they like to conduct business. Then you have a basis for discussing risk. If you have a project management culture, then this is likely solved.

2. Lack of Rich Context: The next pitfall is to conceive of the context (and so its associated risks) very narrowly or superficially; it reads like a bit of vague background. Rather, context should be a detailed map that lets you discover all types of risk.

I’m convinced the risk context statement can address any conceivable project, on any scale, in any content area. You can identify risk in all of these:

work breakdown structure in a conventional project document;

administrative procedure;

industrial process;

technical workflow or materials handling operation on the plant floor;

new product launch;

implementation of a new HR policy;

execution of a strategic plan over the course of three years;

plans for a marketing campaign;

terms of a complex service contract;

implementation of a new IT system;

creation of a social services agency;

…and so on, ad infinitum. So “establish the context” applies to virtually any strategic or operational plan.

Now, this means that you can present that context in just about any format you can imagine; e.g.,

3. No Values. Another pitfall is to gloss over values. Risk assessments commonly ignore ethical and procedural guidelines, including professional codes – and yet these are assets at risk, and a source of competitive advantage. If they are included, they should go beyond a few “motherhood and apple pie” statements copied from the annual report (sorry). For example, I’ve led sessions where medical personnel have listed in point form their entire professional code in the context paper; subsequently, we reviewed each item for potential risk in the project at hand – an excellent approach!

4. Underestimated Stakeholders. They should at least be identified, and assessed with regard to their views and expectations. Then you will be able to determine what the risks are in relation to your program goals. One strategy far too under-utilized is to include certain stakeholders, constituents or program beneficiaries – somehow – in the risk assessment process itself. This is a distinct improvement on ordinary consultation that adds to the credibility of your risk management program. For example, I’ve seen government project teams invite industry reps and subject matter consultants to help identify risk in major public policy drafts. Result: a risk-adjusted implementation plan for a controversial policy that everyone agreed to. Another option is to conduct first a closed-door session (often preferred), but then share results with stakeholders to allow them to add comments.

5. Procedural Pitfalls:

a. Do not permit risks themselves to be listed in the context paper, because you are likely to forget to include them in the risk register.

b. Don’t forget to document any constraint or limitation that has been imposed on your risk ID and assessment process, including no-shows. This is simply to make clear the conditions under which you conducted the risk analysis and drew conclusions.

c. Don’t forget to state and draw attention to the intended deliverable (item 9 in our risk assessment template-establish the context.) This is a technique used in facilitation to ensure that participants understand what they must produce by the end of the session. It could read something like this: “Comprehensive list of risks associated with implementation of project X, identified and assessed by consensus of round table members, with corresponding summary plans for risk mitigation.”

Final note: it’s not quantity, it’s about quality. The context paper need not be longer than a few pages. As long as it is authoritative, this work at the front end of the risk process is well worthwhile.