10.2 Event-Driven vs. Time-Driven Controls & Exception Reporting

Event-Driven vs. Time-Driven Controls & Exception Reporting in PRINCE2 7

Practitioner Core Mandate: Project Executive leadership on a project board does not manage by attending endless weekly operational meetings or micromanaging delivery tasks. Instead, PRINCE2 achieves rigorous governance through two complementary control mechanisms: event-driven controls (triggered by milestones, transitions, and decisions) and time-driven controls (operating on fixed periodic rhythms). When performance drifts beyond delegated boundaries, the exception mechanism swings into action. Practitioners must master the taxonomy of controls, understand how early warning indicators trigger feed-forward responses, and know how to execute the complete Exception Report and Exception Plan lifecycle.

---

1. Event-Driven vs. Time-Driven Controls: The Governance Matrix

In PRINCE2 7, progress controls are categorised by how they are triggered. Confusing event-driven controls with time-driven controls is a classic exam failure point.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE DUAL ARCHITECTURE OF CONTROLS                       │
├─────────────────────────────────────────────────────────────────────────────┤
│ EVENT-DRIVEN CONTROLS                                                       │
│ • Trigger: Occur when a specific event, milestone, transition, or condition │
│   takes place within the project lifecycle.                                 │
│ • Cadence: Irregular, non-cyclical, demand-driven.                          │
│ • Primary Role: Authorizations, major decision gates, escalations, baselines│
│   (e.g., Authorize Initiation, End Stage Report, Exception Report).         │
├─────────────────────────────────────────────────────────────────────────────┤
│ TIME-DRIVEN CONTROLS                                                        │
│ • Trigger: Occur at predetermined, regular calendar intervals.              │
│ • Cadence: Cyclical, predictable (e.g., weekly, bi-weekly, monthly).        │
│ • Primary Role: Periodic visibility, trend monitoring, steady-state updates │
│   (e.g., Checkpoint Report, Highlight Report).                              │
└─────────────────────────────────────────────────────────────────────────────┘

Mapping Controls Across the Four Organizational Layers

To understand how governance operates, we must map every key PRINCE2 control to its management level and trigger mechanism:

                                MANAGEMENT LEVEL CONTROL MAPPING
   
   CORPORATE / PROGRAMME        Event-Driven: Authorize Project | Mandate Exception Plan
   ───────────────────────────────────────────────────────────────────────────────────────
   DIRECTING (Project Board)    Event-Driven: Authorize Initiation | Authorize Project
                                              Authorize Stage/Exception Plan | Ongoing Direction
                                              Authorize Project Closure | Grant Concession
                                Time-Driven:  Receive Highlight Reports (periodic)
   ───────────────────────────────────────────────────────────────────────────────────────
   MANAGING (Project Manager)   Event-Driven: Authorize Work Package | Review Completed WP
                                              End Stage Report | Exception Report
                                              End Project Report | Log Issues/Risks
                                Time-Driven:  Produce Highlight Reports (periodic)
                                              Receive Checkpoint Reports (periodic)
   ───────────────────────────────────────────────────────────────────────────────────────
   DELIVERING (Team Manager)    Event-Driven: Accept Work Package | Return Completed WP
                                              Raise Work Package Exception / Team Issue
                                Time-Driven:  Produce Checkpoint Reports (periodic)

Comprehensive Cross-Level Controls Matrix

---

2. Managing by Exception in Progress Control

The principle of Manage by exception is the cornerstone of efficiency in PRINCE2 governance. Without it, senior executives are sucked into operational weeds, and project managers are paralyzed by bureaucratic sign-off requirements.

How Manage by Exception Works in Practice

