Resource-based project cost estimation calculates delivery cost from the people required to perform the work. Define each role, its cost rate, planned allocation, and duration; convert the plan into hours; then add the non-labour costs included by policy. The estimate should record its assumptions, exclusions, source dates, and reviewer.
How does a resource-based cost estimate work?
Project Management Institute guidance describes planned project cost as a result of the activity plan, resource assignments, duration, and resource cost rates. A bottom-up estimate aggregates lower-level estimates into a project total. For a services engagement, the lower-level units can be roles or named resources planned by week or month.
The practical sequence is straightforward:
- Define the deliverables and the work needed for each.
- Select the roles, skill levels, and locations required.
- Set each role's allocation for each planning period.
- Convert allocation percentages into planned hours using an explicit standard-hours assumption.
- Multiply planned hours by the approved cost rate.
- Add included direct costs and the firm's documented overhead treatment.
- Record exclusions, uncertainty, and the person who approved the estimate.
Allocation % × standard hours in period = planned resource hours
Planned resource hours × cost rate = planned labour cost
A cost rate needs a defined meaning. It might contain only an hourly pay input, or it might be a loaded rate that includes employment on-costs. The label alone does not settle the policy. Finance should document what is included, and all compared scenarios should use the same definition.
Worked example: a three-month project estimate
A consulting team is estimating a three-month discovery and implementation engagement. The example assumes 160 standard hours per month at 100% allocation. The numbers are illustrative and are not market rates.
| Role | Monthly allocation | Months | Planned hours | Cost rate | Labour cost |
|---|---|---|---|---|---|
| Engagement lead | 25% | 3 | 120 | $95 | $11,400 |
| Consultant | 75% | 3 | 360 | $55 | $19,800 |
| Analyst | 50% | 2 | 160 | $32 | $5,120 |
| Total | — | — | 640 | — | $36,320 |
If the firm's policy adds a $2,500 specialist-contractor cost and overhead of 12% of labour, overhead is $4,358.40. The resulting estimated delivery cost is $43,178.40.
$36,320 labour + $2,500 contractor + $4,358.40 overhead = $43,178.40
This total is useful because each part can be challenged. Delivery can question the allocation. Finance can verify the rates and overhead basis. Presales can test the result against the proposed deal budget. A single top-down cost number does not support the same conversation.
What should reviewers challenge before sign-off?
| Review area | Question | Evidence |
|---|---|---|
| Scope coverage | Does every material deliverable have planned effort? | Scope-to-role mapping and exclusions. |
| Role mix | Is the planned skill level realistic for the work? | Delivery review, not margin percentage alone. |
| Timing | Are allocations placed in the periods when work occurs? | Week or month plan with explicit start assumptions. |
| Rates | Are rates current and consistently defined? | Rate owner and effective date. |
| Completeness | Are material non-labour and shared costs treated consistently? | Cost policy and documented exclusions. |
| Uncertainty | Which input would move the estimate most? | Alternative scenario or sensitivity check. |
The UK Cost Estimating Guidance recommends documenting assumptions and exclusions, using consistent categories and units, and applying review and sensitivity analysis where uncertainty is material. A consulting estimate does not need infrastructure-level complexity, but it benefits from the same traceability.
Reviewers should also separate estimate revision from estimate error. New client scope, an approved schedule change, or a named-resource substitution may justify a revised plan. A missed work package, invalid allocation, or stale rate indicates that the original estimate needs correction. Keeping the reason visible helps finance and delivery interpret the variance without rewriting the history of the approval.
For a quick sensitivity check, change one material assumption at a time. Extend a role by one month, replace a role variant, or apply the next effective rate. Recalculate total cost and identify the input with the largest effect. This is an assumption test, not a probability forecast. For a more structured way to size that uncertainty than a single guess per input, see three-point estimating with the PERT method.
Estimating a data-migration project from the ground up
Consider an illustrative case: a consultancy is bottom-up estimating a data-migration project moving a client off a legacy database onto a new platform, using a migration architect, two ETL developers, and a QA/validation analyst across discovery, migration, and validation phases.
- At kickoff: under time pressure, the team is tempted to skip the role-by-role breakdown and quote one blended day rate for the whole migration. Follow the practical sequence above instead – define roles, skill levels, locations, and allocation per period – so scope coverage can be checked deliverable by deliverable rather than assumed.
- Mid-estimate, an uncertain input: nobody is sure how many validation cycles the data volume will actually require, so the QA allocation gets a single guess. Treat that allocation as the sensitivity variable described above: recalculate with one extra validation cycle and see how much the total moves before locking the number in.
- At a scope change: the client adds a legacy data-cleansing sub-task partway through estimating. Separate estimate revision from estimate error, as recommended above, and document the added scope as a new approved item rather than absorbing it into the existing role allocations; see pricing option to delivery baseline for how an approved change should carry into the baseline delivery inherits.
- At sign-off: reviewers are tempted to just check whether the total looks "about right" against a similar past project rather than walking the estimate. Use the review-area table above and challenge role mix, timing, rates, and completeness individually; the value of a bottom-up estimate is that each part can be challenged, not that the total feels familiar.
What does this estimate not tell you?
A resource-based estimate does not prove the scope is correct, guarantee productivity, or predict the final project outcome. It also does not decide the client price. Value, competition, contract risk, and commercial strategy influence price separately from delivery cost.
Managed Margin supports entered resource-loading scenarios and calculated results. Its current presales preview uses deal budget, pay-rate-derived labour cost, configured commission, and configured overhead. Billing rates are not part of that scenario-preview formula. The calculation does not include predictive modelling, and the product does not import timesheets or payroll data.
Continue with the broader project-pricing guide, compare resource-loading scenarios, or review the current Managed Margin pricing workflow.
Sources and methodology
- Project Management Institute, PM101: Estimating. Used for the relationship between resources, duration, cost rates, and project budget.
- Project Management Institute, Lexicon of Project Management Terms, Version 5.0. Used for the bottom-up estimating and baseline definitions.
- UK Infrastructure and Projects Authority, Cost Estimating Guidance. Used for transparency, assurance, documented exclusions, and sensitivity principles.
- The worked example is original. Product statements were reviewed against the current Managed Margin implementation on 24 August 2026.