Applying the processes in scenarios

The seven processes describe who does what, and when, from the first idea for a project to its closure. Practitioner questions use them constantly, because so many questions turn on timing: is this the right moment to produce this product, and is this the right person to do it? This lesson revisits the processes from the scenario angle, using Ridgeline Water's lead service line project as the running case, and practises recognizing which process is running from the clues in a question.

The processes at a glance

Recognizing the process from the clues

Questions rarely name the process. They describe a situation, and you infer the process from the trigger and the actor. A request from the general manager to look at replacing lead lines is a mandate, so starting up a project is next. A completed project brief going to the board means directing a project is deciding whether to authorize initiation. A project manager writing approaches and a project plan is initiating. A team manager accepting a work package is managing product delivery. A project manager preparing a next stage plan is managing a stage boundary.

triggers = {
    "mandate received": "starting up a project",
    "request to initiate": "directing a project (authorize initiation)",
    "initiation authorized": "initiating a project",
    "project and stage authorized": "controlling a stage",
    "work package authorized": "managing product delivery",
    "stage end approaching": "managing a stage boundary",
    "exception plan requested": "managing a stage boundary (exception plan)",
    "forecast breach of stage tolerance": "controlling a stage -> exception report to directing a project",
    "final stage end approaching": "closing a project",
    "premature closure instructed": "closing a project (premature)",
}
events = ["mandate received", "request to initiate", "initiation authorized",
          "project and stage authorized", "work package authorized",
          "forecast breach of stage tolerance", "exception plan requested",
          "stage end approaching", "final stage end approaching"]
for n, e in enumerate(events, 1):
    print(f"{n}. {e:<36} -> {triggers[e]}")

1. mandate received                     -> starting up a project
2. request to initiate                  -> directing a project (authorize initiation)
3. initiation authorized                -> initiating a project
4. project and stage authorized         -> controlling a stage
5. work package authorized              -> managing product delivery
6. forecast breach of stage tolerance   -> controlling a stage -> exception report to directing a project
7. exception plan requested             -> managing a stage boundary (exception plan)
8. stage end approaching                -> managing a stage boundary
9. final stage end approaching          -> closing a project

Starting up and directing

Starting up a project is short and light: appoint the executive and the project manager, capture previous lessons, design and appoint the rest of the project management team, prepare the outline business case, select the project approach, assemble the project brief and plan the initiation stage. Its purpose is to stop poorly conceived projects early and to make sure the board has what it needs to decide whether to initiate. On Ridgeline's lead line project, starting up took three weeks and included a quick check of the inventory data and the smart metering project's lessons log.

Directing a project runs from the request to initiate until the project closes. The board authorizes initiation, the project, each stage and closure; it gives ad hoc direction when asked and responds to exceptions. It does not manage the project day to day. A distractor might have the board writing the PID or approving every work package. In tailored scenarios, directing may be done through short meetings, email decisions or a dashboard, but the authorizations still happen.

Initiating a project

Initiation builds the foundation: the management approaches (risk, quality, change and issues, communication, commercial, digital and data, and others as tailored), the project controls, the project plan, the refined business case and the tailoring of the method, all assembled into the PID. The board then decides whether to authorize the project. Specialist work does not normally start during initiation, though tailored scenarios may allow limited early work, authorized by the board, where delay would be costly.

On the lead line project, initiation produced the regulatory hold points described in lesson 6, the unit-rate commercial approach and a stage plan for the pilot. The board authorized the project and the pilot stage together, which is common: the decision to authorize the project and the first delivery stage can be taken at one meeting.

Controlling a stage and managing product delivery

Controlling a stage is where the project manager spends most time: authorizing work packages, reviewing their status, receiving completed work packages, reviewing stage status, reporting highlights, capturing and examining issues and risks, escalating and taking corrective action. Managing product delivery is the team manager's process: accepting a work package, executing it and delivering it. The interface between them is the work package, and many scenario questions test it: what a work package contains, who agrees it and what happens when a team manager forecasts a breach of work package tolerance (they raise an issue to the project manager).

Managing a stage boundary and closing a project

Managing a stage boundary prepares the board's decision at the end of each stage except the last: the next stage plan, the updated project plan, the updated business case, the review of risks and other PID components, and the end stage report. It also produces exception plans when the board asks for one. Closing a project replaces the boundary in the final stage: the project manager prepares planned closure (or premature closure), hands over products, evaluates the project and recommends closure to the board, which authorizes it.

Two closure details catch candidates repeatedly. First, the project manager recommends closure and the board authorizes it; the business layer is notified. Second, benefits reviews after the project closes belong to the business, through the executive, not to the project manager, whose role ends at closure. The end project report and the benefits management approach make sure the reviews are planned.

When a Canadian municipal project closes, handover often includes updating the tangible capital asset register under public sector accounting standards and transferring records under the municipality's retention schedule. For the lead line project, each replacement's record also goes to the regulator's reporting system.

Tailored processes in scenarios

Scenarios frequently describe tailored processes, and questions test whether the tailoring is legitimate. Combining starting up and initiating on a simple project is legitimate if both purposes are met. Holding stage boundaries as short board calls with a dashboard is legitimate if the board still decides. Merging closing a project into the last stage's boundary meeting is legitimate if acceptance, handover, evaluation and the closure recommendation all still happen. Skipping the boundary between the pilot and the full rollout because the pilot went well is not legitimate, because the board's decision is the point of the boundary.

Process timing questions

Many process questions are really timing questions. They describe an action and ask whether it is happening at the right point in the project. The safest way to answer them is to place the action on a simple timeline: before the mandate, starting up, initiation, a delivery stage, a boundary, the final stage, after closure. Then check which process owns that action and whether its trigger has happened.

Tailored scenarios can shift the timing a little. A combined starting up and initiation may produce the brief and the PID in one piece of work. An agile project may produce next stage release plans as part of continuous backlog refinement, with the formal plan agreed at the boundary. The purpose and the decision point stay the same; the activity is spread differently. When a scenario describes such tailoring, follow it, provided the board's authorizations still happen in the right order.

One more pattern deserves practice: questions about what happens when a process is triggered unexpectedly. If the board instructs premature closure in the middle of a stage, closing a project runs from that point, even though no boundary has been reached. If the board requests an exception plan, managing a stage boundary runs immediately, not at the planned end of the stage.