A planned-versus-actual project margin review compares the approved resource, hours, cost, and margin baseline with delivery data recorded for the same period and on the same cost basis. Review hours by resource before the overall percentage: a small total-hours variance can still hide an expensive role-mix change. Treat the current result as an observation, not a final-margin forecast.
What belongs in the approved baseline?
The baseline is the reference point accepted before delivery. It should preserve enough information to explain the planned margin rather than storing only a percentage.
- approved project or purchase-order budget;
- roles, named resources when available, and planned hours by period;
- the rate and cost-component policy used for the plan;
- included non-labour and shared-cost assumptions;
- scope, duration, and any approved exclusions;
- the date and reason for later approved baseline changes.
The resource-loading pricing example shows how a fixed-price baseline can begin with explicit role and cost assumptions.
Compare like with like
If actual hours cover the first six weeks, compare them with the hours planned for those six weeks—not the entire project. If a rate changed during delivery, cost the period using the policy that applies to that period. If the revenue or cost definition changes, label the new basis rather than silently comparing it with the old one.
PMI cost variance is earned value minus actual cost. A project-margin variance compares margin calculations. These answer related management questions, but they are not the same formula and should not share a label.
Worked example: why role mix matters
Continue the illustrative three-role project from the pricing example. After six weeks, the approved plan expected 420 hours and USD 19,800 of labour for the period. The project records 432 actual hours—only 12 hours above plan—but the cost difference is larger because more senior-consultant time was used.
| Role | Planned hours | Actual hours | Hours variance | Planned labour | Actual labour |
|---|---|---|---|---|---|
| Consultant at USD 60/hour | 120 | 132 | +12 | USD 7,200 | USD 7,920 |
| Senior consultant at USD 90/hour | 60 | 75 | +15 | USD 5,400 | USD 6,750 |
| Analyst at USD 30/hour | 240 | 225 | −15 | USD 7,200 | USD 6,750 |
| Total | 420 | 432 | +12 | USD 19,800 | USD 21,420 |
Hours variance = 432 − 420 = +12 hours
Labour-cost variance = USD 21,420 − USD 19,800 = +USD 1,620
The total effort is 2.86% above the plan for the period, while labour cost is 8.18% above plan. The higher-cost senior mix explains most of the difference. That does not tell the team whether the decision was wrong: senior intervention may have resolved a real delivery risk. It tells the team what to investigate and document.
Which questions should the review ask?
| Signal | Question | Possible follow-up |
|---|---|---|
| Hours above plan | Which resource and week created the difference? | Check estimation, rework, client dependency, and unapproved scope. |
| Cost rising faster than hours | Did the role mix or applicable rate change? | Confirm whether more senior or higher-cost work was intentional. |
| Budget consumption ahead of progress | Is the project spending faster than it is completing the agreed work? | Review remaining scope and dependencies; do not infer completion from spend. |
| Margin percentage changed | Are both calculations using the same approved budget and included costs? | Reconcile the basis before discussing performance. |
| Large update without explanation | What operational event caused it? | Record a reason and an accountable next action. |
A useful review ends with a decision: accept the variance, correct an input, adjust the delivery plan, pursue a scope decision through the firm's normal process, or assign further investigation. A dashboard can surface the signal; it cannot choose the response.
How should margin be read alongside progress?
A cost-to-budget view and a completion view answer different questions. Budget consumption asks how much of the supported budget has been used. Percent complete asks how much work is judged complete. Neither number is a substitute for the other.
A project may be 40% complete after consuming 55% of its cost budget because early work was intentionally senior-heavy, a dependency created rework, the original estimate was weak, or scope was added. The gap is a prompt for investigation—not automatic proof of failure.
A current calculated margin uses the approved budget and supported costs recorded so far. It does not estimate the unrecorded effort still required to finish. Read it with planned hours, actual hours, completion context, and remaining scope.
How often should actuals and margin be reviewed?
There is no universal cadence. Choose a period short enough to support a decision before the next meaningful commitment. Weekly review is practical for many active delivery teams; a fortnightly or milestone cadence may fit slower work. The important point is that the data owner, cut-off time, and decision process are explicit.
A repeatable review checklist
- Confirm that actual hours and supported costs are complete through the cut-off date.
- Compare planned and actual hours by resource for the same period.
- Reconcile rate, role-mix, and non-labour cost changes.
- Read budget consumption beside completion and remaining scope.
- Compare margin calculations only after confirming a consistent basis.
- Record material reasons, decisions, owners, and the next review date.
How this plays out across a phased software implementation
Take a multi-phase software implementation for a mid-size client, run as discovery, build, deployment, and a post-go-live hypercare period. The planned-versus-actual method above has to be reapplied, deliberately, at each handoff.
- At the discovery-to-build handoff, discovery finishes under its planned hours, but the build-phase plan was set on assumptions discovery has since proven incomplete — the baseline is stale before build even starts. Handling: this is a legitimate baseline change, not a variance to explain away. Follow the baseline checklist above and record the date and reason for the revision before comparing any build actuals to it.
- At the deployment milestone, budget consumption spikes because go-live work concentrates senior effort into two weeks, while a feature-count view of percent complete does not reflect how critical the remaining tasks are. Handling: as the progress-context section above sets out, neither number alone tells reviewers whether the team is ready to go live — read consumption and completion together with the remaining task list.
- During hypercare, post-go-live bug-fixing hours start landing against the same cost codes as the original build, quietly blending warranty support into the delivery margin figure. Handling: decide, before hypercare starts, whether it is in scope or a separate engagement, and label the basis — the same scope discipline the baseline section calls for.
- At final reconciliation, discovery was reviewed at milestones, build was reviewed weekly, and hypercare is reviewed monthly, so rolling the four phases into one planned-versus-actual figure risks mixing cut-off dates. Handling: apply "compare like with like" from above, and align the phases to a common cut-off before combining them — see the review cadence guide for setting cadence deliberately rather than by default.
None of this requires a new method. It requires re-anchoring the same baseline discipline every time a project changes shape, which a phased implementation does at every handoff.
How Managed Margin updates delivery data
Authorised users record actual hours by resource and week. Saved weeks roll up into the delivery view, and each week is costed at the applicable stored rate. Managed Margin then recalculates its current figures and supported alerts. It does not import employee timesheets or predict final project margin, so the review is only as current as the entries supplied.
See the current project margin tracking workflow, or return to the professional-services project margin guide for the complete proposal-to-delivery context.
Sources and methodology
- Project Management Institute, Managing fixed-price projects using earned value management. Used for baseline, planned value, actual cost, progress, and review principles. The article distinguishes those EVM measures from a project-margin comparison.
- The actual-hours workflow, period rate treatment, calculation boundaries, and product limitations were reviewed against the current Managed Margin implementation on 23 August 2026.
- All project figures are illustrative and are not a customer result or a recommended benchmark.