Project management
Project baseline: scope, schedule and cost
The approved finish is day 20. The forecast says day 22. Keep both visible so the sponsor can decide what to change and the team can explain what happened.
A project baseline is the approved reference the team uses to compare delivery with its commitment. Teams commonly keep connected references for scope, schedule and cost. APM defines a baseline as a reference against which performance can be monitored or controlled.
The project manager can update a forecast as new information arrives. Changing the approved commitment needs the agreed authority and change record.
Our project status report contains exactly that situation: an approved day-20 finish and a current day-22 forecast. Keeping those figures apart gives the sponsor a decision to make.
Start with what the team agreed to deliver
In this fictional case, the team must deliver an order-status portal, including integration, training, acceptance and handover. The approved plan allows twenty working days and €20,000.
The scope reference describes those accepted outputs and their boundaries. The schedule places the work and milestones on the agreed calendar. The cost reference records the approved budget against the work; a team doing earned-value analysis would also need its time-phased budget.
| Reference | What it records here | What it prevents us from overlooking |
|---|---|---|
| Scope | A usable portal with integration, training, acceptance and handover | Treating the completed build as the whole delivery |
| Schedule | Approved finish on working day 20 | Quietly moving the commitment when work runs late |
| Cost | Approved €20,000 budget | Comparing spending with an unapproved forecast total |
These references need to agree. A schedule that omits acceptance cannot support the scope promise, even if someone has approved its dates.
The work breakdown structure helps define outputs before scheduling. Its warehouse example is separate from this portal case.
Compare baseline, actuals and forecast on the same date
At the end of day 15, the build has passed review. Four days of validation, two of training and one of acceptance remain. Under the example's sequential-work assumption, the finish now falls on day 22.
The team has incurred €12,000 and forecasts another €11,000 to finish. The expected total is €23,000. That forecast does not revise the €20,000 approval.
| Measure at day 15 | Approved reference | Recorded or current estimate |
|---|---|---|
| Finish | Day 20 | Forecast day 22 |
| Total cost | €20,000 | €12,000 incurred + €11,000 remaining = €23,000 |
| Acceptance | Agreed scope and conditions | Six of ten requirements have acceptance evidence; four remain open |
Six accepted requirements do not establish 60% of the effort or value. The team must inspect the remaining work, which may contain difficult integration checks.
Keep actual spending, remaining cost and forecast total in separate fields. Adding the actual cost to a forecast that already includes it would count the same money twice.
Change a baseline through an explicit decision
The status-report Note extends the case to day 16. It assumes the sponsor has authority, reviews the evidence and approves the day-22 finish and €23,000 budget in decision D04.
The project manager can then update the authorised references. Retain the former baseline, approval date, decision owner and reason so the next report can explain the change.
| Point in the record | Approved finish and budget | Forecast |
|---|---|---|
| Day-15 report | Day 20; €20,000 | Day 22; €23,000 |
| After authorised D04 on day 16 | Day 22; €23,000 | Review against remaining work and current evidence |
Approval does not prove the new forecast will hold. Additional defects could change it again. The change-control example shows how the team evaluates an altered commitment before agreeing to it.
Avoid replacing the reference merely because the current comparison looks poor. That would remove the history the sponsor needs to assess performance and earlier decisions.
Establish a baseline people can use
Before approving one, connect the scope to the work, check dependencies and staff availability, agree acceptance conditions and record the authorised dates and budget. Identify the version the team should use.
Choose detail that supports the decision. An early approved stage can coexist with later work that still needs definition, provided the authority and limits are explicit. A baseline is not evidence that every future task is already known.
For the next status report, put the approved reference, current forecast and reporting date side by side. If they differ, name the decision needed and preserve the record of what the sponsor approves.
Sources and example notes
- APM: project terminology, baseline, baseline cost and baseline dates.
- The existing portal status report, the fictional day-15 figures and separate D04 approval extension reused here.
All costs, days, acceptance counts and decisions are fictional teaching inputs. Day 22 assumes sequential remaining work and available resources, with no extra defect rework. The example does not calculate earned value or establish a general approval policy.