1) Run a structured plan review
A plan review is a deliberate quality check of your project plan before you start execution. The goal is to find gaps, unrealistic assumptions, and misalignment while changes are still cheap. Treat it like a “pre-flight inspection”: you are not re-planning from scratch—you are validating that what you have is executable.
Plan review agenda (60–90 minutes)
- Inputs: current scope statement, schedule, budget, roles list, assumptions, and any known constraints.
- Attendees: project owner/sponsor, key contributors, and any stakeholder who must approve outcomes or provide resources.
- Outputs: a short list of plan updates, open decisions, and explicit approvals (or conditions for approval).
A. Scope completeness check
Use this to confirm that the plan covers everything needed to deliver the intended outcomes (including “unseen” work that often gets missed).
- Deliverables complete: For each deliverable, ask: “What does ‘done’ look like, and who signs off?”
- Non-deliverable work included: training, documentation, procurement, data migration, reviews/approvals, handover, and support transition.
- Acceptance criteria present: measurable checks (e.g., “report loads in under 3 seconds for 95% of queries”).
- Out-of-scope confirmed: verify that excluded items are understood and not assumed by stakeholders.
Practical step-by-step:
- List top deliverables in a table.
- Add columns: “Acceptance criteria,” “Approver,” “Hidden work needed,” “Open questions.”
- Fill the table live in the review meeting; assign owners to close open questions.
B. Dependency realism check
Dependencies are where plans often fail in execution. Validate that each dependency is real, owned, and timed correctly.
- External dependencies: vendors, other teams, legal/security reviews, procurement lead times.
- Internal dependencies: shared resources, environment availability, data access, approvals.
- Decision dependencies: choices that must be made before work can proceed (e.g., tool selection).
Practical step-by-step:
- Listen to the audio with the screen off.
- Earn a certificate upon completion.
- Over 5000 courses for you to explore!
Download the app
- For each major task, ask: “What must be true before this can start?”
- For each dependency, capture: owner, due date, and what “ready” means.
- Flag any dependency with no named owner as high risk.
C. Estimate reasonableness check
This is not about perfect accuracy; it is about whether estimates are defensible and consistent with constraints.
- Compare to capacity: do assigned people have enough time given other commitments?
- Look for “too smooth” plans: identical durations everywhere can signal guesswork.
- Check review/approval time: approvals often take longer than creation work.
- Validate critical path assumptions: confirm that the tasks driving the end date are truly unavoidable and correctly sequenced.
Practical step-by-step:
- Identify the 5–10 longest or most uncertain tasks.
- Ask the task owner: “What could make this take longer?” and “What would make it faster?”
- Record the top 1–2 drivers of uncertainty per task; these often become risks.
D. Stakeholder alignment check
Alignment means stakeholders agree on what will be delivered, when, at what cost, and how decisions will be made during execution.
- Confirm success criteria: what outcomes matter most (time, cost, quality, compliance, user adoption).
- Confirm trade-offs: what can flex if something changes (scope vs. date vs. budget).
- Confirm approvals: who approves deliverables and who approves changes.
Practical step-by-step:
- Present a one-slide summary: objectives, top deliverables, target date, budget, and top risks.
- Ask each key stakeholder: “What is your biggest concern about executing this plan?”
- Capture concerns as risks, assumptions to validate, or change requests.
2) Create a practical risk register (and connect it to contingency)
A risk register is a working list of what could go wrong (or right), how likely it is, how bad it would be, and what you will do about it. Keep it practical: a short list of the risks that could materially affect schedule, budget, or outcomes.
Risk register fields (simple and effective)
| Field | What to capture | Example |
|---|---|---|
| Risk | Clear statement of the uncertain event | “Security review takes longer than planned” |
| Probability | Low/Med/High (or 1–5) | High |
| Impact | Schedule/budget/quality impact | 2-week delay |
| Score | Probability × Impact (if using numeric) | 4×5=20 |
| Mitigation | Actions to reduce probability | Pre-review checklist; early consult |
| Contingency | Actions if risk occurs | De-scope noncritical features |
| Owner | Person accountable for monitoring and action | Project lead |
| Trigger | Early warning sign | No reviewer assigned by date X |
Step-by-step: build your “top risks” list in 30 minutes
- Step 1: Brainstorm from the plan review. Convert concerns, weak dependencies, and uncertain estimates into risk statements.
- Step 2: Limit to the top 8–12 risks. If everything is a risk, nothing is prioritized.
- Step 3: Rate probability and impact. Use a consistent scale (e.g., 1–5). Define what “5 impact” means (e.g., “>10% budget overrun” or “>2 weeks delay”).
- Step 4: Assign an owner per risk. Owners track triggers and execute mitigations; they are not just “informed.”
- Step 5: Define one mitigation and one contingency. Mitigation reduces likelihood; contingency is your “if it happens” response.
Link risks to schedule and budget contingency decisions
Contingency is not “padding everywhere.” It is a deliberate reserve tied to known uncertainties.
- Schedule contingency: a time buffer placed where it protects the delivery date (often near the end of a critical chain or before a major milestone).
- Budget contingency: a reserve (money or hours) held for risk response, not for scope expansion.
Practical step-by-step:
- Identify the top 3–5 risks that could move the end date or cost.
- Estimate a rough exposure for each (e.g., “If it happens, +10 days”).
- Decide on a contingency approach:
- Option A: Explicit buffers. Add a “contingency task” or “management reserve” line item tied to specific risks.
- Option B: Risk-based milestones. Add intermediate checkpoints (e.g., “Security pre-check complete”) to detect issues early, reducing the need for large buffers.
Rule of thumb: If you cannot explain which risks your contingency covers, your contingency will be questioned (or misused) during execution.
3) Define the tracking approach
Tracking is how you will know—early—whether execution is on course. A good tracking approach is lightweight, consistent, and tied to decisions. It answers: “Where are we vs. plan, what changed, and what do we need from stakeholders?”
A. Choose a progress measurement method
Two common methods are percent complete and deliverable-based tracking. Choose based on the type of work and the level of reporting credibility you need.
| Method | How it works | Best for | Watch-outs |
|---|---|---|---|
| Percent complete | Owner reports progress as a % | Long tasks with measurable progress | Can be subjective; “90% done” trap |
| Deliverable-based | Progress equals completed outputs/milestones | Most small projects; stakeholder reporting | Needs clear acceptance criteria |
Practical step-by-step (recommended): deliverable-based tracking
- Define 8–20 milestones/deliverables that represent real progress.
- For each, define “done” and the approver.
- Track status as: Not started / In progress / Blocked / Done.
- Optionally add “planned date” and “actual date” for each milestone.
B. Set an update cadence
Cadence is the rhythm of updates and decisions. Too frequent wastes time; too infrequent hides problems.
- Weekly (common): best when multiple contributors are active and dependencies exist.
- Twice weekly: useful during critical phases (testing, launch prep) or when risk is high.
- Biweekly: acceptable for low-risk projects with few moving parts.
Practical step-by-step:
- Pick one recurring day/time for status updates.
- Set a deadline for inputs (e.g., “Update your tasks by Tuesday 3pm”).
- Hold a short review meeting (15–30 minutes) focused on exceptions: blockers, slippage, decisions needed.
C. Define a reporting format stakeholders will actually read
Use a single-page format that highlights what changed and what you need from stakeholders.
Example: one-page weekly status
- RAG status: Green/Amber/Red with one-sentence rationale.
- Accomplished this period: 3–5 bullets tied to deliverables.
- Planned next period: 3–5 bullets.
- Top risks/issues: 3 items with owner and next action.
- Decisions needed: who decides, by when, and options.
- Changes: approved changes since last report (scope/date/budget impacts).
Tip: If your report does not drive a decision or action, simplify it.
4) Prepare a simple kickoff-ready package
A kickoff-ready package is a compact set of artifacts that lets the team start execution with shared understanding. It should be short enough to review in a kickoff meeting, but complete enough to prevent “we thought you meant…” confusion.
Kickoff-ready package contents (minimum viable)
- Objectives: 2–5 bullets describing the outcomes and how success will be judged.
- Scope summary: in-scope deliverables and explicit out-of-scope items.
- Schedule snapshot: key milestones with dates, plus the target end date.
- Budget snapshot: total budget (or total effort hours), plus contingency/reserve approach.
- Roles and responsibilities: who owns what deliverables and who approves them.
- Change process: how changes are requested, evaluated (impact on time/cost/scope), and approved.
Step-by-step: assemble the package in under 2 hours
- Step 1: Create a 1–2 page “Project Plan Summary” (template below).
- Step 2: Attach the milestone schedule (one page).
- Step 3: Attach the risk register (top risks only).
- Step 4: Add a simple decision log section (even if empty at kickoff).
- Step 5: Share 24–48 hours before kickoff and request comments in advance.
Practice
A. Execution readiness checklist
Use this checklist to decide whether you are truly ready to start. Mark each item as Yes/No and capture actions for any “No.”
| Area | Checklist item | Yes/No | Action / Owner |
|---|---|---|---|
| Scope | All key deliverables have clear acceptance criteria and approvers | ||
| Scope | Non-deliverable work (reviews, training, handover) is included | ||
| Dependencies | Top dependencies have named owners and due dates | ||
| Estimates | High-uncertainty tasks have documented assumptions | ||
| Alignment | Sponsor and key stakeholders agree on success criteria and trade-offs | ||
| Risks | Top risks have mitigations, contingencies, and owners | ||
| Contingency | Schedule/budget contingency approach is explicit and agreed | ||
| Tracking | Progress method (deliverable-based or percent complete) is defined | ||
| Tracking | Update cadence and reporting format are agreed | ||
| Kickoff | Kickoff-ready package is prepared and shared in advance | ||
| Kickoff | Decision points and escalation path are clear |
B. Draft a concise Project Plan Summary (copy/paste template)
Fill this in and share it with stakeholders. Keep it to one page if possible.
Project Plan Summary (v1.0) Date: [YYYY-MM-DD] Owner: [Name] Sponsor: [Name] Status: [Draft/Approved] 1) Objectives (outcomes) - [Objective 1] - [Objective 2] - [Objective 3] Success measures: - [Metric/criterion] - [Metric/criterion] 2) Scope In-scope deliverables: - [Deliverable A] (Approver: [Name]) - [Deliverable B] (Approver: [Name]) Out of scope (explicit): - [Item not included] - [Item not included] 3) Milestones (key dates) - [Milestone 1]: Planned [date] - [Milestone 2]: Planned [date] - [Go-live/Final delivery]: Planned [date] 4) Budget / Effort - Planned budget/effort: [amount] - Contingency/reserve: [amount or approach] - Key cost drivers/constraints: [1–3 bullets] 5) Roles (execution ownership) - Project lead: [Name] - Delivery owners: [Name → deliverable] - Approvers: [Name → deliverable] 6) Top Risks (with actions) - [Risk 1] | P/I: [H/M/L] | Mitigation: [action] | Owner: [name] - [Risk 2] | P/I: [H/M/L] | Mitigation: [action] | Owner: [name] - [Risk 3] | P/I: [H/M/L] | Mitigation: [action] | Owner: [name] 7) Tracking & Reporting - Progress method: [Deliverable-based / Percent complete] - Update cadence: [weekly on Day] - Reporting format: [one-page status + milestone table] 8) Change Handling - How to request change: [email/form/channel] - Impact assessment: [who estimates schedule/budget/scope impact] - Approval: [who approves and within what time] 
