How to Estimate by Role Rate (Not Just Hours)

The estimate I wrote in 2014 for a six-month build of an internal tooling platform looked like this, in its entirety:

Discovery: 80 hours @ £140/h    £11,200
Design:    120 hours @ £130/h   £15,600
Engineering: 600 hours @ £140/h £84,000
Project management: 80 hours @ £100/h £8,000
TOTAL                          £118,800

The project landed three weeks late, with the senior architect having quietly absorbed about a third of the engineering hours, two design rounds that hadn't been quoted, and a project manager who had spent twice the budgeted hours dealing with a client communication problem that wasn't anyone's fault. The post-mortem couldn't agree on what had gone wrong because nobody could agree on what was supposed to have happened. The estimate didn't say.

A role-based estimate would have said. This is what one looks like for the same project.

The same estimate, role-based

Discovery
  Strategy lead × 30h × £200/h            £6,000
  Senior consultant × 50h × £150/h        £7,500
                                          £13,500

Design
  Design director × 30h × £180/h          £5,400
  Senior designer × 60h × £130/h          £7,800
  Mid-level designer × 30h × £100/h       £3,000
                                          £16,200

Engineering
  Senior architect × 80h × £190/h        £15,200
  Senior developer × 200h × £150/h       £30,000
  Mid-level developer × 280h × £130/h    £36,400
  QA engineer × 80h × £100/h              £8,000
  DevOps × 40h × £160/h                   £6,400
                                          £96,000

Programme management
  Programme lead × 40h × £150/h           £6,000
  Project manager × 80h × £100/h          £8,000
                                          £14,000

TOTAL                                    £139,700

Several things happen as soon as the estimate looks like this.

The headline price moves up — not dramatically, but visibly. £139,700 instead of £118,800. That's because role-rate estimating forces honesty about the senior involvement that headline-rate estimates quietly absorb into the blended rate.

The senior architect's involvement is now declared, not implicit. If the project genuinely needs 80 hours of senior architect time, that's now a line. If during the project the senior absorbs more than 80 hours of architect work, the project lead has a conversation to have rather than a fact to absorb.

The QA and DevOps lines, which a headline-hours estimate often treats as overhead, are now declared and priced. If the project doesn't have a QA budget, that's a deliberate decision the client and agency have made together.

What clients actually see

The natural worry, when an agency owner first sees a role-based estimate, is that the client will react badly to seeing the seams. Three observations from running this for four years across forty projects a year:

• Most clients prefer it. Procurement-heavy clients (anyone with a finance team) prefer a role-based estimate because it answers questions the agency was previously being asked to defend in spreadsheets. The estimate becomes the conversation, instead of the agency having to produce a separate "rationale doc".

• Some clients want the headline number only. That's fine. Print the estimate with the role-based composition on a second page (or in an appendix). The first page is a single line: "Six-month build, £140k, payable in three milestones." The role-based composition lives behind it. If the client never asks, you never have to defend it. If the client does ask, you have it ready.

• A small number of clients want to negotiate the role rates. That's not a bug; it's the conversation you want. They've identified that the QA rate is high for their context, or that the architect time is heavier than they need. You either defend the rate or adjust the role mix. The negotiation has somewhere to land.

The cost of producing role-based estimates, once you have a template, is 10–15 minutes more than producing a headline-hours estimate. The benefit, repeatedly across our last four years, has paid back ten or twenty times over.

The four questions a role-based estimate answers

A headline-hours estimate doesn't answer these. A role-based estimate has to answer them by construction.

1. Which role is going to do the most expensive work?

