PMGT5891 Chap.2 Identifying Risks Against Objectives
Identifying Risks Against Objectives
This chapter shows how risk identification works when it starts from objectives rather than from a blank brainstorm. You will learn to write risk statements in cause, event and consequence form, following ISACA guidance built on ISO 31000 definitions, and to tell a cause apart from the event it triggers.
The known and unknown matrix explains which kinds of uncertainty identification can reach, and the identification tools taught in the unit are matched to the gaps they close. Hillson's Risk Breakdown Structure then organises the results by source, so concentrations of exposure become visible. The chapter ends with the Week 3 task of critiquing public risk register templates.
What this chapter covers
- 01
Clarifying objectives before listing risks
- 02
ISO 31000:2018 purpose of risk identification
- 03
Risk statements: event, cause and consequence
- 04
Separating causes from events
- 05
Known knowns, known unknowns, unknown knowns, unknown unknowns
- 06
Identification tools from checklists to structured interviews
- 07
Risk Breakdown Structure levels and numbering
- 08
Judging concentration by summed scores, not counts
- 09
Critiquing public risk register templates
Worked example · free
Statements and branches for a library app upgrade
- +1Data: Loss of borrowing histories during migration caused by mismatched field formats between the old and new databases, resulting in roughly 2,000 members needing manual record repair over 10 staff days.
- +1Branch: the root source is the data structure of the two systems, so it belongs under 1 Technical, for example as 1.1 Data migration.
- +1Staff: Late launch of the new app caused by the only developer who knows the old system leaving mid-project, resulting in a 4-week slip past the holiday period and about $18,000 in contractor fees.
- +1Branch: the root source is reliance on one person within the project team, so it belongs under 2 Management, for example as 2.1 Key personnel.
Key terms
- Risk statement
- A risk statement is a sentence linking an event that affects an objective to its causes and its consequences, often in the form event caused by cause resulting in consequence.
- Unknown knowns
- Unknown knowns are pieces of knowledge an organisation already holds but has overlooked, often because they are implicit or held by a few people.
- Risk Breakdown Structure
- A Risk Breakdown Structure is a hierarchy of risk sources, modelled on the Work Breakdown Structure, in which each lower level defines sources in more detail.
- Risk taxonomy
- A risk taxonomy is a single-level list of risk categories, which Hillson contrasts with the multi-level Risk Breakdown Structure.
Identifying Risks Against Objectives FAQ
Why should objectives be agreed before identifying risks?
Because risk is defined as an effect on objectives, a risk cannot be judged without them. A delay matters only if a deadline is an objective, and a cost overrun only if the budget is fixed. Agreeing objectives first also sets the right level for each statement, since a team objective and a board objective attract different risks and different readers.
What is the difference between a cause and an event in a risk statement?
The event is the thing that directly moves an objective, such as data leaking or a launch slipping. The cause is what gives rise to it, such as a faulty change or a missing skill. Mixing them up produces statements that blame an activity without saying what goes wrong, which leaves the risk owner unsure what to control.
How is a Risk Breakdown Structure different from a list of risk categories?
A list of categories offers one level of headings. A Risk Breakdown Structure nests sources through several levels, so risks can be mapped to the lowest level, totals can be rolled up for senior reports, and empty boxes reveal possible blind spots. It can also become a checklist for future projects and a common frame for comparing tenders.
Can unknown unknowns be identified at all?
Not directly, since by definition nobody is aware of them. Some, however, were knowable: a careful search of documents, wider information sharing and decomposing the project can expose them, at which point they become known unknowns that can be registered and treated. For the rest, the realistic aim is to be ready to recover when a surprise arrives.
Exam move
Pick any project you know well, perhaps a recent group assignment or a renovation at home, and write its three main objectives in one line each. Under each objective, draft two risk statements using the event, cause, consequence template, and give every consequence a number. Then swap statements with a classmate and check one thing only: is the event really an event, or is it a cause in disguise?
Next, build a two-level RBS for the same project and map your six statements onto it; any empty branch is a prompt for more identification. Finally, open one of the public register templates from Canvas and list three fields you would add or change, noting the ISO 31000 or PMI idea behind each change. Repeat the statement drill weekly until it takes under two minutes.
Working through Identifying Risks Against Objectives in PMGT5891? Sia is AskSia’s AI Project Management tutor — ask any PMGT5891 Identifying Risks Against Objectives question and get a clear, step-by-step explanation grounded in how PMGT5891 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
