10.4 Practices Application Scenarios (BL4)
Key Takeaways
- Practices interrelate: a risk that materialises becomes an issue; a quality failure becomes an off-specification; a tolerance breach triggers an exception and may force Business Case re-verification.
- When analysing a scenario, first identify the practices involved, then the correct management products, then the right roles — in that order.
- Tailoring a small project still requires each retained practice to preserve its purpose; combining management products is valid, omitting purpose is not.
- A sustainability tolerance breach follows the same exception path as any other target, and may call the Business Case's continued viability into question.
- Practices are applied within processes; the processes drive the lifecycle, the practices provide the controls.
Practices Do Not Operate in Isolation
The Practitioner exam does not test practices one at a time; it tests them in combination. A single scenario often involves Risk, Issues, Quality, Progress, and the Business Case interacting within a process such as Controlling a Stage or Managing a Stage Boundary. The analytical skill being assessed is the ability to see which practices are in play, which management products they produce, and which roles own the decisions.
A reliable three-step method for any scenario question:
- Identify the practices involved. What is actually happening — a risk materialising, a quality failure, a tolerance breach, a change request?
- Identify the correct management products. Which register, report, or approach captures this? Is it the Risk Register, the Issue Register, an Exception Report, a Project Issue, an off-specification?
- Identify the right roles. Who owns the decision — the Project Manager, the Project Board, a Team Manager, a Change Authority?
Applying this method to four worked scenarios shows how the practices interrelate.
Scenario A: A Risk Materialises into an Issue
A project building a new customer portal identified a risk that the third-party identity provider might delay API availability. The risk was logged in the Risk Register with a probability and impact. Six weeks in, the provider confirms a four-week delay. The risk has now materialised — it is no longer a potential future event but a current problem, so it is captured as an Issue in the Issue Register, specifically as an off-specification (the delayed API is a missing or late product).
Practices involved: Risk (the original identification, assessment, and ownership) and Issues (the capture and resolution of the materialised problem). If the delay breaches the stage's time tolerance, Progress is also involved, because the Project Manager must raise an Exception Report to the Project Board. The Project Board, not the Project Manager, decides whether to accept the delay, to replan, or to escalate. The scenario shows Risk → Issues → Progress interacting within the Controlling a Stage process.
Scenario B: A Quality Failure on a Product
A Team Manager delivers a software module that fails its quality review — it does not meet the acceptance criteria in the Product Description. The failure is captured as an off-specification in the Issue Register (Issues practice). The Quality practice is involved because the review identified the failure; the Progress practice is involved because the Team Manager must report the status to the Project Manager in the next Checkpoint Report. If the rework pushes the Work Package outside its time or cost tolerance, the Project Manager raises an Exception Report to the Project Board (Progress practice, manage by exception).
Practices involved: Quality (review and acceptance criteria), Issues (off-specification capture), and Progress (Checkpoint Report and possible Exception Report). The roles: the Team Manager reports to the Project Manager; the Project Manager escalates to the Project Board if tolerance is breached. The Project Board decides on any concession or replan.
Scenario C: Tailoring Plans, Quality, and Risk for a Small Project
A small, low-risk project to update an internal procedure document is being set up. The Project Manager proposes to combine the Plans into a single lightweight Project Plan with no separate Stage Plans, to apply Quality through informal peer review by a subject-matter expert, and to record Risks in a simple list within the Project Log rather than a standalone Risk Register.
Analysis: this is valid tailoring provided each practice's purpose is preserved. The combined plan must still define what is being delivered, when, and with what resources (Plans purpose). The peer review must still confirm the document is fit for purpose (Quality purpose). The risk list must still identify, assess, and control risks (Risk purpose). The tailoring decisions are documented in the PID and in the relevant management approaches — in this case, probably a combined management approach section within the PID.
What would make this invalid? If the Project Manager proposed no quality check at all, or no risk record at all, the purpose of the Quality or Risk practice would be lost, and the tailoring would be invalid. The exam tests exactly this boundary.
Scenario D: A Sustainability Tolerance Breach
A construction project's Business Case committed to an embodied-carbon ceiling for the foundation works, with a tolerance of +5%. Three months in, the Project Manager's latest Highlight Report shows the foundation works are tracking 8% above the carbon ceiling — a sustainability tolerance breach. Because sustainability is a performance target, the breach triggers the standard exception mechanism: the Project Manager raises an Exception Report to the Project Board.
The Project Board now has a decision. If the breach can be recovered within the project's other tolerances, the board may direct the Project Manager to replan. If the breach is structural — the carbon ceiling cannot be met without a fundamentally different approach — the board may need to ask whether the Business Case remains viable. This is the link from Progress (the breach detected via Highlight Report and Exception Report) back to the Business Case (the project's justification). If the Business Case is no longer viable, the project may be stopped or fundamentally replanned.
Practices involved: Progress (tolerance monitoring, Highlight Report, Exception Report), Sustainability (the target and tolerance), and the Business Case (continued viability). The roles: the Project Manager detects and escalates; the Project Board decides. This scenario shows that a sustainability breach is not a special case — it follows the same path as any other tolerance breach, but because sustainability targets live in the Business Case, a serious breach can threaten the project's justification.
The Underlying Principle: Practices Within Processes
Across all four scenarios, one principle holds: practices are applied within processes. The processes (such as Controlling a Stage, Managing Product Delivery, Managing a Stage Boundary) drive the project lifecycle and trigger the activities; the practices provide the controls (registers, reports, approaches, tolerances) that those activities use. A scenario question that asks when something happens is usually a process question; a question that asks what is produced or how it is controlled is usually a practice question. Keeping that distinction clear is a reliable route to the correct answer.
A risk logged in the Risk Register becomes a confirmed delay from a supplier. The delay pushes the stage outside its time tolerance. Which sequence of practices and management products is correct?
A small internal project uses informal peer review for quality and keeps risks in a list within the Project Log. The Project Manager proposes to omit any quality record entirely. Which statement is correct?
A project's foundation works track 8% above the embodied-carbon ceiling, breaching the sustainability tolerance of +5%. What must the Project Manager do, and what might the Project Board have to consider?