1. Delegation with Clear Boundaries: The Project Board sets the objectives and allocates tolerances (Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability) to the Project Manager.
2. Autonomous Management: As long as progress remains strictly within these tolerances, the Project Manager exercises total autonomy to direct daily operations, reallocate tasks, adjust resources, and implement tactical responses.
3. Preserving Project Executive Time: The Project Board does not hold routine progress meetings. The Board stays informed via periodic, concise Highlight Reports (time-driven control). Board members are free to attend to their substantive operational roles.
4. Immediate Escalation upon Exception: The moment performance drifts—or is predicted to drift—beyond any tolerance threshold, an exception occurs. The PM must immediately notify the Project Board via an Exception Report (event-driven control).

Feedback Control vs. Feed-Forward Control

A critical concept tested at the Practitioner level is the difference between feedback and feed-forward control:

• Feedback Control (Lagging / Historical): Measures what has already happened (e.g., "We spent $40,000 last month against a plan of $30,000"). While useful for accounting, feedback control alone cannot prevent project failure because the damage is already done.
• Feed-Forward Control (Leading / Predictive): Uses current trends, burn rates, supplier data, and risk exposure to forecast what will happen in the future (e.g., "At our current burn rate, we will exceed stage budget by $50,000 in six weeks"). PRINCE2 progress control is fundamentally feed-forward: managers must act based on projected trajectories to avert disaster before it occurs.

---

3. Early Warning Indicators: Detecting Exceptions in Advance

Experienced project practitioners do not wait for milestones to fail before recognizing an exception. They actively monitor early warning indicators across all seven targets:

┌─────────────────────────────────────────────────────────────────────────────┐
│                      EARLY WARNING INDICATORS MATRIX                        │
├─────────────────────────────────────────────────────────────────────────────┤
│ • SCHEDULE SLIPPAGE ON CRITICAL PATH: Float on near-critical activities     │
│   is eroding, pushing secondary paths onto the critical path.               │
│ • TESTING DEFECT CONCENTRATION: Number of failed quality inspections or     │
│   re-test cycles is escalating exponentially, signaling rework delays.      │
│ • SPRINT VELOCITY DECAY: Agile teams deliver fewer story points per sprint  │
│   than estimated, projecting future backlog spillover.                      │
│ • MATERIAL INFLATION & RATE CREEP: Supplier unit costs or specialist labor  │
│   rates drift upwards, eroding cost tolerance margins.                      │
│ • SCOPE CHURN & CREEPING ENHANCEMENTS: Stakeholders submit multiple minor   │
│   queries or change requests that collectively expand deliverable effort.   │
│ • AGGREGATED RISK ACCELERATION: Multiple medium risks emerge simultaneously,│
│   pushing total monetized risk exposure past the stage risk tolerance cap.  │
│ • RUN-RATE SUSTAINABILITY DRIFT: Weekly energy use, shipping freight, or    │
│   scrap material generation projects a breach of the stage carbon ceiling.  │
└─────────────────────────────────────────────────────────────────────────────┘

---

4. The PRINCE2 7 Six-Step Exception Management Technique

