6.2.4: Step 4 - Design the Change and Escalation Protocol

Purpose of This Step

In every project—no matter how well planned—things will change.

Tasks run late. Scope expands. A stakeholder asks for “just one more thing.” Unless these changes are tracked and escalated through a structured process, they often lead to:

• Missed milestones
• Budget overruns
• Team burnout
• Stakeholder distrust

This step ensures your project has a clear, transparent, and proactive system for managing scope or schedule deviations and escalating risks before they cause failure.

What You’re Building

You will design a simple control protocol that shows:

• When a risk or issue needs to be flagged
• How escalation works (who to tell, when, how)
• What decisions or approvals are required
• How change is logged and monitored over time

You’ll express this as:

• A flowchart, escalation matrix, or decision tree
• A written procedure or table describing who does what
• A practical guide your team could actually follow

Step-by-Step Instructions

1. Identify What Should Be Escalated

Start by defining the types of issues or changes that require formal attention.

Common Escalation Triggers:

Category	Trigger
Schedule	Task is >3 days behind planned finish date
Scope	New feature request or deliverable not in original WBS
Risk	A blocker cannot be resolved within the team
Approval Delay	A key milestone can’t proceed due to stakeholder unavailability
Resource Conflict	Key team member is pulled to another project or becomes unavailable

2. Define Escalation Thresholds

Be clear about when an issue should be escalated.

Example Thresholds:

Issue Type	Escalate If…
Delay	More than 10% of scheduled duration has passed with no progress
Incomplete Deliverable	Missed by >1 week with no recovery plan
Scope Change	Impacts timeline, cost, or deliverables
Stakeholder Unavailable	Approval or input needed in <5 days and contact has failed

3. Build the Escalation Flow

Create a simple, scannable decision path or escalation ladder.

Example Flow:

[Team Member Identifies Issue]
        ↓
[Team Lead Logs It in Tracker]
        ↓
[PM Reviews Severity]
        ↓
If HIGH impact → PM escalates to Sponsor
If LOW impact → PM resolves in team
        ↓
[Decision is documented and status is updated]

OR present as a ladder:

Level	Role	Example Action
Level 1	Task Owner	Identifies issue and flags to team lead
Level 2	Team Lead	Confirms issue, updates log
Level 3	Project Manager	Assesses impact, escalates if needed
Level 4	Sponsor / Steering	Approves scope/budget changes or deadline shifts

4. Create a Change Log Format

Build a table (or Notion board, Google Sheet, etc.) to record each change or escalation. Include:

Field	Purpose
Change ID	Unique number or label
Date Identified	When issue was logged
Description	What happened or what’s being requested
Type	Scope, Schedule, Resource, etc.
Impact	None / Low / Medium / High
Escalated To	Who owns the decision
Decision / Outcome	Approved / Denied / Adjusted
Date Resolved	When the issue was closed

Bonus: add a column for “Linked Deliverable” or “Impacted Milestone”

5. Document or Visualize the Process

Make the protocol usable:

• Create a short 1-page summary
• Build a flowchart with swimlanes
• Include it as a reference in your team working agreement or kickoff guide

Example (Summary Format):

“If a task is delayed by more than 3 days, the responsible team member must log the issue and notify the team lead. If the impact is rated ‘Medium’ or higher, the PM will escalate to the project sponsor within 2 business days. All changes must be logged in the Change Log.”

Why This Step Matters

Projects don’t fail when issues happen.
They fail when no one acts on them in time.

A simple, clearly owned escalation process will:

• Reduce firefighting
• Improve trust between teams and sponsors
• Ensure approvals happen fast and visibly
• Protect your scope, schedule, and team morale