13.4 Process Application Scenarios (BL4)
Key Takeaways
- Processes provide the framework within which practices and principles are applied; scenarios require identifying the correct process sequence, not just the right practice.
- From Starting Up through Initiating to the first stage, the handoffs are: Project Brief → request to initiate → PID and request to authorise the project → first Stage Plan and authorisation to deliver.
- At a stage boundary, Managing a Stage Boundary produces the End Stage Report, updated Business Case and Project Plan, and next Stage Plan; the board then authorises, defers, or stops.
- Premature closure mid-project replaces the normal End Stage Report with an Exception Report leading to a closure decision, and Closing a Project must then handle partial products and Follow-on Action Recommendations.
How to Approach Process Scenarios
Bloom's Level 4 questions ask you to analyse a situation and identify the correct process behaviour, not just recall a definition. The reliable approach is:
- Identify where the project is in the lifecycle — which stage, which boundary.
- Identify which process owns the activity described.
- Identify the management products that process must produce.
- Identify the role that performs the activity and the role that decides.
- Check the sequence — what must have happened before, and what happens next.
The processes are the framework within which the practices (risk, quality, scope, and so on) and the principles are applied. A scenario that mentions a risk review at a stage boundary is really asking about Managing a Stage Boundary, with the risk practice applied inside it.
Scenario A: From Starting Up to the First Stage
Situation. A sponsor has an idea for a new customer-facing product. A Project Manager is appointed and asked to get the project moving.
Correct process sequence.
- Starting Up a Project. The PM assembles a Project Brief, appoints the Project Board and PM, and assembles the team. The output is a request to initiate the project to the board.
- Directing a Project — authorise initiation. The board reviews the Project Brief and authorises initiation.
- Initiating a Project. The PM develops the PID (Project Plan, Business Case, approaches, controls), and produces a request to authorise the project and the next Stage Plan (the initiation stage itself is often authorised separately, after which the first delivery stage plan is produced at the end of initiation).
- Directing a Project — authorise the project and authorise the first delivery stage. The board reviews the PID and the first delivery Stage Plan and authorises the project and that stage.
- Controlling a Stage. The PM assigns Work Packages, monitors work, reports progress, and manages issues and risks within the stage's tolerances.
Exam trap. Initiating a Project does not authorise the first delivery stage — the board does, via Directing a Project. The PM proposes; the board authorises.
Scenario B: A Stage Ending Normally
Situation. A stage is nearing its end. The PM has completed the planned work packages and is preparing for the stage boundary.
Correct process behaviour.
- Managing a Stage Boundary. The PM:
- drafts the next Stage Plan;
- updates the Project Plan with actuals and the latest forecast;
- updates the Business Case and the Benefits Management Approach;
- reviews and updates risks and the Risk Management Approach;
- updates the PID where any baseline has changed;
- compiles the End Stage Report and the request to authorise the next stage.
- Directing a Project — authorise a stage. The board reviews the End Stage Report, the updated Business Case and Project Plan, and the next Stage Plan, and decides: authorise, authorise with conditions, defer, or stop.
- If authorised, the project moves into the next stage and Controlling a Stage resumes.
Exam trap. The PM does not authorise the next stage. The PM produces the request; the board decides.
Scenario C: Premature Closure Mid-Project
Situation. Three stages into a project, a major regulatory change makes the project's product obsolete. The PM forecasts that the project can no longer deliver the business benefits in the Business Case.
Correct process behaviour.
- Controlling a Stage. The PM recognises that the project's continued-business-justification is in question. Because this is a project-level (not stage-level) tolerance issue, the PM raises an Exception Report to the Project Board.
- Directing a Project. The board reviews the Exception Report and decides to stop the project — i.e., authorise premature closure.
- Closing a Project — premature closure path. The PM:
- identifies partial products and which can be salvaged;
- produces Follow-on Action Recommendations for incomplete products;
- hands over any usable products;
- produces the End Project Report explaining why the project was stopped early;
- updates the Benefits Management Approach (some benefits may still be partially realisable from salvaged products);
- captures lessons in the Lessons Log;
- recommends closure to the board.
- Directing a Project — authorise closure. The board formally authorises closure.
Key distinction from normal closure. Premature closure must deal with partial products and produce Follow-on Action Recommendations — these are the distinguishing outputs. A normal End Stage Report is not produced for the abandoned stage; the Exception Report and the board's closure decision replace it.
Scenario D: Mid-Stage Exception Leading to Premature Closure
Situation. During a stage, the PM forecasts that stage cost and time tolerances will both be breached, and there is no realistic recovery plan that stays within the project's overall tolerances.
Correct process behaviour.
- Controlling a Stage. The PM raises an Exception Report (the stage-tolerance breach triggers this).
- Directing a Project. The board considers the Exception Report. Rather than asking for an Exception Plan, the board decides the Business Case is no longer viable and authorises premature closure.
- Closing a Project. The PM follows the premature-closure path as in Scenario C.
Which processes are involved? Controlling a Stage (raised the Exception Report), Directing a Project (board decision to close), and Closing a Project (PM executes closure). Managing a Stage Boundary is not performed, because the stage did not end normally — the project moved from an in-stage exception straight to premature closure.
Integrating Practices and Principles
Each scenario above is more than a process flow — it is also where practices and principles show up:
- The continued business justification principle is tested at every stage boundary (Managing a Stage Boundary updates the Business Case) and at closure (Closing a Project evaluates the Business Case).
- The manage by stages principle is the reason the board re-authorises at each boundary.
- The manage by exception principle is what makes an Exception Report the correct response to a tolerance forecast breach.
- The learn from experience principle is exercised when lessons are captured at closure.
When a scenario asks "what should the PM do next?", the answer is almost always anchored in a specific process. Name the process, then the management product, then the role that decides.
A project has just completed Initiating a Project. The PM has produced the PID, the updated Business Case, and a Stage Plan for the first delivery stage. According to the correct process sequence, what happens next?
A regulatory change mid-project makes the product obsolete. The PM forecasts that the Business Case can no longer be delivered. Which sequence correctly describes the process behaviour that follows?
During a stage, the PM forecasts a stage-level tolerance breach and raises an Exception Report. The board, rather than requesting an Exception Plan, decides the Business Case is no longer viable and stops the project. Which process is NOT performed in this sequence?