In a build with a senior architect, that role is usually the bottleneck. A role-based estimate forces you to declare how many hours of architect time the project will consume, which forces you to think about whether that role will actually be available at the cadence the project needs. (If the architect is at 110% utilisation across other projects, you've just identified a staffing problem before it becomes a delivery problem.)

2. Which role is going to be at risk of being absorbed by a more senior role?

The mid-level engineering line is almost always at risk of being absorbed by the lead developer line, especially in agile builds where seniors aren't actively boundaried away from the harder tickets. A role-based estimate makes this risk visible in the line item structure. The pricing review that follows can ask: is the lead developer going to actively coach the mids, or is the lead going to quietly do the work? The answer to that question is a different staffing plan, possibly a different price.

3. What does this engagement need that we haven't budgeted for?

Role-based estimates surface absences. A common one: an engagement with no QA line. That's a deliberate choice or an oversight, and the role-based template makes it impossible to ship the estimate without having had the conversation. Same for DevOps, security review, accessibility review, and the other lines that frequently disappear into the blended rate of a headline estimate.

4. What's the right thing to delete if the budget is too high?

When a client comes back asking for the price to come down 15%, the agency that has a role-based estimate has a much sharper conversation. They can show: removing a senior consultant line saves £6k. Reducing QA by half saves £4k. Cutting the design director time saves £3.6k. The client picks. The conversation is quantitative.

The agency with a headline-hours estimate is reduced to either lowering the blended rate (which compresses margin invisibly) or compressing the hours (which compresses delivery, also invisibly).

The template we use internally

We use a four-column structure for every estimate. The template is small enough to live in a single spreadsheet tab. The columns:

Phase rolls up. Role rolls up. The total is computed from the lines, not entered.

A second tab records the real hourly cost of each named individual likely to be staffed on each role. That tab is private to the agency. When a worklog from a named individual lands against an estimate line, the system can compare what the line was priced at (role rate) against what the individual cost the agency (real cost). The variance is the project margin movement.

We use this template internally inside the layer we built (now Saldo). The template itself is independent of any tool — it works in a spreadsheet, in a pricing system, anywhere. The benefit, structurally, comes from estimating at the role granularity, regardless of how the variance is later read.

The four-question test before sending

Before any estimate over £40k goes out to a client, we run it through these four questions. Two minutes per estimate, paid back many times.

1. Does every line have a named role at a defended rate? If a line says "engineering: 600 hours" without a role breakdown, it goes back.
2. Is there a role you'd expect to see that isn't on the page? QA is the most commonly missed; DevOps and accessibility review are next.
3. Does any role's hour total look high enough that a senior is likely to absorb the work? If yes, either rate the line at the senior's rate or split the line into two roles with the absorption explicitly declared.
4. If the client asks for 15% off the price, do you know what you'd remove without breaking the build? If not, the estimate isn't ready to defend in negotiation yet.

The estimate that passes the four questions is sendable. The estimate that doesn't gets fifteen more minutes of work, and almost always comes out tighter on the other side.

What this changes downstream

Estimating by role rate is a small change at the document level and a large change downstream. Three downstream effects we've observed:

• Margin variance becomes diagnosable. When a project lands at 12% margin instead of 35%, the role-rate estimate gives you a structure to ask "which role was off-plan, and by how much" — instead of the headline-hours postmortem where the only available answer is "we used too many hours".
• Sales conversations become quantitative. Salespeople who internalise the role-based template learn to defend price by defending the role mix. They stop discounting at the blended rate, which is the version of discounting that compresses agency margin most painfully.
• Hiring decisions follow from project staffing. If the role-based estimates across the active book of work consistently call for more senior architect hours than the agency has, the hiring need is provable. If they consistently call for fewer mid-level hours than the agency has staffed, the staffing problem is the same kind of provable.

The headline-hours estimate is a residue of the era when agency pricing was a single blended rate and the conversation with the client ended at the total. That era is over. Most clients want more than a total. Most agencies need more than a total. The role-based estimate isn't longer or harder; it's just honest about the composition that was always implicit.

Migrating existing engagements

Most agencies who decide to switch to role-based estimating have an existing book of work running on headline-hours quotes. The migration is rarely a cliff edge — re-papering all active engagements is a lot of paperwork and produces little benefit on engagements that are already half-delivered. The pattern that works in practice is staged.

For new engagements: switch immediately. Every estimate going out from this week is role-based. The template is the same one we showed above; the time cost is 10–15 minutes per estimate; the benefit starts compounding from the next pricing review.

For active engagements at less than 50% delivered: write a one-page "role mix annex" to the existing estimate, at the next milestone or scope change, that records the implicit role mix the original estimate assumed. This isn't legally binding — the original headline estimate still governs the contract — but it gives the project lead the role-level visibility they need for the rest of the engagement, and it sets the precedent for how the next phase will be priced.

For active engagements at more than 50% delivered: leave them alone. Re-papering near the end of an engagement is a relationship cost without a margin benefit. Use the post-mortem to reconstruct the role mix retroactively as a learning exercise, but don't try to renegotiate.

For retainers and ongoing engagements: at the next contract renewal, switch the renewal to a role-based structure. Most retainers have a natural anniversary; that's the right moment for the structural change.

Within a quarter, most agencies that have committed to the migration have all new estimates and most renewed retainers in the new structure. Within a year, the headline-hours estimate has been quietly retired across the book of work, without anyone having had a difficult conversation about it.

If you'd like to see what role-rate estimates look like running against live project data — the variance between what each role was priced at and what the named individual actually cost the agency — that's what Saldo is for. The 15-minute demo runs against your real Jira data; we don't ask for card details up front.