PRINCE2 7 section 11.3.1 defines a six-step exception management technique (figure 11.3). It is one of the three named PRINCE2 techniques in the progress practice, and the syllabus tests it under criterion 3.7.1(c). As with the planning, risk, and issue techniques, an alternative procedure may be used — for example, a programme-wide exception procedure — provided the choice is documented as a tailoring decision in the PID. The manual also notes that although the technique refers to reports, systems and data performing the same function are acceptable.

             THE SIX STEPS OF EXCEPTION MANAGEMENT (FIGURE 11.3)

  DELIVERING LEVEL
  ── Step 1 ────────────────────────────────────────────────────────────────
     Team manager forecasts, from work package data, that a product will
     take the WORK PACKAGE outside one of its tolerances.
       └─► Raises an ISSUE to the project manager; captured in the ISSUE
           REGISTER (an ISSUE REPORT if more detail or formality is needed).
       └─► If the project manager can resolve it WITHIN STAGE TOLERANCE,
           NO exception report is created. It is reported in the next
           highlight report, and a note may go in the lessons log.

  MANAGING LEVEL
  ── Step 2 ────────────────────────────────────────────────────────────────
     If stage (or project) tolerance is FORECAST to be breached, the project
     manager creates an EXCEPTION REPORT: the situation, resolution options,
     and a recommendation.

  DIRECTING LEVEL
  ── Step 3 ────────────────────────────────────────────────────────────────
     The project board or project executive chooses among six options:
       • reallocate overall PROJECT tolerance to absorb the stage breach
       • reprioritize requirements to bring the stage back within tolerance
         (de-scoping or re-scoping the product)
       • tell the project manager they need more time to consider
       • implement the report and REQUEST AN EXCEPTION PLAN
       • escalate to the BUSINESS LAYER for advice and direction, if the
         exception would take the project outside project-level tolerance
       • act on the business layer's direction and direct the project
         manager accordingly

  MANAGING LEVEL
  ── Step 4 ────────────────────────────────────────────────────────────────
     The project manager CEASES the current stage and introduces a stage
     boundary to create the EXCEPTION PLAN and adjust related PID content.
     An END STAGE REPORT may also be produced if the stage has progressed
     far enough for that to be useful input to the decision.

  DIRECTING LEVEL
  ── Step 5 ────────────────────────────────────────────────────────────────
     The project board or project executive assesses the exception plan and
     may:
       • reject it and request amendments
       • reject it and direct the project manager to continue with the
         stage (possibly with minor adjustments)
       • approve it and return it for further action

  MANAGING LEVEL
  ── Step 6 ────────────────────────────────────────────────────────────────
     The project manager receives the exception plan with a direction to
     implement it AS A NEW STAGE PLAN — the exception plan becomes the new
     stage plan. The project manager authorizes the next set of work
     packages so delivery can recommence, taking account of the triggering
     issue.

Four details the exam rewards

1. Step 1 does not always produce an exception. A work-package-level forecast breach becomes an issue first. If the project manager can absorb it inside stage tolerance, there is no exception report at all — just a line in the next highlight report and possibly the lessons log. Options that jump from a team manager's warning straight to an exception report are over-escalating.
2. Step 3 includes "reallocate overall project tolerance". The board does not have to demand an exception plan. It can absorb a stage breach out of project-level tolerance, re-scope, ask for more time, or escalate to the business layer. An option presenting the exception plan as the board's only response is wrong.
3. Step 4 stops the stage. The project manager ceases the current stage and enters a stage boundary. Production does not continue in parallel while the exception plan is drafted.
4. Step 6 is where the exception plan becomes the stage plan, and the manual adds a practical point: consider aligning the new stage end with the old one where feasible, so the board's planned end stage assessments do not need rescheduling. A product flow diagram can be used to show progress and remind the board of dependencies.

[!CRITICAL EXAM RULE] The technique runs delivering → managing → directing → managing → directing → managing. Every escalation step changes level, and every decision step sits at the directing level. If an option has a level making a decision that belongs one layer up, it is wrong regardless of how sensible the action sounds.

---

5. The Exception Mechanism: The Complete Lifecycle

When early warning indicators confirm that an agreed tolerance cannot be protected, the formal PRINCE2 exception mechanism is activated. This workflow follows four disciplined steps:

                           THE COMPLETE EXCEPTION LIFECYCLE

   ┌─────────────────────────────────────────────────────────────────────────┐
   │ STEP 1: IDENTIFY & FORECAST                                             │
   │ • PM identifies that an agreed Stage Tolerance is FORECAST to breach.   │
   │ • Golden Rule: Must escalate immediately upon prediction, NOT actual.   │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ STEP 2: DRAFT EXCEPTION REPORT                                          │
   │ • Document root cause, quantified variance, and multi-target impact.    │
   │ • Conduct rigorous OPTIONS ANALYSIS (including 'do nothing'/cancel).    │
   │ • Formulate balanced recommendation and submit to Project Board.        │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ STEP 3: PROJECT BOARD ADJUDICATION                                      │
   │ • Board reviews Exception Report via Give Ongoing Direction.            │
   │ • Decisions: Accept recommendation | Request new options | De-scope     │
   │   deliverables | Grant tolerance uplift | Escalate to business layer         │
   │ • If re-planning required ──► Instruct PM to create EXCEPTION PLAN.     │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ STEP 4: CREATE & AUTHORIZE EXCEPTION PLAN                               │
   │ • PM creates Exception Plan within 'Managing a Stage Boundary' (SB).    │
   │ • Replaces remaining portion of current Stage Plan to stage end.        │
   │ • Project Board authorizes Exception Plan via 'Directing a Project' (DP)│
   │ • Approved Exception Plan becomes the new operational baseline.         │
