Techniques BABOK Guide v3, 10.38
Risk Analysis and Management
In short Risk analysis and management means spotting what could go wrong before it does, judging how likely and how damaging each risk is, and deciding what to do about the ones that matter. The result is a living risk register with owners and response plans that you revisit throughout the initiative, not a one-off list.
Based on: IIBA, BABOK® Guide v3, technique 10.38 “Risk Analysis and Management”; business analysis training materials (module on strategy analysis); K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 32; Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture 9.
On this page
What it is#
The technique identifies areas of uncertainty that could harm the value of a change, analyzes them, and develops and manages ways to deal with them. It is continuous, not a one-time exercise.
As presented in the BABOK Guide and the training materials, it has four parts:
- Identification. Use expert judgment, stakeholder input, experiments, and past experience or historical data. Aim for a comprehensive register; each risk links a cause to a consequence, and one cause can lead to several consequences, or the other way round.
- Analysis. Rate likelihood (as a percentage or as low/medium/high) and impact on cost, duration, solution scope, or quality; together they give the risk level. The training materials also give extra weight to reputational and regulatory risks and to risks that could happen soon.
- Evaluation. Compare each risk with the potential value of the change and with the level of risk stakeholders are willing to accept.
- Treatment. Choose one of five strategies: avoid (remove the source or change the plan), transfer (shift responsibility to a third party), mitigate (reduce the probability or the impact), accept (do nothing for now, perhaps with a fallback plan), or increase (take on more risk to pursue an opportunity). Then write a response plan, name a risk owner, and reassess the residual risk, which is what remains after the response.
Wiegers and Beatty’s additions#
- A risk is not a problem. If something bad has already happened, it is a problem, handled through normal tracking. Risk management deals with threats before they materialize.
- Risk exposure = probability × impact. Do not chase precision; the aim is to separate the most dangerous risks from the rest. A risk rated “high” on either scale deserves early attention.
- Write the full cause and consequence, not just “customers may not agree on requirements”.
- Plan for failure of the plan: a contingency plan says what you will do if mitigation does not work.
- Keep it economical: do not spend more on managing a risk than the loss it could cause.
- Watch the trend: if the same risk stays in the top five week after week, its mitigation is either not being done or not working.
When to use it#
In the BABOK Guide, the technique supports tasks such as 6.3 Assess Risks and 5.4 Assess Requirements Changes. In practice: when building a business case, when choosing a change strategy, before each release, whenever a change request arrives, and in regular status reviews. Its strengths, per the training materials: it works for strategic, tactical, and operational risks; lessons carry over between initiatives; and ongoing monitoring catches shifts in risk levels.
Use Item Tracking for problems that have already occurred. For a small, low-stakes change, a quick conversation about the top three risks may be all you need.
How to do it#
- Set the context: objectives, stakeholders’ risk tolerance, and the scales you will use for probability and impact.
- Identify risks with stakeholders, using prompt lists. Maglinets presents M. Fowler’s four categories: requirements risks, technology risks, skills risks, and political risks. Wiegers and Beatty catalog requirements risks by stage, for example an unclear vision or scope, too little customer involvement, overlooked non-functional requirements, ambiguous terms with no glossary, unvalidated requirements, and uncontrolled change.
- Write each risk as cause → consequence.
- Rate probability and impact, and calculate exposure.
- Prioritize. The training materials warn that the list can grow unmanageable; work actively on the top subset.
- Choose a strategy for each top risk: avoid, transfer, mitigate, accept, or increase.
- Plan the response: actions, owner, due date, trigger, and a contingency plan.
- Monitor at a fixed rhythm: rerate risks, close those that have passed, add new ones, and check that the exposure of actively managed risks is falling.
- Feed the lessons into future initiatives.
Example#
The Workshop, a fictional chain of 12 bike-repair workshops, builds a risk register for online booking and repair-status notifications. Probability runs from 0.1 to 0.9 and impact from 1 to 10 (illustrative values):
| ID | Risk (cause → consequence) | P | I | Exposure | Strategy | Response | Owner |
|---|---|---|---|---|---|---|---|
| R1 | Mechanics are too busy to update status → customers get no messages and keep phoning | 0.6 | 8 | 4.8 | Mitigate | One-tap status update on a workshop tablet; managers check daily during pilot | Workshop managers |
| R2 | Supplier has no catalog export → parts pre-ordering cannot be built | 0.4 | 6 | 2.4 | Mitigate | Request a sample export now; fallback: manual part entry | Development team lead |
| R3 | New rules on customer messaging → rework of consent handling | 0.2 | 7 | 1.4 | Transfer | Use a messaging provider that manages consent under contract | Owner |
| R4 | SMS costs exceed budget → overspend | 0.3 | 4 | 1.2 | Accept | Contingency: move non-urgent messages to email | Owner |
There is also an opportunity: spring is the busiest season. The owner chooses to increase risk by launching in all 12 workshops at once instead of in phases, accepting a rougher rollout in exchange for a full season of online bookings.
Three weeks later R1 is still top of the list, which is Wiegers and Beatty’s warning sign. The analyst finds the tablets were never installed in two workshops: the response, not the rating, needed fixing.
Common mistakes#
- Listing problems as risks → move things that have already happened to the item log.
- Vague statements → write cause → consequence.
- Too many risks → focus effort on the top subset.
- Missing major risks, which the training materials name as a real danger → use prompt lists and involve varied stakeholders.
- Write once, forget → review at a fixed rhythm and watch the trend.
- No owner → every active risk has one named owner.
- Threats only → consider opportunities, where “increase” may be the right strategy.
Template#
| ID | Raised by | Date opened | Risk (cause → consequence) | Area affected | Probability | Impact | Exposure | Strategy | Response plan | Contingency plan | Owner | Due | Status / date closed |
|----|-----------|-------------|----------------------------|---------------|-------------|--------|----------|----------|---------------|------------------|-------|-----|----------------------|
| | | | | | | | | | | | | | |
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.38 “Risk Analysis and Management”.
- Business analysis training materials (module on strategy analysis).
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 32 (risk management and a catalog of requirements risks).
- Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007. Lecture 9 (risk categories after M. Fowler; risk management after K. Wiegers).