PEPJune 20265 min read
Most clients know they need a project schedule. Fewer know they need a Project Execution Plan — and fewer still know what the difference is, or why it matters.
A schedule tells you when things are supposed to happen. A Project Execution Plan (PEP) tells you who is responsible for making them happen, what the decision-making process is when they do not, how risks are managed, how procurement will be run, and what "done" looks like at every stage. The schedule is a single component of the PEP. Without the rest of it, the schedule is just a chart on a wall.
This article walks through what a PEP contains, why each section matters, and what its absence means for your project.
The Project Execution Plan is the single governing document for a construction project. It is produced before the contractor is appointed — ideally before tender goes out — and it establishes the framework within which the entire project will be managed.
It is not the contractor's construction programme. It is not the architect's design programme. It is the client's management framework, produced by the client's project manager, setting out how the project will be planned, procured, supervised, and closed out.
Once agreed, it becomes the baseline against which all decisions are made. Instructions that fall outside its scope get escalated. Variations that affect its programme get assessed. If a dispute arises, the PEP is the first document a lawyer asks for.
A well-structured PEP covers seven areas:
1. Project overview and objectives. The client's brief summarised into measurable objectives: area, specification standard, budget, completion date, and any project-specific constraints. This section exists to prevent scope creep before it starts. If the objectives are written down and agreed, any proposal to change them can be assessed against them.
2. Scope definition and exclusions. What is in scope and — critically — what is not. Exclusions are as important as inclusions. "Furniture and loose fittings by client" is an exclusion. "IT infrastructure by others" is an exclusion. Any exclusion that is not written down will eventually be claimed by the contractor as additional work.
3. Project organisation and responsibilities. A responsibility matrix identifying who has authority to approve, instruct, or certify at each project stage. Who approves variations above US$10,000? Who certifies monthly payment applications? Who has authority to issue a stop-work instruction? These questions have obvious answers until the moment there is a dispute — and then they matter enormously.
4. Programme and milestones. The master programme at milestone level: design freeze dates, tender issue, contractor appointment, mobilisation, construction stages, practical completion, and final handover. This is not the contractor's detailed construction programme — that comes later. This is the client's view of the project timeline, which the contractor's programme must sit within and support.
5. Procurement strategy. How will the project be procured? Single main contractor with domestic sub-contractors? Separate contracts for fit-out and MEP? What pre-qualification criteria apply? What evaluation methodology will be used? The procurement strategy shapes the entire risk profile of the project. A client who has not decided this before going to tender is handing the contractor a negotiating advantage.
6. Risk register. Every identified risk, assessed by probability and impact, with a named owner and a mitigation action. The risk register is a live document — it is reviewed and updated at each project stage. Its value is not in identifying risks everyone already knows about. Its value is in assigning ownership and tracking mitigation so that when a risk materialises, it is not a surprise.
7. Reporting and communication protocols. How often does the project manager report to the client? What does the weekly report contain? What triggers an ad-hoc escalation? Who does the contractor send RFIs to, and what is the response timeframe? Communication failures are responsible for a disproportionate number of construction disputes. The PEP defines the protocol before the confusion starts.
The PEP takes time to produce. On a straightforward corporate fit-out, a thorough PEP typically takes two to three weeks to develop, review, and finalise. Under pressure to start, clients and project managers routinely skip it or produce a summary that covers the schedule and nothing else.
The cost of that shortcut arrives in several forms:
Scope disputes. When scope boundaries are not written down, contractors interpret ambiguity in their favour. "Was the electrical distribution board upgrade in scope?" If the answer is not in the PEP, the client is arguing from memory. The contractor is arguing from a bill.
Unauthorised decisions. Without a defined responsibility matrix, project decisions get made at the wrong level. A site engineer approves a material substitution that should have gone to the client. A consultant signs off on a variation that exceeds their authority. By the time the client finds out, the work is done and the contract clause that would have protected them has already been waived by implication.
Programme drift that no one owns. When the master programme exists only in the contractor's head, slippage is always someone else's problem. The PEP creates a baseline that belongs to the client. Variance against it is a project management issue, not a negotiation.
Before a single contractor arrives on site, the client should have in their hands:
These are not bureaucratic requirements. They are the documents that determine whether the client or the contractor controls the project. In their absence, the contractor controls it.
Describe what you're working on and we'll tell you where independent management adds the most value.