A resource-loading pricing scenario estimates a proposed team's delivery cost from role, allocation, duration, working hours, and governed cost rates, then compares that cost with the proposed fixed fee. The calculation makes staffing assumptions reviewable before sign-off. It does not prove the scope is deliverable or predict the final margin; delivery and finance still review the assumptions.
Which inputs belong in a resource-based price?
Start with the people required to deliver the scope, not an arbitrary discount from the client's budget. A bottom-up scenario needs enough detail to show why the planned labour cost has the value it does.
- Role and level: for example, senior consultant, consultant, or analyst.
- Skill and location: where these affect the governed rate and working-hours policy.
- Allocation: the percentage of a normal working week assigned to the project.
- Duration: the number of periods for which that allocation is planned.
- Cost rate: the approved internal hourly cost used for the role.
- Deal budget: the proposed fixed fee used as the scenario's revenue basis.
- Included cost components: in this example, sales commission and labour overhead.
The example below follows the current Managed Margin scenario-preview method: deal budget less commission, pay-rate-derived planned labour, and labour overhead. Billing rates are not used in this preview.
Worked example: Option A
Assume a three-month fixed-price engagement with a proposed deal budget of USD 120,000. The workspace uses a 40-hour week, 5% sales commission, and 15% labour overhead. All figures are illustrative.
| Role | Allocation | Planned hours | Cost rate | Planned labour |
|---|---|---|---|---|
| Consultant | 50% for 3 months | 40 × 4 × 3 × 50% = 240 | USD 60/hour | USD 14,400 |
| Senior consultant | 25% for 3 months | 40 × 4 × 3 × 25% = 120 | USD 90/hour | USD 10,800 |
| Analyst | 100% for 3 months | 40 × 4 × 3 × 100% = 480 | USD 30/hour | USD 14,400 |
| Total | — | 840 | — | USD 39,600 |
Commission = USD 120,000 × 5% = USD 6,000
Labour overhead = USD 39,600 × 15% = USD 5,940
Calculated scenario margin = USD 120,000 − 6,000 − 39,600 − 5,940 = USD 68,460
Calculated scenario margin % = USD 68,460 ÷ 120,000 × 100 = 57.05%
This result means the entered assumptions leave USD 68,460 after the three cost categories included in this preview. It does not mean the final project will achieve that margin. Subcontractor cost, infrastructure, travel, shared costs, scope change, actual role mix, and delivery variance can change the result if they apply later.
How should two staffing scenarios be compared?
Suppose Option B adds more senior-consultant time and reduces analyst allocation. The deal budget, commission rate, and overhead policy stay unchanged.
| Input or result | Option A | Option B | Review question |
|---|---|---|---|
| Consultant allocation | 50% | 50% | Is the core delivery capacity unchanged? |
| Senior allocation | 25% | 50% | Does the scope require more senior judgement? |
| Analyst allocation | 100% | 75% | Can less analyst capacity still deliver the work? |
| Planned labour | USD 39,600 | USD 46,800 | Is the higher-cost mix operationally justified? |
| Commission + overhead | USD 11,940 | USD 13,020 | Were the same cost policies applied? |
| Calculated margin | USD 68,460 / 57.05% | USD 60,180 / 50.15% | Which option balances delivery confidence and margin? |
Option A has the higher calculated margin, but that does not automatically make it the right option. If the project genuinely needs the added senior capacity, approving the lower-cost plan may simply hide delivery risk. Presales supplies the commercial context; delivery tests whether the staffing plan can execute the scope; finance checks the cost policy and result.
How does this play out on a real cloud-migration project?
Consider a mid-size IT consultancy pricing a fixed-price cloud-migration project: moving a client's on-premises workloads to a cloud platform over four months.
At kickoff, presales builds the resource-loading scenario the same way as the worked example above: a lead cloud architect, two migration engineers, and an analyst, each with a role, allocation, and duration, priced at the approved cost rate from the rate card. The deal budget is set before the team commits to a specific role mix, which keeps the commission and overhead calculation consistent with the policy used across other proposals.
During discovery, the architect finds more legacy dependencies than the proposal assumed and floats an Option B with more senior-architect time and less analyst time, mirroring the comparison table above. The higher-cost option has a lower calculated margin, but if the legacy dependencies genuinely need senior judgement, approving the cheaper option only defers the risk into delivery — the review question in the comparison table applies directly here.
Once a scenario is selected and the fixed-price purchase order is promoted, the placeholder role allocations from the option still need named engineers assigned before the project can be activated. If the originally scoped migration engineer is not available, resourcing has to re-check whether a substitute at a different cost rate changes the delivery economics — the resource-loading numbers are a planning input, not a booking.
At migration cutover, unplanned data-transfer volume adds hours beyond the original plan. That is a delivery-variance question, not a pricing-scenario question: project margin variance is where that gets measured against the promoted baseline, not this pricing worksheet.
The scenario above tests whether the proposed price and team are internally consistent. It does not confirm the client's legacy environment matches the proposal's assumptions or that named engineers with the right skills are actually free for the engagement — those checks stay with delivery and resourcing, not the pricing calculation.
What should happen after one option is selected?
The selected scenario should become a controlled starting point, not a screenshot that is forgotten after sign-off. Preserve the approved deal budget, chosen role mix, duration, allocation assumptions, calculation policy, and alternatives considered.
In Managed Margin, promoting a scenario is currently limited to a fixed-price purchase order. Promotion creates the approved budget and rate-card-based placeholder allocations. The team must still assign named resources, complete weekly planning, and pass the normal activation checks. Promotion does not activate the project automatically.
Once delivery begins, use the planned-versus-actual project margin review to compare recorded effort with this approved baseline.
What does this pricing example not prove?
- It does not predict final hours, final costs, completion date, or final margin.
- It does not test scope completeness, delivery quality, client dependency, or schedule feasibility.
- It does not recommend a price or a target margin.
- It does not use billing rates in the current Managed Margin scenario preview.
- It does not include every cost category that may apply to a live project.
- It does not replace approval by people who understand the work and the firm's cost policy.
For the commercial product workflow, see project pricing and scenario planning. For the broader operating context, return to the professional-services project margin guide.
Sources and methodology
- Project Management Institute, Planned Resources and Cost. Used for the principle that planned resources and cost estimates should be built from explicit assumptions.
- UK Infrastructure and Projects Authority, Cost Estimating Guidance. Used for transparent assumptions and estimate review.
- The formula and promotion boundaries were reviewed against the current Managed Margin scenario implementation on 23 August 2026. Every monetary amount and role in the example is synthetic.