└─────────────────────────────────────────────────────────────────────────────┘

The Anatomy of an Exception Report

An Exception Report is an executive-level management product prepared by the Project Manager to inform the Project Board of an impending breach and present actionable recovery pathways. An incomplete or superficial Exception Report will be rejected by an experienced board.

Mandatory Sections of an Exception Report:

1. Exception Title & Date: Unique identifier, stage name, and creation date.
2. Cause of the Exception: Root-cause explanation of the events, failures, or discoveries that produced the variance.
3. Current Status & Forecast Variance: Quantified deviation against the baselined Stage Plan across all seven targets (Cost, Time, Quality, Scope, Benefits, Risk, Sustainability).
4. Impact Assessment:
   • Impact on the remainder of the current stage;
   • Cumulative impact on the overall Project Plan and project end date;
   • Impact on the Business Case (e.g., reduced ROI, delayed benefits realization);
   • Impact on project risks and corporate sustainability targets.
5. Options Analysis: Rigorous appraisal of at least two to three viable alternatives. For each option, evaluate financial cost, schedule impact, technical quality, risk profile, and sustainability consequences. (One option must always evaluate the baseline 'do nothing' or 'premature project closure' scenario).
6. Recommendation: The Project Manager's explicit recommendation, detailing why the chosen option represents the optimal balance of business value and risk.
7. Lessons Learned: Operational insights that can prevent recurrence.

Project Board Decision-Making

Upon receiving an Exception Report, the Project Board convenes (or provides ongoing direction electronically). The Board has several governance options:

• Accept the Recommendation: Concur with the PM's proposed solution and instruct the PM to prepare an Exception Plan.
• Select an Alternative Option: Direct the PM to execute an alternative option evaluated in the report (e.g., de-scoping non-critical deliverables rather than extending schedule).
• Grant a Tolerance Uplift: If corporate tolerances permit, the Board may simply increase the stage tolerance (e.g., authorizing an additional $30,000 from project reserves) so delivery can proceed without replanning.
• Escalate to the business layer: If the stage exception causes a breach of overall Project Tolerances, the Project Board lacks authority to resolve it and must escalate to the business layer.
• Premature Project Closure: If the exception fatally destroys the Business Case (e.g., market conditions change or technology becomes obsolete), the Board directs premature project closure.

The Exception Plan: Core Rules and Operational Mechanics

If the Project Board accepts an option requiring formal replanning, it instructs the Project Manager to create an Exception Plan.

Critical Rules of Exception Plans:

• Replaces the Remainder of the Current Plan: An Exception Plan replaces the current Stage Plan from the present moment until the end of the stage. (If project-level tolerances were breached, an Exception Plan replaces the Project Plan).
• Never Rewrites History: An Exception Plan does not alter past actuals. Past costs, completed milestones, and historical defects remain baselined in project archives. The Exception Plan establishes a new forward-looking baseline for the remaining deliverables.
• Process Context:
  • The PM creates the Exception Plan within the Managing a Stage Boundary (SB) process.
  • The Project Board reviews and approves the Exception Plan within the Directing a Project (DP) process (activity: Authorizing a Stage or Exception Plan).
• Becomes the New Baseline: Once formally approved by the Project Board, the Exception Plan immediately becomes the new agreed Stage Plan, complete with newly allocated stage tolerances.

---

6. Practical Scenario Evaluations

Scenario A: The "Post-Mortem" Exception Report

