Planned-versus-actual project margin compares an approved revenue and cost baseline with actual hours and supported costs recorded to a defined cut-off date. Use the same scope, period, rates, and cost categories on both sides. Investigate differences by driver, and treat the actual-to-date result as a current observation rather than a prediction of final margin.
What exactly should planned and actual mean?
A useful comparison begins with definitions. Planned margin is the approved commercial value less the costs included in the pricing model. Actual-to-date margin applies the agreed revenue and cost policy to hours and costs recorded through a stated cut-off. A margin percentage normally divides the resulting margin amount by the approved commercial value, but firms may use other definitions. Write yours down and use it consistently.
The U.S. Department of Energy describes Earned Value Management as a method that integrates scope, cost, and schedule against an approved baseline. Its guidance also warns that comparing planned and actual cost without measuring physical progress can be misleading. That principle is useful here, but a project-margin comparison is not automatically a formal EVM calculation. Managed Margin does not calculate earned value or predict cost at completion.
Margin asks what remains after included costs. Cost variance asks how actual cost compares with the relevant plan. Progress asks how much agreed work has been completed. The measures inform one another, but one cannot safely stand in for the others.
A six-step planned-versus-actual method
1. Preserve an approved baseline
Store the contract value, scope and exclusions, resource plan, hours by period, cost rates, non-labour costs, shared-cost policy, and approval date. Preserve the original rather than overwriting it when delivery changes. An authorised rebaseline can be useful, but it should have its own effective date and reason.
2. Establish the cut-off and owner
Choose the date through which actuals must be complete and name the person responsible for the update. A calculation made on Monday with Friday's hours missing is not directly comparable with one made after the week is closed. The review record should therefore show both the data cut-off and review date.
3. Capture actuals at useful detail
Record hours by resource and period, plus supported partner, infrastructure, travel, or other costs included by policy. Detail matters because equal total hours can have different costs when role mix or effective pay rates differ. Correct input errors before discussing operational performance.
4. Reconcile the calculation basis
Confirm that planned and actual views use the same commercial value and cost categories. If a scope change, approved price adjustment, or cost-policy change affects the basis, show it explicitly. A five-point margin difference built from two different denominators is not an operational variance until the bases are reconciled.
5. Trace the variance to drivers
Start with hours by resource and period, then test rate changes, team mix, non-labour cost, rework, delay, dependencies, and approved scope changes. Labels such as "delivery issue" or "scope creep" are conclusions, not evidence. Record the specific cause that the available data supports.
6. Decide and document
A review should end with a decision: accept an intentional variance, correct data, change the delivery plan, initiate a commercial scope process, or investigate further. Assign an owner and date. A dashboard can identify a signal; accountability remains a management task.
Worked example: the same hours can hide a different cost
A fixed-price project has an approved value of USD 120,000. The full-project baseline includes USD 78,000 of cost, so planned margin is USD 42,000, or 35%. At the end of week six, compare the planned and recorded labour for those same six weeks. This period view explains a current driver; it does not estimate the cost still required to finish.
| Role and hourly cost | Planned hours to date | Actual hours to date | Planned cost | Actual cost |
|---|---|---|---|---|
| Lead consultant, USD 100 | 120 | 150 | USD 12,000 | USD 15,000 |
| Consultant, USD 65 | 240 | 225 | USD 15,600 | USD 14,625 |
| Analyst, USD 40 | 240 | 225 | USD 9,600 | USD 9,000 |
| Total | 600 | 600 | USD 37,200 | USD 38,625 |
Hours variance = 600 - 600 = 0 hours
Labour-cost variance = USD 38,625 - USD 37,200 = +USD 1,425
Total hours are exactly on plan, yet labour cost is USD 1,425 higher because 30 lead-consultant hours replaced lower-cost effort. That may be justified by risk or quality needs. The calculation reveals the trade-off; it does not judge the decision. Reviewers should ask why the mix changed, whether the remaining plan reflects the new delivery need, and whether a client-approved scope decision exists.
How should the result be interpreted?
| Observation | What it can support | What it cannot prove |
|---|---|---|
| Actual hours exceed planned hours for the same period | A specific effort variance that needs explanation. | That the final project will overrun. |
| Cost rises faster than hours | Review of rate, role mix, shift, or cost-category changes. | That a higher-cost resource was unnecessary. |
| Budget consumption exceeds reported completion | A prompt to examine timing, rework, scope, and remaining effort. | Formal earned-value performance unless EV rules are actually used. |
| Current margin is below planned margin | Reconciliation of the current calculation and its drivers. | A forecast of final margin, as noted in the short answer above. |
For the meeting mechanics, use the separate weekly planned-versus-actual review guide. For the arithmetic and naming convention, see how to calculate project margin variance. Because the approved fee in this example does not move, every one of those extra hours comes straight out of margin—see why extra hours reduce fixed-price margin.
When should the baseline change?
Do not rewrite the approved plan merely because actual performance differs. That removes the reference needed to learn from the variance. A new baseline is more defensible when an authorised commercial or delivery decision changes the work that the project is now expected to perform. Preserve the original, label the revised version, record the approval and effective date, and explain which future periods changed.
For example, assume the client approves a USD 20,000 extension with 240 additional planned hours. Review historical delivery against the baseline that governed those periods. Use the revised, labelled baseline for the new work from its effective date. Management can then see both the original variance and the economics of the approved change instead of blending them into an unexplained percentage.
A reviewer should be able to reproduce the original plan, identify every authorised revision, and state which version is being used in the current comparison. If that cannot be done, resolve the baseline before interpreting margin variance.
How this plays out during a multi-phase software implementation
Consider a 35-person IT consultancy delivering a three-phase CRM implementation for a mid-size distributor: a foundation phase, a workflow-automation phase, and a reporting phase, each priced and approved separately. Applying the six-step method above looks different at each stage of that delivery.
- At phase-1 kickoff. The team is eager to start logging hours before the approved baseline—roles, hours, rates, and scope—is actually locked for that phase. Without step 1 above, the first weekly comparison has nothing stable to compare against. Preserve the phase-1 baseline, with its own owner and approval date, before any actual hours are recorded.
- Mid-phase 1, when an integration breaks. A senior architect burns extra hours resolving an unplanned issue with the client's ERP connector while a junior analyst's planned hours go unused. Total hours can stay close to plan while the role mix—and therefore labour cost—moves, exactly as in the worked example above. Trace the variance to the driver instead of stopping at the aggregate hours figure.
- When the client adds scope mid-phase. A request for extra reporting fields arrives after phase 1 is underway. Blending it into the existing baseline hides both the original variance and the economics of the addition. Treat it as an authorised rebaseline with its own effective date, as described above.
- At phase-2 kickoff. It is tempting to carry the phase-1 team and rates forward unchanged. If a consultant's role or rate has changed since phase 1 was approved, that assumption is now wrong. Re-run the baseline steps for phase 2 rather than copying phase 1's numbers.
- At the monthly portfolio review. A sponsor wants one margin figure across all three phases. That is only meaningful once each phase's calculation basis is reconciled—same revenue and cost definitions, same treatment of the phase-1.5 change—so a single blended percentage does not hide which phase is actually off plan. The professional-services project margin guide covers how this fits into the wider proposal-to-delivery workflow.
Limitations and control checklist
- Actuals can be incomplete, late, incorrectly classified, or entered at the wrong effective rate.
- A baseline can become irrelevant after an approved commercial change unless versions remain visible.
- Actual-to-date cost says nothing by itself about the effort still required to finish.
- Budget consumption is not percent complete, and manually supplied completion is not earned value.
- Margin definitions vary, so cross-project comparisons require a common revenue and cost policy.
Before publishing a result, confirm the cut-off, completeness, baseline version, denominator, included costs, and owner of each material explanation, and keep forecast language out of the summary as noted above.
How Managed Margin applies the method
Managed Margin carries a fixed-price resource plan into delivery. An authorised user manually records weekly actual hours and may record completion context; the application costs actual weeks using the applicable stored rate and recalculates current actual-to-date figures. It does not import timesheets or run external integrations. Explore the current project margin tracking workflow.
Sources and methodology
- U.S. Department of Energy, Earned Value Management. Used for the distinctions among planned value, earned value, actual cost, baseline, and progress. This article does not claim that Managed Margin implements formal EVM.
- U.S. Government Accountability Office, Cost Estimating and Assessment Guide. Used as an authoritative reference on cost estimates and managing cost through a project's life cycle.
- Product statements were reviewed against the current Managed Margin implementation on 24 August 2026. All figures are original educational examples, not customer results or benchmarks.