Define the decision before you assess the risk

An assessment can contain plenty of detail and still leave the decision-maker unsure what to do. Before listing risks, make the assignment clear: what decision will this assessment support, and where does the work begin and end?

That is the purpose of scope. It gives the assessment a defined task and gives everyone involved a way to judge whether the result is useful.

Begin with the decision

“Assess the risks of the new system” leaves several questions open. Are you deciding whether to buy it, whether to launch it, or how to operate it? Which teams and interfaces matter? Does the assessment cover next month’s launch or the system’s whole life?

Consider this fictional assignment:

Assess whether the customer support team can move to the proposed case-management system in October, and identify any actions needed before the operations director decides whether to approve the change.

Now the work has a purpose. The assessment must inform a launch decision, and the team knows who will make it. It still needs boundaries and evidence requirements.

Write a scope people can check

A short scope statement can answer the following questions. Add detail where the decision needs it.

• What are we trying to achieve? Move the support team while maintaining the agreed service arrangements.

• What is included? Data migration, user access, staff preparation, supplier support and the handover between systems.

• What is outside this assessment? Whether other departments should adopt the system later.

• What period matters? Preparation, launch and the first month of operation.

• What will we deliver? Material scenarios, evidence and uncertainties, treatment options and a decision brief.

• Who needs to contribute? The support manager, system administrator, supplier representative and affected staff.

• Who decides, and when? The operations director at the agreed launch review.

An exclusion should make the boundary visible. It should not hide a dependency. If the support team relies on another department’s data, that interface still needs attention even when the other department’s entire operation is outside the assignment.

Make assumptions and limits visible

Perhaps a supplier test report is available but a live trial is not. Perhaps the assessment team has five working days, or a key specialist is unavailable. Record those limits and explain what they mean for the conclusions.

Do the same for assumptions. “Staff will complete training before launch” is an assumption until there is evidence. Assign someone to check it, and state what happens if it is not met.

Agree what completion looks like. A finished report is an output; a decision-maker having enough relevant information is the intended use. The scope should make both clear.

Revisit the boundary when something important changes

Scope is a starting agreement, not a reason to ignore new information. If the supplier changes the migration method or another team becomes dependent on the launch, revisit the affected part of the assessment. Record the change and its implications for time, resources and the decision.

For your next assessment, complete this sentence before opening the risk register:

This assessment will help [decision-maker] decide [decision] by [date], covering [boundaries and time horizon], using [evidence], and delivering [outputs].

Then ask the people doing and receiving the work whether they understand it in the same way.Based on section 5.3.1 of Risk Management Body of Knowledge, by Julian Talbot, Jason Brown and Miles Jakeman, AM. The system-change example is illustrative.

Put the body of knowledge to work

Explore the Risk Management Body of Knowledge for the connected principles, frameworks and methods behind this article.

Considering a shared reference for your team? Enquire about organisational use and tell us how you would use RMBOK.