# How to review estimate accuracy by work type
Source: https://korrel.ai/blog/review-estimate-accuracy-by-work-type
Published: 2026-10-06
Updated: 2026-09-30
Topic: how to review estimate accuracy by work type
Tags: estimating, cost-tracking
---
## Key points

- Compare similar completed work rather than one portfolio-wide average.
- Separate effort, role mix, cost rate, fixed cost, and scope before you change an estimate.
- Change one estimate component when the same bias appears across comparable projects.

To learn how to review estimate accuracy by work type, compare estimated and actual results for groups of similar completed work. Look for repeated estimating bias.

Before you use a portfolio average, check discovery and implementation support separately and review what each difference means for price and cost. Group the work first.

Do not try to make every project match its estimate. Check uncertainty as well as repeated errors. Correct the estimate component that caused the difference.

## How should you choose work types that reflect delivery?

Start with work types that your team can identify without debate, such as discovery or analysis. Other examples include workshop delivery and training, as well as implementation and ongoing support.

Do not group projects only by client or total fee. Check the work required for each project so you can group work that your team estimates and delivers in the same way.

Use these tests for each work type:

- It has a clear output.
- Team members record time or cost against it.
- Its estimate uses a consistent method.
- Several completed examples can be compared.
- A future estimator can select it before work starts.

Keep your first set simple. Before you split a work type with two different delivery models, check that each group has enough completed examples to compare.

For example, keep a fixed workshop separate from an open-ended stakeholder consultation. Before you group them, compare their workshop formats and stakeholder counts, then check their decision structures.

Use these work types in your wider [estimating process](/blog/topics/estimating). Give each past job a clear label that an estimator can use in the next proposal.

## Build one clean comparison set

Use completed work. Do not compare a full estimate with a partial actual result.

For each work item, collect:

- work type;
- estimated hours and labour cost;
- actual hours and labour cost;
- estimated and actual role mix;
- estimated and actual fixed costs;
- approved scope changes;
- a short cause note.

Compare the final approved estimate with the matching actual result. Keep approved changes separate from the original scope so new work does not look like an estimating failure.

Check for missing time before you call an estimate generous. If time recording is late, first use a clear [timesheet timing policy](/blog/how-often-consultants-fill-timesheets). Then review a period with complete records.

The basic hours difference is:

`hours difference = actual hours - estimated hours`

The percentage difference is:

`hours difference percentage = (actual hours - estimated hours) / estimated hours × 100`

Use the percentage only when estimated hours are greater than zero.

Use one sign convention throughout. In this review, a positive difference means actual effort was higher than estimated effort. Write that rule above the report so nobody reads it backwards.

