Project Execution Plan: Template and Worked Example

Signs your project execution is drifting

Most projects don't fail in one dramatic moment. They drift, one unclear decision at a time. If you notice any of the signs below, the fix is a specific section of the execution plan.

If two or more of these signs sound familiar, you don't need a new project plan. You need the execution rules that should have come with the old one.

• Nobody is sure who decides. Two managers give opposite answers, or a decision waits a week because nobody feels allowed to make it. Fix it with the Organization and RACI section and the approval thresholds in Change control.
• Scope changes slip in without approval. A "small" request from a stakeholder becomes two weeks of work that nobody signed off. Fix it with Change control: a request form, an impact check and a named approver for each level of change.
• Delays surface too late. The team knew about a slipping milestone for weeks, but the sponsor finds out at the deadline. Fix it with Communication and reporting and Risk management, which set a fixed reporting rhythm and a trigger that sends a risk to the steering group.
• Nobody agrees on what "done" means. A deliverable is "finished" for the team and "not acceptable" for the client. Fix it with Quality standards and Handover and closure, which attach acceptance criteria and a sign-off to every deliverable.
• The plan and reality no longer match. Dates moved after approved changes, but the document still shows the old ones. Fix it with a baseline and version numbers, covered in Tracking execution against the plan.

What is a project execution plan?

A PEP is the rulebook for delivery. The project plan says what you will build and why. The execution plan says how the team will run the work day to day: roles, decision rights, schedule baseline, quality checks, reporting and change control. It is often confused with three nearby documents.

Construction, oil and gas, mining, infrastructure, manufacturing, public projects and large IT programs use PEPs most. A small project with one team and no external stakeholders rarely needs one: a task list and a weekly check-in will do. Write one when several teams, a client, a budget holder or a contract depend on the same delivery.

• Project plan: covers the full life cycle, including initiation and closure, and usually comes before approval.
• Implementation plan: focuses on putting a solution into use, such as training, cutover and go live. It can sit inside the execution plan as one phase.
• Work plan: lists tasks, owners and dates. It is the detailed schedule the execution plan refers to, not the governance around it.

Project execution plan template: the sections to include

Use these sections in this order. For a typical business project, each one fits on half a page to a page.

In construction, the plan also covers procurement and contracts, health and safety, and sustainability, which is why those plans run much longer.

• Purpose and objectives: two or three measurable outcomes the project must reach, copied from the business case.
• Scope: what is in, what is out, and the main deliverables.
• Organization and RACI: sponsor, steering group, project manager, workstream leads, and who is responsible, accountable, consulted and informed for each deliverable.
• Schedule and milestones: phases, dated milestones and the critical dependencies between them.
• Resources and budget: people, tools, vendors and the budget by phase, with who can approve spend.
• Quality standards: acceptance criteria for each deliverable and who checks them.
• Risk management: the top risks, their owners, and the trigger that moves a risk to the steering group.
• Change control: how a change is requested, assessed and approved, with thresholds. For example, the project manager approves changes under one week of delay, the sponsor above that.
• Communication and reporting: what report goes to whom, how often, and in what format.
• Handover and closure: how deliverables are accepted and transferred.

Worked example: IT migration execution plan

Here is a condensed plan for a company moving its shared files from on-site servers to a cloud storage platform. The durations are illustrative. The execution phase runs 14 weeks.

The schedule runs in five blocks: weeks 1 to 3 to audit folders, clean duplicates and map permissions; weeks 4 to 6 for a pilot with one department and its fixes; weeks 7 to 10 to migrate department by department; weeks 11 to 12 for the final sync, the cutover weekend and the support desk; weeks 13 to 14 to decommission servers and close the project.

• Objectives: all departments working from cloud storage by the end of week 12, old servers switched off by the end of week 14, no lost files at cutover.
• Scope: file migration, permissions mapping, user training, server decommissioning. Out of scope: email and the finance system.
• Organization: the IT director is sponsor and accountable for go live. The infrastructure lead is responsible for migration. Department heads are consulted on folder structure. All staff are informed through weekly updates.
• Top risks: permissions copied wrongly (owner: infrastructure lead), staff keep saving to old drives (owner: department heads), cutover overruns the weekend (owner: project manager).
• Change control: any change that moves a department's migration date goes to the sponsor. Anything smaller is decided by the project manager and logged.
• Reporting: a weekly one-page status with traffic lights per department, and a monthly steering meeting with the risk register and budget burn.
• Phase gate criteria: the pilot passes when the pilot department works from the cloud for a full week with no blocking ticket open.

How long should a project execution plan be?

Length follows complexity, not ambition. The rule of thumb: long enough to cover the ten sections, short enough to read in one sitting. Use the markers below.

A good test: can your sponsor read it once and answer "who approves a two-week delay?" If not, the plan is either too long or missing change control.

• One team, internal project: skip the full PEP. A short summary with milestones, RACI and reporting rhythm is enough.
• Several teams or a vendor involved: the ten sections above, each kept to the point.
• Client contract, regulated work or capital project: a longer document, with appendices for procurement, safety and quality.

Presenting the plan for approval

Your steering group will not read every page in the meeting. Open with a one-page view: objectives, phases with milestone dates, the top three risks and the decisions you need from them today. Keep the full document as the reference behind it.

Who writes it? The project manager owns the document and drafts it. Workstream leads write their own sections, and the sponsor approves it. Ask for sign-off in writing, then label the approved version as the baseline. Every later change to dates, scope or budget should point back to that baseline, so nobody argues about what was agreed.

Tracking execution against the plan

The plan only works if reporting follows it. Pick a small set of indicators you can update in minutes: milestones hit on time, open change requests, top risks by status, budget spent against plan, and blocked deliverables.

Hold the same meetings on the same days. A weekly team status keeps work moving, a monthly steering review handles decisions and escalations, and a phase gate review checks acceptance criteria before the next phase starts. When an approved change moves a milestone, update the plan the same week and raise the version number.