During Stage 3 of a commercial airline baggage-routing overhaul, the stage completion date was baselined for August 15 with a time tolerance of +1 week (August 22). By July 1, the Project Manager realized that baggage sensor testing was running 4 weeks behind schedule. However, the PM hoped the team could make up the time during integration. On August 23—one day after the stage tolerance ceiling expired—the PM submitted an Exception Report to the Project Board stating: 'Stage 3 is officially in exception because our time tolerance expired yesterday.'

Practitioner Evaluation:

• Governance Flaw: Total violation of the feed-forward exception principle.
• Impact: By waiting until the tolerance was actually breached, the PM robbed the Project Board of 7 weeks of decision-making time. The Board could have de-scoped features, approved emergency vendor support, or adjusted flight rollout dates in July. In August, the project faces operational paralysis.
• Correct PRINCE2 Action: The PM must raise an Exception Report the moment a breach is forecast (on July 1). An Exception Report is a proactive warning, not an autopsy.

Scenario B: The Single-Option Ultimatums

A railway signaling upgrade encounters severe underground cabling corrosion, threatening a 2-month delay and $150,000 cost overrun (stage cost tolerance is $50,000). The Project Manager submits an Exception Report containing only one proposed resolution: 'The Project Board must allocate an additional $150,000 and extend the stage deadline by 2 months, or the project will fail.'

Practitioner Evaluation:

• Governance Flaw: Defective Options Analysis in the Exception Report.
• Impact: Presenting an executive board with a single binary ultimatum strips the board of its governance prerogative. An Exception Report must evaluate multiple viable alternatives with transparent trade-offs.
• Correct PRINCE2 Action: The PM must present at least two to three evaluated options. For instance: Option 1: Inject $150,000 and extend the schedule by 2 months (preserves full scope); Option 2: De-scope auxiliary station cabling to secondary tracks, maintaining budget and schedule (retains core passenger safety benefits); Option 3: Terminate the stage and solicit competitive emergency contractor bids. The PM recommends Option 2 with justification, allowing the Board to make an informed executive choice.

Scenario C: Unilateral Production of an Exception Plan

Midway through an e-commerce platform upgrade, a critical cloud hosting vendor raises prices, projecting a 15% stage cost overrun. Recognizing that this will breach stage cost tolerance, the Project Manager immediately spends three weeks halting team development, drafting a 40-page Exception Plan, and reorganizing all Work Packages. The PM then presents the completed Exception Plan to the Project Board for rubber-stamp approval.

Practitioner Evaluation:

• Governance Flaw: Bypassing Project Board authorization to replan.
• Impact: Producing an Exception Plan requires significant time and project expenditure. If the Project Board reviews the situation and decides instead to terminate the project or de-scope features, the PM's three weeks of planning effort are completely wasted.
• Correct PRINCE2 Action: The PM must first submit an Exception Report. Only if the Project Board adjudicates the report, selects an option requiring replanning, and formally directs the PM to produce an Exception Plan does the PM initiate replanning under Managing a Stage Boundary.

---

7. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Classifying Highlight Reports as Event-Driven: Highlight Reports are strictly time-driven controls produced at regular calendar intervals agreed in the Stage Plan.
• Trap 2: Waiting for an Actual Breach Before Raising an Exception Report: An Exception Report must be triggered by a forecast breach. If an exam question describes a PM waiting for the tolerance ceiling date to pass, that choice is always wrong.
• Trap 3: Project Manager Authorizing an Exception Plan: A Project Manager never has the authority to approve an Exception Plan. Only the Project Board can authorize an Exception Plan (via the Directing a Project process).
• Trap 4: Confusing an Exception Report with an Exception Plan: An Exception Report diagnoses the problem, assesses impact, and evaluates options. An Exception Plan is the detailed operational schedule and budget that replaces the Stage Plan if the Board approves replanning.
• Trap 5: Assuming an Exception Plan Erases Past Budget Overruns: An Exception Plan does not rewrite history; it starts from the current operational reality and baselines future remaining work to stage completion.