Fixed-price project margin is the fixed project revenue less the delivery costs included by the firm. Because extra delivery effort does not automatically increase the agreed price, margin falls when hours, rates, or other costs exceed the approved assumptions. Protect it with defined scope, a costed resource baseline, periodic actuals, and explicit change decisions.
Why is fixed-price margin exposed to delivery effort?
In a fixed-price arrangement, the client receives price certainty for a defined scope. The January 2026 UK government pricing guidance states that fixed price depends on fixed scope and transfers delivery risk for the defined service to the supplier. Although public procurement contracts can be more complex than a consulting engagement, the central relationship still applies: if the revenue basis stays fixed while supplier cost rises, supplier margin falls.
Project margin = agreed fixed revenue − included delivery costs
Project margin % = project margin ÷ agreed fixed revenue × 100
This does not mean every unfavourable difference is scope creep. A variance can come from an underestimated task, a more senior role performing the work, a rate change, rework, an approved scope change without a corresponding commercial change, or an unplanned direct cost. The review should identify the driver rather than assign a label first.
Worked example: planned and actual fixed-price margin
Assume a professional-services firm signs a $100,000 fixed-price engagement. Its approved plan includes $60,000 of labour and $10,000 of other included delivery costs.
| Measure | Approved plan | Current actual-to-date basis | Difference |
|---|---|---|---|
| Fixed project revenue | $100,000 | $100,000 | $0 |
| Included labour cost | $60,000 | $72,000 | +$12,000 |
| Other included cost | $10,000 | $10,000 | $0 |
| Project margin | $30,000 | $18,000 | −$12,000 |
| Project margin % | 30% | 18% | −12 points |
The table does not tell the team why labour cost increased. The next step is to inspect planned and actual hours by role and period. If a consultant logged 160 hours above plan, the team must determine whether the cause was underestimated effort, changed scope, rework, or a staffing decision. The financial signal starts the delivery conversation; it does not replace it.
A current margin calculation describes recorded inputs on the selected basis. A final-margin forecast also needs an estimate of remaining work. Managed Margin does not currently predict the final margin at completion.
What controls protect fixed-price margin?
- Define scope before pricing. State deliverables, assumptions, exclusions, acceptance, and the change mechanism.
- Cost the proposed team. Preserve roles, cost rates, allocation, duration, and material non-labour costs.
- Review delivery feasibility. The cheapest role mix is not useful if it cannot deliver the work.
- Approve one baseline. Keep the original budget and resource assumptions identifiable after sign-off.
- Record actual effort by period. Review the same role and time units used in the plan.
- Compare progress with budget use. Budget consumption alone is not proof that the same percentage of scope is complete.
- Record changes explicitly. Do not erase the baseline to make current performance look aligned.
- Assign a decision owner. A variance needs an operational or commercial response, not just a red status.
PMI's fixed-price project case study emphasizes a defined scope, project baseline, progress assessment, and captured actual cost. Managed Margin does not claim to implement formal earned-value forecasting, but those control principles support a useful planned-versus-actual review.
Use a simple decision record when the review finds a material variance: note the affected scope or role, the plan value, the current recorded value, the likely driver, the owner, and the agreed response date. The response may be operational, such as changing the remaining role mix, or commercial, such as following the agreed change process. Recording the choice is more useful than repeatedly presenting the same variance.
How does this play out across a fixed-price systems-integration project?
Take a 25-person IT professional-services firm delivering a fixed-price project to connect a client's order-management and finance systems. The commercial model is simple on paper; the pressure points show up at specific stages of delivery.
- At kickoff, the price is built assuming senior integration architects are needed full-time from day one, when in practice they are only required for design and final testing. Handling: apply control 2 above and the role-by-role method in estimating cost from resources — cost the team by role, allocation, and duration rather than as a flat lump sum, so the plan reflects when senior cost actually lands.
- Mid-delivery, the team discovers a third legacy system nobody scoped that also needs a connector. Handling: this is what control 1 exists for — go back to the documented scope, deliverables, and exclusions to determine whether the connector is inside the agreed price or requires the change mechanism.
- At the change order, the client agrees to pay for the extra connector but only a modest increase, and it is tempting to fold the additional hours into the existing baseline instead of recording a distinct change. Handling: controls 4 and 7 above apply directly — keep the original baseline identifiable and record the change explicitly, so later variance reporting reflects only genuinely unbudgeted work.
- At the monthly review, budget consumption runs ahead of testing completion because integration testing front-loads senior hours. Handling: control 6 warns against exactly this read — budget consumption alone does not prove an overrun, so check testing completion before reacting.
- At project close, the final reconciliation must separate the original fixed price plus the approved change-order value from any unapproved hours the team may have absorbed along the way. Handling: use the decision-record practice above to confirm actual cost reconciles to the baseline plus approved changes, not to a quietly expanded scope.
Every one of these pressure points is ordinary for fixed-price delivery. What separates a controlled project from an eroded one is whether the baseline and its approved changes stay identifiable throughout, which is what the control checklist above is built to enforce.
How does Managed Margin handle fixed-price scenarios?
Managed Margin lets a team create alternative fixed-price resource-loading scenarios and compare their calculated margins. The scenario preview uses the entered deal budget, pay-rate-derived labour, configured commission, and configured overhead. It does not use billing rates in this preview and it does not predict delivery performance.
Promotion is fixed-price only. Promoting one option sets the approved budget and creates placeholder allocations from its resource plan. It does not activate delivery. Named resources must be assigned and the delivery plan completed before activation. Once work is active, authorised users can record weekly actual hours and review current planned-versus-actual figures.
The product does not import timesheets, payroll, HR, CRM, ERP, invoicing, or accounting data. Data freshness depends on the team's update process. Learn how the pricing option becomes a delivery baseline, or explore delivery margin tracking.
Sources and methodology
- UK Cabinet Office, Risk Allocation and Pricing Approaches, January 2026. Used for fixed-scope, price-certainty, and supplier-risk principles.
- Project Management Institute, Managing fixed-price projects using earned value management. Used for baseline, progress, and actual-cost control concepts, not as a claim that Managed Margin implements EVM forecasts.
- The worked example is original. Product claims were checked against the Managed Margin implementation on 24 August 2026.