An approved brief does not control a project until it becomes a measurable scope baseline, a priced cost plan and a logic-linked programme. By the end, you will know which registers, approval gates and monthly measures to require so that scope changes, forecast costs and completion risks remain visible before they become claims or delays.
Key takeaways
- Create a scope baseline with deliverables, exclusions, interfaces and a work breakdown structure.
- Approve changes only after recording their cost, schedule and scope impact.
- Update the estimate at completion instead of relying on the original project budget.
- Link activities, approvals, procurement and commissioning to calculate a credible completion date.
Turn the Approved Brief Into a Scope Baseline
Translate each brief requirement into a deliverable that someone can price, schedule and sign off; a room list or high-level area schedule cannot do that alone. The approved scope baseline combines the scope statement, assumptions, exclusions, interfaces and a hierarchical work breakdown structure.
Build the WBS from project deliverables down to work packages. Stop decomposing when a package has one accountable owner, a measurable output and a clear completion test. Record these fields for every package:
- Package description and boundary: what is included, excluded and supplied by others
- Owner and responsible contractor or consultant
- Quantity, specification, drawing or performance requirement
- Acceptance criteria, inspection record and approving party
- Budget code, estimate basis, allowances and procurement route
- Schedule activity, required predecessor information and planned dates
- Interfaces with adjacent packages, including inputs, outputs and handover points
Price each package against its defined quantity and quality, rather than applying a broad rate to an undefined area. Schedule its design, procurement, installation, testing and handover activities; otherwise long-lead equipment and commissioning disappear from the plan.
Obtain client approval against the complete package register, not just a narrative brief. Freeze the approved version with a revision number, date and decision record. After that point, a new requirement, omitted item or changed performance standard enters change control, while an unclear package returns for clarification before pricing or construction.
Separate Scope Creep From a Valid Change
A request becomes scope creep when it adds work outside the approved scope baseline without a recorded decision, price or time adjustment. Classify it before instructing a contractor, because an informal “small” change can move package responsibility, trigger rework and become a disputed claim.
1. Compare the request with the signed drawings, employer’s requirements, specifications, exclusions and package matrix. If the deliverable already belongs to the baseline, reject it as scope creep or issue it as clarification; do not pay twice for work already included.
2. Label unresolved detailing as design development when it refines an approved outcome without changing its function, quantity or performance. A coordinated door schedule or final MEP route can fit this category; an extra room, higher capacity or upgraded finish cannot.
3. Record a site condition when physical evidence differs from the information provided for pricing, such as undocumented services, contaminated soil or inadequate existing structure. Verify it with photographs, surveys, test results and the contract’s notice requirements.
4. Treat a new law, authority direction or utility requirement as a statutory change, then check the contract for entitlement. Treat a contractor request as a claim only after testing its cause against the contract, records and notice obligations.
5. Require a change request before work starts. Record its reason, drawings, estimate, programme effect, quality and procurement effects, affected packages, responsible party, approval authority, funding source and status. Approve, reject or defer it in the change-control log, then update the scope baseline, budget, programme and package matrix together. No approval means no instructed change.
Control the Budget From Estimate to Final Forecast
A budget becomes a control tool only when its basis is documented. Record the scope definition, measurement rules, pricing date, estimate class, design status, exclusions, procurement route, taxes, owner-supplied items and escalation assumption in the cost plan. Without these, a later increase could be scope growth, market movement or estimating uncertainty rather than an overrun.
| Control | Required record | What it tells you |
|---|---|---|
| Approved budget | Element, package, allowance, tax and contingency baseline | What the client authorised |
| Committed cost | Signed contract, purchase order, approved variation and unpaid commitment | What the project is already obliged to spend |
| Actual cost | Invoice, payment certificate, accrual and cost-code record | What has been incurred or certified |
| Forecast at completion | Cost to date, commitments, remaining estimate and risk allowance | What the finished project is expected to cost |
Keep design contingency separate from client contingency and the contractor’s risk allowance. Identify each allowance, its owner, trigger, value and remaining balance; otherwise the same risk can be funded twice or not at all. Treat provisional sums as unresolved scope, not free money, and replace them with priced work when defined.
Update the forecast monthly using the same work breakdown structure as the approved budget. Reconcile certified value, physical progress, committed cost, actual cost and forecast-at-completion as separate fields. Maintain a change-control log linking each approved change to its estimate, decision, affected package and revised baseline.
This preserves the difference between an authorised change and genuine cost variance.
Build a Programme That Shows the Real Completion Date
Set completion at the point when the asset can be occupied and operated, not when the last construction task finishes. Build the construction schedule as a logic-linked network from the work breakdown structure, with calendars for labour, access, shutdowns and authority reviews.
Break every long-lead package into visible activities:
- Freeze the performance specification and issue the technical submittal.
- Complete consultant and client approval.
- Show fabrication, factory testing, shipping, customs clearance and delivery.
- Allow for storage, installation, testing and commissioning.
- Link integrated systems testing, statutory inspection, training, O&M manuals, as-builts, snag closure and handover to completion.
Then test the network, not just the stated critical path. Review total float, near-critical paths, resource conflicts, restricted access windows, approval durations and calendars; a non-critical activity with little float can become critical after a modest delay. Run delay scenarios for late equipment, rejected submittals and failed commissioning, and record mitigation owners and early-warning dates.
Track planned value against earned progress, certified value, actual cost and forecast-at-completion in the monthly programme report. Physical progress or payment certification does not prove operational readiness. Require a change-control log to show each approved or rejected change’s affected package, decision date and schedule impact, then update the baseline only after authorisation.
This prevents an unrecorded design decision from appearing later as a contractor delay or claim.
Require a PMC to Make Decisions and Performance Traceable
Require a fixed monthly control pack with named owners, dates, decisions and evidence, not a narrative report. It must make scope, cost, schedule, interfaces and contractual risks actionable before the next payment cycle.
- A scope and change register showing each work package, owner, acceptance criteria, approved budget, schedule activity, requested change, reason, cost impact, time impact, affected packages, approval authority and status.
- A monthly cost report separating approved budget, client contingency, contractor risk allowance, actual cost, committed cost, certified value, forecast-at-completion and remaining risk. Do not merge contingency with contractor allowance.
- A commitment register listing every purchase order, subcontract, variation, retention, unpaid obligation, forecast exposure and budget code. This exposes liabilities that the ledger has not yet paid.
- A progress dashboard separating physical progress, payment certification, earned value, procurement status, commissioning, approvals, defects and forecast completion. High installed quantities do not prove operational readiness.
- A current programme with critical-path movement, late approvals, procurement constraints, recovery actions, responsible owners and the cost, congestion, rework and safety consequences of acceleration.
- An interface register covering structure-to-façade tolerances, MEP builder’s work, BMS points, fire strategy, specialist equipment and utility capacity, with an owner, information due date, verification method and consequence.
- A contract-risk and claims log recording notice dates, entitlement, evidence, responsibility, response deadline and likely exposure.
Cube Buildwell should be judged by whether its PMC team can trace each recommendation from source document to decision, baseline update and accountable action. Review the pack in a decision meeting and close actions with dated evidence.
Related product
 | Project Management Consultancy (PMC) Project Management Consultancy (PMC) Cube Build Well offers comprehensive Project Management Consultancy services designed to ensure successful project execution from concept to... View product → |
Frequently asked questions
What belongs in a project scope baseline?
Include the scope statement, priced deliverables, assumptions, exclusions, interfaces and a hierarchical work breakdown structure. A room list or area schedule alone is not enough to price, schedule or sign off the work.
How do you distinguish scope creep from a valid change?
Compare the request with the approved baseline. Treat work outside the baseline as a change and record its reason, cost, programme impact, design responsibility and approval before execution.
How should a PMC control the project budget?
Track the approved budget against committed costs, actual costs, pending changes, risks and the estimate at completion. A final forecast must show whether remaining funds cover the work still required.
What makes a construction programme show the real completion date?
Include design approvals, procurement lead times, long-lead items, access constraints, inspections, testing, commissioning and handover. Link activities with logic and update actual progress against the critical path.
