Applying the practices in scenarios

The seven practices are the aspects of project management that must be addressed continually: business case, organizing, plans, quality, risk, issues and progress. Practitioner questions test them in context. A typical question gives a situation, such as a supplier reporting a defect, a sponsor asking for a new feature or a forecast showing a cost overrun, and asks what the appropriate response is, which product should be updated or who should decide. This lesson revisits each practice from the scenario angle, using the five-step method from lesson 8.

The practices as a set of questions

Each practice answers a question the project must keep asking. Thinking of them as questions makes classification, step 2 of the method, much quicker.

Business case in scenarios

Business case questions usually turn on three points. First, the business case is owned by the executive, though the project manager may write and update it. Second, it is updated at stage boundaries, at exceptions and at closure, using the latest forecasts. Third, benefits are often realized after the project closes, so the benefits management approach must say who measures them and when. A distractor might have the project manager owning benefits reviews after closure, or the business case frozen at initiation.

Scenario cue: at the digital card's stage 2 boundary, sign-ups in user testing take twice as long as planned for patrons over 70. That affects the benefit of reducing branch sign-up workload and the equity target. The response is to update the business case and the benefits forecast and to present options to the board, not to ignore the finding or quietly lower the target.

Organizing in scenarios

Organizing questions test who holds which role, what each can decide and how stakeholders are engaged. The executive owns the business case and is ultimately accountable. The senior user specifies needs, provides user resources and ensures benefits can be realized. The senior supplier provides supplier resources and is accountable for the quality of what suppliers deliver. Project assurance is independent of the project manager. Change authority is set by the board and can be delegated. Look for scenario details such as combined roles and delegated authorities before answering.

Plans in scenarios

Plans questions often concern levels and timing. The project plan covers the whole project and is updated at each boundary. A stage plan is produced near the end of the previous stage. Team plans are optional and belong to team managers. Exception plans replace the plan they cover once approved. Product-based planning comes before activity planning. A distractor might suggest detailed stage plans for all stages at initiation, or a team manager changing the stage plan.

Quality in scenarios

Quality questions distinguish quality planning (agreeing expectations, acceptance criteria and product descriptions) from quality control (checking products against criteria) and quality assurance (independent checks that the project's approach is appropriate and followed, often from outside the project). Project assurance is not the same as quality assurance, although the two may overlap. A product that fails a quality check is reworked by the team; a product that will not meet its specification is an off-specification, an issue. The quality register records planned and actual quality activities.

Risk in scenarios

Risk questions test the difference between risks (uncertain future events) and issues (things that have happened), the use of the risk budget for responses to specific risks, and appropriate responses: for threats, avoid, reduce, transfer, share, accept or prepare a contingent plan; for opportunities, exploit, enhance, share or reject. The risk owner manages a risk; the risk actionee carries out a response. A distractor might use change budget to fund a risk response, or call an event that has already happened a risk.

Issues in scenarios

Issue questions are among the most common. An issue is any event that has happened, was not planned and requires management action: a request for change, an off-specification, or a problem or concern. The project manager captures and examines issues, recommends a response and decides or escalates depending on tolerance and authority. Changes are funded from the change budget if one has been set. Issues that can be handled informally may go in the daily log; others go in the issue register and may need an issue report.

def route(issue_type, cost_k, within_stage_tolerance, pm_limit_k=3, board_limit_k=50):
    if issue_type == "problem" and within_stage_tolerance and cost_k <= pm_limit_k:
        return "project manager: corrective action"
    if issue_type in ("request for change", "off-specification"):
        if cost_k <= pm_limit_k:
            return "project manager (delegated change authority)"
        if within_stage_tolerance and cost_k <= board_limit_k:
            return "project board (or its delegated change authority) via issue report"
    if not within_stage_tolerance:
        return "exception report to the project board"
    return "project board via issue report"

cases = [
    ("wallet pass certificate", "request for change", 4.5, True),
    ("kiosk screen too low for wheelchair users", "off-specification", 2.0, True),
    ("vendor sprint slips one week", "problem", 1.5, True),
    ("SMS alerts for non-smartphone users", "request for change", 35, False),
]
for name, kind, cost, ok in cases:
    print(f"{name:<44} -> {route(kind, cost, ok)}")

wallet pass certificate                      -> project board (or its delegated change authority) via issue report
kiosk screen too low for wheelchair users    -> project manager (delegated change authority)
vendor sprint slips one week                 -> project manager: corrective action
SMS alerts for non-smartphone users          -> exception report to the project board

The routing rules are a simplification, but they capture the logic of most issue questions: decide what kind of issue it is, then check authority and tolerance. The certificate is a request for change above the project manager's 3 thousand limit but within tolerance, so it goes to the board or its delegated change authority. The kiosk height error is a small off-specification the project manager can resolve. The sprint slip is a problem within tolerance, handled by corrective action. The SMS feature would breach stage tolerance, so it needs an exception report.

Progress in scenarios

Progress questions test tolerances, controls and reports. Time-driven controls include highlight and checkpoint reports; event-driven controls include end stage reports, exception reports and issue reports. The project manager uses the daily log, registers and checkpoint reports to monitor progress and forecasts against stage tolerances. When a forecast breach appears, the project manager raises an exception report promptly, even if recovery seems possible later. The board responds by approving an exception plan, asking for more information, or, if project tolerance is threatened, referring to the business layer.

In US public-sector projects, the issue and change control rules often have to reflect council's or the board's delegated authority ordinance. A change within the project's tolerance may still need council approval if it changes a contract above a set value, so the project's change authority cannot exceed the organization's own delegation.

Practices interacting in one situation

Real situations rarely involve one practice at a time. When the treatment plant contractor found rock in the UV building excavation (lesson 5), the issue touched almost every practice. It was an issue (a problem with a cost), it affected progress (a forecast breach of stage tolerance), it changed the plan (an exception plan was needed), it drew on the risk practice (the ground conditions risk had been on the register, with a response that had not covered rock at that depth), it affected the business case (contingency use and a possible delay to benefits), it involved organizing (the contractor's senior supplier had a conflict of interest) and it involved quality (the revised foundation design needed review and approval).

Practitioner questions sometimes ask which practice or product is most directly affected, or which should be updated first. The usual answer follows the flow of events: capture and examine the issue, check tolerances (progress), escalate if needed, then update plans, business case and risks as the board directs. Thinking through the sequence like this is often faster than searching the manual for each practice separately.

It also explains why some exam options are partly right. An option that says 'update the risk register' is not wrong in itself, but if the question asks what the project manager should do first after a forecast breach, the exception report comes before the register update. Reading the stem for words such as first, next and most directly is part of step 5 of the method.