[OpenStax separates labour variance into rate and time effects](https://openstax.org/books/principles-managerial-accounting/pages/8-3-compute-and-evaluate-labor-variances). Its accounting examples compare actual results with standard costs. That distinction matters here because higher cost does not always mean the work took longer.

## How do you review estimate accuracy by work type?

Sort completed items by work type. Review both the median and the spread, checking individual results before you set a rule for future estimates.

Look at individual projects as well. Separate one large overrun from a pattern of overruns across nearly every project.

Mark each difference with a cause that you can act on:

- effort quantity;
- role mix;
- cost rate;
- fixed cost;
- scope change;
- recording problem;
- exceptional event.

Do not use vague causes such as “complex project” or “team issue”. Name what changed: two extra stakeholder groups, senior review replacing analyst review, or travel omitted from fixed costs.

[GAO's cost estimating guide](https://www.gao.gov/products/gao-20-195g) includes a work breakdown structure, data collection, and updating estimates with actual costs. Apply those principles to comparable completed work. Ask delivery staff to explain differences rather than relying on memory.

Check for the same cause across similar completed work before you record estimate bias. If causes differ, do not force one correction across the group.

## Use a work-type estimate bias matrix

Use this matrix to make one controlled estimating decision from the review. It is an original diagnostic tool, not an industry benchmark. The rows are invented examples, not findings about these work types. Test each proposed cause against your own records.

| Work type | Repeated result | Evidence to check | Likely estimate component | One test change | Do not change yet |
|---|---|---|---|---|---|
| Discovery | Actual hours often exceed estimate | Workshop count, interview count, analysis time | Effort quantity | Add a unit per interview or workshop | Cost rates |
| Analysis | Total hours vary, but cost rises consistently | Actual role mix by task | Role mix | Add planned senior review hours | Base analyst hours |
| Implementation | Hours rise after unknowns become clear | Assumptions, risks, approved changes | Risk allowance or scope boundary | Price one named uncertainty | Every labour rate |
| Training | Delivery is close, preparation runs over | Preparation and delivery time codes | Preparation effort | Set preparation hours per module | Delivery duration |
| Support | Small requests exceed the included allowance | Request count and average handling effort | Quantity allowance | Set an included request volume | Role cost rate |
| Travel-heavy work | Labour is close, total cost runs over | Records for travel and accommodation, plus supplier records | Fixed cost | Add the omitted fixed-cost item | Labour hours |

Read across one row. Start with the repeated result and check the evidence before you select a cause and change one component for the next comparable estimate.

The final column has a clear purpose. Do not use a broad rate increase to correct an effort error. Protect the components that the evidence does not challenge.

## Change the component that caused the difference

Separate quantities, role assignments, fixed costs and both cost and sell rates in your estimate. Review contingency separately from overhead and margin.

Use the cause to choose the correction:

- If actual hours repeat above estimated hours, change the effort quantity or its unit driver.
- If senior staff do work assigned to junior staff, change the role mix.
- If pay or supplier prices changed, update the relevant cost rate or fixed cost.
- If omitted work entered through a vague boundary, define or exclude that work.
- If a named uncertainty repeats, price that risk rather than adding a general uplift.
- If unapproved additions caused the difference, improve change control instead of the base estimate.

Do not apply one portfolio-wide percentage to discovery, delivery, travel and support when their causes differ.

Contingency also needs a named reason. Our guide to [pricing contingency from uncertainty](/blog/contingency-implementation-project-estimate) shows how to price recorded risks instead of adding an unexplained percentage.

Keep sell price and delivery cost separate. Before you change a margin target, check effort estimates and cost rates, then review commercial discounts.

## Test the correction on the next estimate

Record the change as a test. Name the work type, component, old method, new method, evidence period, and review date.

For example:

> For training work, estimate preparation by module rather than as one project total. Keep the delivery duration and role rates unchanged. Review after the next three completed training items.

You can assess this specific test, which also tells the estimator what not to alter.

Use the revised method only on comparable work, not on implementation simply because it shares a proposal with discovery. Keep both calculations visible so the team can explain the change.

After the test work is complete, repeat the comparison and keep the change if it reduces repeated bias without creating bias in the other direction. Otherwise, reverse or adjust it.

Do not change the method after every project. Check for exceptional events before you make a permanent price increase.

## Make the review part of estimating

Give one person responsibility for the work-type list and sign convention. Ask delivery leads to add cause notes while details are still clear.

Run the review on a fixed cycle that matches your project volume. Include enough completed work to compare, but keep the cycle short enough to inform current proposals.

Bring three outputs to the meeting:

1. the comparison by work type;
2. the bias matrix with evidence notes;
3. one proposed component change for each supported bias.

Do not leave with a general instruction to “estimate better”. Assign each accepted change to the estimate template or scope method that needs it.

Korrel carries scope, rates, and estimate components into delivery. Its analytics compare forecast and actual cost by work type for active projects. A separate view shows estimate bias across completed projects. [Start your trial](https://app.korrel.ai/signup) and use completed work to make one supported estimating change.

## Common questions

### What is estimate bias?

In this review, estimate bias means a repeated tendency to estimate above or below the actual result. Check comparable completed work before you treat a difference as a pattern.

### How many work types should a consultancy use?

Use the smallest set that separates work with different delivery patterns. Start with the service types already used in proposals, time records, or project reviews. Split a type only when its results contain two clear patterns.