Project margin variance is the difference between two margin results calculated on a consistent basis. In dollars, subtract baseline margin from current margin. For margin rates, subtract the baseline percentage from the current percentage and report the result in percentage points. Reconcile revenue, included costs, scope, and cut-off dates before interpreting the difference.
Which project margin variance formula should you use?
Use two related calculations because they answer different questions. Dollar variance shows the absolute economic change on the chosen basis. Percentage-point variance normalises that result against revenue. Do not call a move from 30% to 24% a "6% decline": it is a decline of 6 percentage points, or 20% relative to the original 30% rate.
Margin amount = revenue basis - included costs
Margin percentage = margin amount / revenue basis x 100
Dollar variance = current margin amount - baseline margin amount
Percentage-point variance = current margin % - baseline margin %
"Current" must have a precise meaning. It may be an actual-to-date calculation, a formally revised baseline, or a separately governed forecast. Those are not interchangeable. Managed Margin calculates current actual-to-date values from recorded data; it does not forecast final margin.
Worked example: a six-point margin change
A fixed-price project has an approved value of USD 100,000. The baseline includes USD 70,000 of costs, leaving USD 30,000 of margin. During delivery, the comparison identifies USD 6,000 of additional included cost on the same revenue basis. The example assumes no approved price change and is for arithmetic only.
| Measure | Baseline | Current comparison | Variance |
|---|---|---|---|
| Revenue basis | USD 100,000 | USD 100,000 | USD 0 |
| Included cost | USD 70,000 | USD 76,000 | +USD 6,000 |
| Margin amount | USD 30,000 | USD 24,000 | -USD 6,000 |
| Margin percentage | 30% | 24% | -6 percentage points |
The headline is not the diagnosis. Suppose the USD 6,000 comprises USD 3,600 of additional senior hours, USD 1,400 of partner cost, and USD 1,000 of approved infrastructure cost. Reviewers can now separate an intentional technical intervention from an avoidable delivery issue and a client-approved requirement.
How do you explain project margin variance?
| Driver | Evidence to inspect | Question to ask |
|---|---|---|
| Hours variance | Planned and actual hours for the same resource and period | Was the estimate wrong, was there rework, or did scope change? |
| Role-mix variance | Hours transferred between roles with different cost rates | Was senior intervention deliberate and documented? |
| Rate variance | Applicable rate and effective date | Did staffing, location, shift, or pay policy change? |
| Non-labour cost | Partner, infrastructure, travel, or other supported items | Was the cost planned, approved, and classified consistently? |
| Commercial change | Approved scope, fee, and baseline versions | Should the original baseline remain the comparison, or is a labelled rebaseline needed? |
The Department of Energy's project-management lexicon defines cost variance within EVM as earned value minus actual cost. That is not the formula above. Calling both measures "cost variance" creates avoidable ambiguity, so label project-margin variance explicitly and keep formal EVM terminology for EVM calculations.
Choose the comparison pair before calculating
Baseline versus actual-to-date is useful for current observation only when both views cover a meaningful basis. Planned-to-date versus actual-to-date is better for explaining period performance. Original baseline versus authorised revised baseline explains a commercial or delivery decision. Forecast versus baseline is a different exercise because it requires a governed estimate of remaining cost; do not create that label from actuals alone.
Also handle edge cases explicitly. If approved revenue is zero, a margin percentage cannot be calculated on that denominator. If the revenue basis changes, show the old and new basis as separate rows. If the baseline margin is negative, percentage-point variance remains arithmetically valid, but relative percentage-change language can become confusing and should be avoided.
How variance shows up across a multi-phase implementation
Consider an illustrative case: a mid-size systems integrator delivers a three-phase software implementation for one client – discovery, build, and rollout – priced as a single fixed-price engagement with one baseline set at signing. Margin variance is reviewed at each phase gate, not only at the end. This example is illustrative, not an audited result.
- At baseline lock: the team must agree exactly what "baseline" means before build starts – the signed SOW figures, or an internal working estimate that was never approved. Use the signed, approved baseline as the fixed comparison point; an unapproved working number produces a variance nobody can defend later.
- Mid-delivery, during build: a senior architect is pulled in for two weeks to resolve an integration issue outside the original role mix. This raises cost, but it is role-mix variance, not unexplained overrun. Log it against the role-mix row in the driver table above so a deliberate technical decision is not mistaken for rework.
- At a scope change: the client approves an additional integration mid-build through a change order. This is a commercial-change driver, and it forces an explicit choice: keep the original baseline as the comparison for the rest of the project, or move to an authorised revised baseline. Making that choice visible keeps rollout-phase variance meaningful; see the planned-versus-actual review guide for running that phase-gate comparison.
- At the phase-gate review: the team reports margin "down six points" and a stakeholder paraphrases it as a "6% decline." Correct the language where it is used, not after it has spread through a status deck: a move from 30% to 24% is six percentage points, not a 6% decline.
- At rollout, near close: actual-to-date margin looks healthy because the rollout phase has not yet consumed its planned effort. Do not read that number as final profitability; the limitation below applies directly here, since unrecorded future effort in the current phase is exactly what an actual-to-date figure cannot show.
Controls, limitations, and a review checklist
- State the baseline version, current version, and data cut-off.
- Confirm the same revenue denominator on both sides.
- Reconcile every included cost category and effective rate.
- Report percentage changes as percentage points when subtracting rates.
- Trace material changes to evidence rather than assigning a generic cause.
- Read cost and margin alongside progress and remaining scope.
An actual-to-date margin variance does not include unrecorded future effort. It can show what has changed so far, but it cannot establish final profitability without a separate estimate-to-complete process.
For the full operating method, read planned versus actual project margin. If the key question is whether spend is ahead of progress, continue to budget consumption versus percent complete.
How Managed Margin handles the current comparison
Authorised users manually record weekly actual hours. Managed Margin applies the stored rate effective for each recorded week and recalculates supported current figures. Its result is actual-to-date, not predictive. The delivery margin tracking page explains the current workflow and visibility controls.
Sources and methodology
- U.S. Department of Energy, Project Management Lexicon of Terms. Used to distinguish formal EVM cost variance and percent-complete terminology from project-margin calculations.
- U.S. Department of Energy, Earned Value Management. Used for baseline, planned value, actual cost, and progress distinctions.
- Product statements were reviewed against the current Managed Margin implementation on 24 August 2026. All figures are original educational examples.