# Solution Effort and Cost Estimate: [Solution or bid name]

> Effort and cost estimate for delivering a solution, built bottom-up
> from the work breakdown structure and cross-checked with a functional
> size count: scope baseline, estimate class, method, sizing, three-point
> (PERT) effort per work package, effort by role and phase, rates,
> non-labour costs, contingency and management reserve, confidence range,
> schedule implications, assumptions and exclusions, comparison with
> history and sign-off. Structure aligned with the estimating practice
> described in the PMI PMBOK Guide, Eighth Edition (2025), the five
> estimate classes of AACE International Recommended Practice 17R-97,
> and the functional size methods of ISO/IEC 20926:2009 (IFPUG) and
> ISO/IEC 19761:2011 (COSMIC, Measurement Manual v5.0). Replace every
> `[bracketed]` value and every row marked *Example*. This is a format
> for estimating, not a commercial offer or financial advice.

<!--
Guidance: How to use this template
- Write one estimate per scope baseline. When scope changes, issue a new
  version; never edit the numbers of an approved version in place.
- Fix the scope (section 2) and the estimate class (section 1) before you
  collect numbers. An estimate without a stated class and range is read
  as a promise.
- Estimate effort first (person-days), then convert to cost with rates.
  Keep effort and price separate: price is a commercial decision taken
  on top of the cost baseline (section 9.4).
- Use at least two independent methods (bottom-up plus a functional size
  or analogous cross-check) and explain any gap above your tolerance.
- The worked example follows one solution through the whole file: a
  customer self-service portal integrated with an existing CRM and
  identity provider. The same example appears in Bill of Materials
  (`business/bill-of-materials`), so the non-labour lines match.
- Related documents: Work Breakdown Structure
  (`project/work-breakdown-structure`), Bill of Materials
  (`business/bill-of-materials`), RAID Log (`project/raid-log`),
  Resource Plan (`project/resource-plan`), Project Schedule
  (`project/project-schedule`), Statement of Work
  (`business/statement-of-work`), RFP Technical Response
  (`business/rfp-technical-response`), Quote or Estimate
  (`business/quote-estimate`) for a simple priced quote.
-->

## Document control

<!-- Guidance: Identify the scope baseline this estimate prices and who is accountable for it. The estimator and the reviewer must be different people. -->

| Field | Value |
|---|---|
| Document ID | [EST-001] |
| Solution or bid | [Solution name], [Opportunity or project code] |
| Customer or sponsor | [Organisation] |
| Scope baseline | [SoW / requirements / HLD reference and version] |
| Estimate class | [Class 5 / 4 / 3 / 2 / 1] (section 1.2) |
| Estimate purpose | [Feasibility / Budget request / Bid / Baseline / Re-estimate] |
| Currency and price basis | [USD], [nominal], rates valid to YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (lead estimator) | [@solution-architect] |
| Approvers/reviewers | [@delivery-manager], [@commercial-lead], [@peer-estimator] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential / Commercial in confidence] |
| Related documents | [WBS-NNN], [BOM-NNN], [RAID-NNN], [SOW-NNN] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Lead estimator | [@name] | [Submitted] | YYYY-MM-DD |
| Independent peer reviewer | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Delivery manager | [@name] | [Decision] | YYYY-MM-DD |
| Commercial or finance lead | [@name] | [Decision] | YYYY-MM-DD |
| Bid or project sponsor | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft, Class 4 from discovery workshops |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Three-point estimates per work package, COSMIC cross-check added |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved as Class 3 bid estimate after peer review |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Estimate purpose and class](#1-estimate-purpose-and-class)
2. [Scope baseline](#2-scope-baseline)
3. [Estimating approach](#3-estimating-approach)
4. [Functional size cross-check](#4-functional-size-cross-check)
5. [Work package effort](#5-work-package-effort)
6. [Effort by role and phase](#6-effort-by-role-and-phase)
7. [Rates and labour cost](#7-rates-and-labour-cost)
8. [Non-labour costs](#8-non-labour-costs)
9. [Contingency, reserve and cost baseline](#9-contingency-reserve-and-cost-baseline)
10. [Confidence range and schedule implications](#10-confidence-range-and-schedule-implications)
11. [Assumptions, dependencies and exclusions](#11-assumptions-dependencies-and-exclusions)
12. [Comparison with history](#12-comparison-with-history)
13. [Review, sign-off and re-estimation](#13-review-sign-off-and-re-estimation)
14. [Glossary and references](#14-glossary-and-references)

## 1. Estimate purpose and class

<!-- Guidance: Say what decision the estimate supports and how mature the definition is. Readers judge an estimate by its class: a Class 5 number used as a fixed price is the most common and most expensive misuse. -->

### 1.1 Purpose

[State the decision this estimate supports, for example a go or no-go on
a bid, a budget request, or the cost baseline for a contracted project.]
*Example:* This estimate prices the delivery of the customer self-service
portal described in HLD v1.2 for the fixed-price bid due YYYY-MM-DD. It
becomes the cost baseline if the bid is won.

### 1.2 Estimate class

AACE International classifies estimates into five classes (Class 5, least
defined, to Class 1, most defined) and uses the maturity of the scope
definition as the main characteristic of each class. The ranges below are
your organisation's own targets, not figures from the recommended
practice; agree them with your delivery and commercial leads.

| Class | Typical use | Definition available | Target range (your policy) |
|---|---|---|---|
| 5 | Idea screening, opportunity qualification | Problem statement, a few conversations | [*Example:* -50% to +100%] |
| 4 | Feasibility, early budget request | Capability list, context diagram | [*Example:* -30% to +50%] |
| 3 | Budget authorisation, business case, bid with priced risk | Requirements baseline, HLD, integration list | [*Example:* -20% to +30%] |
| 2 | Control baseline, bid or tender, fixed price | Detailed design for most components | [*Example:* -15% to +20%] |
| 1 | Check estimate, bid or tender, re-estimate of remaining work | Design complete, work under way | [*Example:* -10% to +15%] |

Selected class: [*Example:* Class 3. Requirements baseline v1.0, HLD v1.2
and the interface list are approved; detailed designs do not exist yet.]

*Example:* Bidding a fixed price on a Class 3 estimate is a deliberate
exception to the class table. It is accepted only because the discrete
risks are priced as expected monetary value in section 9.2, contingency
is held at P80, and the sponsor approves the exposure in writing. If any
of these conditions is missing, bid capped time and materials or ask for
a paid discovery phase that brings the estimate to Class 2.

## 2. Scope baseline

<!-- Guidance: List the documents and versions that define what is priced. Anything not traceable to the baseline is either an exclusion or an unpriced risk. -->

| Baseline item | Reference and version | Notes |
|---|---|---|
| Requirements | [BRD / SRS ID, version] | *Example:* 46 functional, 31 non-functional requirements |
| Architecture | [HLD ID, version] | *Example:* HLD v1.2, approved by the design authority |
| Interfaces | [Interface list ID] | *Example:* 4 interfaces: CRM (REST), identity provider (OIDC), email (SMTP API), document store |
| Data migration | [Data migration strategy ID] | *Example:* 180,000 customer accounts, 1.2 million cases |
| Environments | [Environment plan] | *Example:* DEV, SIT, UAT, PROD, DR |
| Service transition | [Hypercare scope] | *Example:* 4 weeks of hypercare after go-live |
| WBS | [WBS ID, version] | Section 5 uses the same IDs |

In scope: [list the deliverables]. Out of scope: [list items, and move
them to section 11.3].

## 3. Estimating approach

<!-- Guidance: Name each method, where it is used and why. One method alone hides its own bias; two methods that agree within tolerance build confidence. -->

| Method | Where used | Evidence | Strength | Limitation |
|---|---|---|---|---|
| Bottom-up three-point (PERT) | Every work package in section 5 | Estimates from the people who will do the work | Detailed, exposes uncertainty | Misses work that is not in the WBS |
| Functional size (COSMIC or IFPUG) | Build and integration packages | Count of functional processes from requirements | Independent of team opinion | Needs a calibrated productivity rate |
| Analogous | Whole-project cross-check | Actuals from comparable past projects (section 12) | Quick, grounded in reality | Projects are never fully alike |
| Parametric | Testing, project management | Ratios from history, for example PM effort as a share of delivery effort | Consistent | Ratios drift with delivery model |
| Expert judgement (wideband Delphi) | Novel components | Two or more experts estimate independently, then converge | Captures tacit knowledge | Anchoring if experts confer too early |

Rules applied in this estimate:

1. Estimate in person-days of 8 working hours of effort on the task.
   Leave, holidays and non-project time are applied once, as the
   availability ratio in section 10.2, when converting to calendar time.
2. Estimators give optimistic, most likely and pessimistic values without
   seeing each other's numbers first.
3. Every work package has one named estimator and one assumption ID.
4. Tolerance between methods: the bottom-up and functional size
   estimates for the same scope must agree within [*Example:* 15%], or the
   gap is explained in section 4.3.

## 4. Functional size cross-check

<!-- Guidance: Size the functionality independently of the WBS, then convert size to effort with a productivity rate from your own history. Use COSMIC or IFPUG consistently; do not mix units. -->

### 4.1 Method

[Choose one.] COSMIC (ISO/IEC 19761:2011) sizes each functional process
by counting its data movements: Entries (E) and Exits (X) cross the
boundary with a user or another system, Reads (R) and Writes (W) touch
persistent storage. Each data movement counts as one COSMIC function
point (CFP). IFPUG function point analysis (ISO/IEC 20926:2009) counts
data functions and transactional functions and weights them by
complexity. Follow the official measurement manual for counting rules;
this section records your count, not the rules.

### 4.2 Count

| Process ID | Functional process | E | X | R | W | CFP |
|---|---|---|---|---|---|---|
| FP-01 *(Example)* | Register customer account | 1 | 2 | 1 | 1 | 5 |
| FP-02 *(Example)* | Sign in through identity provider | 1 | 1 | 1 | 0 | 3 |
| FP-03 *(Example)* | View open cases | 1 | 2 | 2 | 0 | 5 |
| FP-04 *(Example)* | Create case and send to CRM | 1 | 2 | 1 | 1 | 5 |
| FP-05 *(Example)* | Update profile | 1 | 1 | 1 | 1 | 4 |
| FP-06 *(Example)* | Upload attachment to a case | 1 | 1 | 0 | 1 | 3 |
| Sample subtotal | 6 of 48 processes | 6 | 9 | 6 | 4 | 25 |
| **Total** *(Example)* | 48 functional processes | | | | | **212** |

### 4.3 Conversion and comparison

| Item | Value |
|---|---|
| Productivity rate (build and unit test, from section 12) | *Example:* 0.65 person-days per CFP |
| Size-based effort for build and integration | *Example:* 212 x 0.65 = 137.8 person-days |
| Bottom-up effort for the same scope (WBS 1.3 + 1.4, section 5) | *Example:* 83.3 + 65.0 = 148.3 person-days |
| Difference | *Example:* 148.3 - 137.8 = 10.5 person-days, 7.6% above the size-based figure |
| Within tolerance? | *Example:* Yes (limit 15%). The excess is resilience work on the CRM interface (retries, idempotency), which functional size does not measure |

## 5. Work package effort

<!-- Guidance: Estimate each lowest-level WBS element with optimistic (O), most likely (M) and pessimistic (P) values. Compute the PERT expected value and standard deviation. A pessimistic value close to the most likely value usually means the estimator has not thought about what can go wrong. -->

For each work package the PERT (beta) approximation gives:

$$
E = \frac{O + 4M + P}{6}, \qquad \sigma = \frac{P - O}{6}
$$

For the total, expected values add, and, if work packages are treated as
independent, variances add: $E_{total} = \sum E_i$ and
$\sigma_{total} = \sqrt{\sum \sigma_i^2}$.

| WBS | Work package | Estimator | O | M | P | E | σ | σ² |
|---|---|---|---|---|---|---|---|---|
| 1.1 *(Example)* | Project management and governance | @pm | 40 | 50 | 70 | 51.67 | 5.00 | 25.00 |
| 1.2 *(Example)* | Discovery and detailed design | @sa | 30 | 40 | 60 | 41.67 | 5.00 | 25.00 |
| 1.3 *(Example)* | Portal front end and services | @dev-lead | 60 | 80 | 120 | 83.33 | 10.00 | 100.00 |
| 1.4 *(Example)* | Integration (CRM, identity, email) | @int-lead | 40 | 60 | 110 | 65.00 | 11.67 | 136.11 |
| 1.5 *(Example)* | Data migration | @data-lead | 20 | 30 | 55 | 32.50 | 5.83 | 34.03 |
| 1.6 *(Example)* | Testing (SIT, performance, security support) | @qa-lead | 35 | 45 | 70 | 47.50 | 5.83 | 34.03 |
| 1.7 *(Example)* | Environments and delivery pipeline | @devops | 15 | 20 | 30 | 20.83 | 2.50 | 6.25 |
| 1.8 *(Example)* | Deployment, cutover and hypercare | @pm | 15 | 20 | 35 | 21.67 | 3.33 | 11.11 |
| **Total** | | | **255** | **345** | **550** | **364.17** | **19.28** | **371.53** |

*Example* check: $E_{total} = (255 + 4 \times 345 + 550) / 6 = 2185 / 6 = 364.17$
person-days, and $\sigma_{total} = \sqrt{371.53} = 19.28$ person-days.
The total σ is not the sum of the individual σ values (295 / 6 = 49.17); summing
them would overstate the spread for independent packages.

## 6. Effort by role and phase

<!-- Guidance: Allocate the expected effort to roles and phases so that the resource plan and rate card can be applied. Rows and columns must both add up to the same total; a mismatch means effort was lost or invented. -->

The expected total of 364.17 person-days is planned as 364 person-days.

| Role | Mobilise and design | Build | Test | Deploy and hypercare | Total |
|---|---|---|---|---|---|
| Solution architect *(Example)* | 14 | 10 | 3 | 3 | 30 |
| Project manager *(Example)* | 10 | 20 | 8 | 7 | 45 |
| Business analyst *(Example)* | 20 | 8 | 5 | 2 | 35 |
| Senior developer *(Example)* | 10 | 65 | 8 | 7 | 90 |
| Developer *(Example)* | 4 | 62 | 8 | 6 | 80 |
| Integration engineer *(Example)* | 6 | 18 | 3 | 3 | 30 |
| QA engineer *(Example)* | 4 | 2 | 26 | 8 | 40 |
| DevOps engineer *(Example)* | 4 | 4 | 2 | 4 | 14 |
| **Total** | **72** | **189** | **63** | **40** | **364** |

Check the shape against history: in the example, testing (63 of 364, 17%)
and project management (45 of 364, 12%) sit inside the ratios observed
on past projects in section 12. A testing share far below your history
is a warning sign, not a saving.

## 7. Rates and labour cost

<!-- Guidance: Use cost rates (fully loaded internal cost or subcontractor buy rate), not sell rates. State the source and validity of the rate card. Blended rates hide skill mix; keep rates per role. -->

| Role | Person-days | Cost rate per day (USD) | Labour cost (USD) | Rate source |
|---|---|---|---|---|
| Solution architect *(Example)* | 30 | 1,100 | 33,000 | Rate card RC-2026 |
| Project manager *(Example)* | 45 | 950 | 42,750 | Rate card RC-2026 |
| Business analyst *(Example)* | 35 | 800 | 28,000 | Rate card RC-2026 |
| Senior developer *(Example)* | 90 | 850 | 76,500 | Rate card RC-2026 |
| Developer *(Example)* | 80 | 650 | 52,000 | Rate card RC-2026 |
| Integration engineer *(Example)* | 30 | 850 | 25,500 | Subcontractor quote Q-118 |
| QA engineer *(Example)* | 40 | 600 | 24,000 | Rate card RC-2026 |
| DevOps engineer *(Example)* | 14 | 800 | 11,200 | Rate card RC-2026 |
| **Total** | **364** | | **292,950** | |

*Example:* the average cost rate is 292,950 / 364 = USD 804.81 per
person-day. Section 9 uses it to convert effort contingency to cost.

Rate assumptions: [working days per month, overtime policy, travel time
treatment, annual rate increases if the project spans a rate change,
offshore or nearshore mix, currency of subcontractor rates].

## 8. Non-labour costs

<!-- Guidance: List every cost that is not people time during delivery. Take cloud, licence and hardware prices from the Bill of Materials so the two documents cannot drift; mark here which BoM lines are carried inside this estimate. -->

| ID | Item | Basis | Cost (USD) | BoM reference |
|---|---|---|---|---|
| NL-01 *(Example)* | Non-production cloud environments during delivery | 4 months x 449.86 per month = 1,799.44, rounded | 1,800 | BOM-CL-101 to BOM-CL-104 |
| NL-02 *(Example)* | Test automation tool licences | 4 named users x 1,050 per year | 4,200 | BOM-SW-002 |
| NL-03 *(Example)* | Travel for on-site workshops and cutover | 6 trips x 1,000 | 6,000 | Not in BoM |
| NL-04 *(Example)* | Independent penetration test | Fixed quote from test provider | 12,000 | BOM-PS-002 |
| NL-05 *(Example)* | Production and DR cloud from go-live to the end of hypercare | 1 month x (1,352.88 + 294.20) = 1,647.08, rounded | 1,650 | BOM-CL-001 to BOM-CL-006, BOM-CL-201, BOM-CL-202 |
| **Total** | | | **25,650** | |

Production and DR environments run from go-live while the supplier is
still accountable (4 weeks of hypercare), so their cost sits inside the
delivery price. From the start of Year 1 the customer pays them as run
cost (BoM section 12).

## 9. Contingency, reserve and cost baseline

<!-- Guidance: Separate the allowance for known uncertainty (contingency, owned by the delivery manager) from the allowance for unknown events (management reserve, owned by the sponsor). Do not hide either inside inflated work package estimates. -->

### 9.1 Contingency for estimating uncertainty

The example sets the effort target at the 80th percentile (P80). With
the normal approximation of the total, $P80 \approx E + 0.8416\,\sigma$.

| Item | Value |
|---|---|
| Expected effort E | *Example:* 364.17 person-days |
| Total σ | *Example:* 19.28 person-days |
| P80 effort | *Example:* 364.17 + 0.8416 x 19.28 = 380.40 person-days |
| Effort contingency (P80 - E) | *Example:* 16.23 person-days |
| Contingency cost at average rate | *Example:* 16.23 x 804.81 = 13,062.07, rounded USD 13,062 |

### 9.2 Contingency for discrete risks

Price risks that are not already inside the three-point ranges, using
expected monetary value (probability times cost impact). Keep the risk IDs
identical to the RAID Log.

| Risk ID | Risk | Probability | Cost impact (USD) | EMV (USD) |
|---|---|---|---|---|
| RSK-011 *(Example)* | CRM API limits force a caching layer | 30% | 12,750 | 3,825 |
| RSK-012 *(Example)* | Source data quality worse than profiled; extra cleansing cycle | 40% | 8,000 | 3,200 |
| RSK-013 *(Example)* | Identity federation needs an extra customer security review | 20% | 6,000 | 1,200 |
| **Total** | | | | **8,225** |

### 9.3 Cost baseline and budget

| Line | Basis | USD |
|---|---|---|
| Labour cost | Section 7 | *Example:* 292,950 |
| Non-labour cost | Section 8 | *Example:* 25,650 |
| **Base cost** | Labour + non-labour | **318,600** *(Example)* |
| Contingency, estimating uncertainty | Section 9.1 | *Example:* 13,062 |
| Contingency, discrete risks | Section 9.2 | *Example:* 8,225 |
| **Cost baseline** | Base cost + contingency | **339,887** *(Example)* |
| Management reserve | *Example:* 5% of base cost = 15,930.00 | *Example:* 15,930 |
| **Total budget** | Cost baseline + management reserve | **355,817** *(Example)* |

Release rules: [*Example:* the delivery manager draws contingency against
a named risk or variance and records it in the change log; management
reserve needs sponsor approval and a change request].

### 9.4 Hand-off to pricing

Pricing is owned by the commercial lead. Record what was handed over so
the link between cost and price stays auditable.

| Item | Value |
|---|---|
| Cost baseline handed over | *Example:* USD 339,887 |
| Pricing model | [Fixed price / Time and materials / Capped T&M / Milestone-based] |
| Target gross margin on cost baseline | *Example:* 30% |
| Indicative price, cost baseline / (1 - margin) | *Example:* 339,887 / 0.70 = 485,552.86, rounded USD 485,553 |
| Management reserve treatment | *Example:* Held by the supplier, not priced separately |
| Price owner and date | [@commercial-lead], YYYY-MM-DD |

## 10. Confidence range and schedule implications

<!-- Guidance: Show the range, not only the point. Explain what moves the estimate from one end to the other. Then translate effort into duration and team size, and check the result against the customer's dates. -->

### 10.1 Range

| Measure | Effort (person-days) | Comment |
|---|---|---|
| Sum of optimistic values | *Example:* 255 | Every package goes well at once; not a realistic target |
| Expected (P50 approximation) | *Example:* 364.17 | Planning value |
| P80 | *Example:* 380.40 | Effort target including contingency |
| P90 | *Example:* 364.17 + 1.2816 x 19.28 = 388.88 | Use for fixed-price exposure checks |
| Sum of pessimistic values | *Example:* 550 | Every package goes badly at once; use only to test worst-case affordability |

The P80 and P90 figures assume the work packages are independent. Risks
that hit several packages at once (for example a late design approval)
make the real spread wider; price those as discrete risks in section
9.2.

### 10.2 Duration and team

| Phase | Effort | Team size | Availability ratio (leave, holidays, non-project time) | Working days | Months (20 days) |
|---|---|---|---|---|---|
| Mobilise and design *(Example)* | 72 | 4 | 0.85 | 72 / 3.40 = 21.18 | 1.06 |
| Build *(Example)* | 189 | 7 | 0.85 | 189 / 5.95 = 31.76 | 1.59 |
| Test *(Example)* | 63 | 5 | 0.85 | 63 / 4.25 = 14.82 | 0.74 |
| Deploy and hypercare *(Example)* | 40 | 4 | 0.85 | 40 / 3.40 = 11.76 | 0.59 |
| **Total** | **364** | | | **79.52** | **3.98** |

*Example:* about 4 months end to end with phases run in sequence. The
customer's target go-live is in 5 months, which leaves about one month
of schedule float. Compressing to 3 months would need overlapping build
and test and a larger team, which raises coordination effort; re-estimate
rather than scaling the numbers.

## 11. Assumptions, dependencies and exclusions

<!-- Guidance: Every assumption must be testable and have an owner and a date by which it is confirmed. Record the impact if it proves false, so the change request is already half written. -->

### 11.1 Assumptions

| ID | Assumption | Impact if false | Owner | Validate by |
|---|---|---|---|---|
| ASM-001 *(Example)* | The CRM vendor provides a sandbox with production-like APIs from week 2 | Integration build slips; up to 10 extra days | Customer IT | YYYY-MM-DD |
| ASM-002 *(Example)* | Customer subject matter experts are available 2 days a week during design | Design phase extends | Customer project manager | YYYY-MM-DD |
| ASM-003 *(Example)* | UAT is executed by the customer; supplier supports with 1 QA engineer | Test effort rises by about 15 days | Customer | YYYY-MM-DD |
| ASM-004 *(Example)* | No more than two UI languages | Each extra language adds about 4 days | Product owner | YYYY-MM-DD |

### 11.2 Dependencies

| ID | Dependency | Provider | Needed by | Status |
|---|---|---|---|---|
| DEP-001 *(Example)* | Identity provider tenant and test users | Customer security team | Week 3 | Open |
| DEP-002 *(Example)* | Data extract of customer accounts | Customer data team | Week 6 | Open |

### 11.3 Exclusions

[List what is not priced.] *Example:* production and DR cloud running
costs after hypercare (see BoM, Years 1 to 3), CRM licence changes, content
writing and translation, accessibility audit by a third party, end-user
training beyond two train-the-trainer sessions, support after the
4-week hypercare period.

## 12. Comparison with history

<!-- Guidance: Compare the result with actuals, not with past estimates. If you have no history, say so and lower your confidence; do not borrow industry averages and present them as your own. -->

| Past project | Scope similarity | Size (CFP) | Actual effort | Days per CFP | Estimate vs actual |
|---|---|---|---|---|---|
| PRJ-2024-07 *(Example)* | Portal, 2 interfaces | 150 | 108 days build | 0.72 | Estimated 95, actual 108 (+14%) |
| PRJ-2025-02 *(Example)* | Portal, 3 interfaces | 190 | 118 days build | 0.62 | Estimated 120, actual 118 (-2%) |
| PRJ-2025-11 *(Example)* | Partner portal, 4 interfaces | 240 | 146 days build | 0.61 | Estimated 130, actual 146 (+12%) |
| **This estimate** | Portal, 4 interfaces | 212 | 148.3 days build (bottom-up) | 0.70 | |

*Example* reading: the productivity rate of 0.65 used in section 4 is the
mean of the three past rates, (0.72 + 0.62 + 0.61) / 3 = 0.65. This
estimate's bottom-up rate, 148.3 / 212 = 0.70, is within the observed
range. Two of three past projects overran by more than 10%, which
supports holding contingency at P80 rather than P50.

## 13. Review, sign-off and re-estimation

<!-- Guidance: An estimate is approved only after an independent review. Define the events that force a re-estimate so the baseline is not stretched silently. -->

### 13.1 Review checklist

| Check | Result | Reviewer |
|---|---|---|
| Every requirement and deliverable maps to at least one work package | [Pass / Fail] | [@name] |
| Project management, testing, environments, cutover and hypercare are included | [Pass / Fail] | [@name] |
| Each work package has O, M and P values from a named estimator | [Pass / Fail] | [@name] |
| Row and column totals in section 6 agree with section 5 | [Pass / Fail] | [@name] |
| Non-labour lines match the Bill of Materials version | [Pass / Fail] | [@name] |
| Contingency and management reserve are separate and justified | [Pass / Fail] | [@name] |
| Functional size cross-check within tolerance, or the gap explained | [Pass / Fail] | [@name] |
| Assumptions are testable, owned and dated | [Pass / Fail] | [@name] |
| Estimate class and range are stated on every summary that quotes the number | [Pass / Fail] | [@name] |

### 13.2 Re-estimation triggers

Re-estimate and issue a new version when any of these occurs:

- an approved change request alters the scope baseline in section 2;
- an assumption in section 11.1 is proved false;
- actual effort to date departs from the plan by more than [*Example:*
  10%] at a phase gate;
- the design matures enough to move to a better estimate class;
- the rate card, team location mix or delivery model changes.

### 13.3 Roles

| Activity | Solution architect | Delivery manager | Estimators | Commercial lead | Sponsor |
|---|---|---|---|---|---|
| Define scope baseline and class | A | C | C | I | I |
| Three-point estimates | C | C | R | I | I |
| Functional size count | R | I | C | I | I |
| Contingency and reserve | C | R | C | C | A |
| Pricing on top of cost baseline | C | C | I | R | A |
| Approval | C | R | I | C | A |

R = responsible, A = accountable, C = consulted, I = informed.

## 14. Glossary and references

<!-- Guidance: Define the estimating terms used here and list the sources consulted with the version you checked. -->

### 14.1 Glossary

| Term | Meaning in this template |
|---|---|
| Estimate class | Category of an estimate set by how mature the scope definition is, which in turn implies its expected range |
| Three-point estimate | Optimistic, most likely and pessimistic values for the same work |
| PERT expected value | Weighted mean (O + 4M + P) / 6 of a three-point estimate |
| P80 | Value that the outcome is expected not to exceed in 80% of cases |
| Contingency | Allowance for identified uncertainty and risks, inside the cost baseline |
| Management reserve | Allowance for unidentified events, outside the cost baseline, released by the sponsor |
| Cost baseline | Approved cost including contingency, used to measure performance |
| CFP | COSMIC function point: one data movement of a functional process |
| Productivity rate | Effort per unit of size, taken from your own completed projects |
| EMV | Expected monetary value: probability multiplied by cost impact |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), pmi.org | Eighth Edition, November 2025 | Estimating, contingency and reserve concepts (structure only) |
| AACE International, Recommended Practice 17R-97, Cost Estimate Classification System, aacei.org | Check the current revision | Five estimate classes, maturity of definition as the main characteristic |
| ISO/IEC 20926:2009, IFPUG functional size measurement method, iso.org | 2009 edition; check the current review status at iso.org | Function point option in section 4 |
| ISO/IEC 19761:2011, COSMIC functional size measurement method, iso.org | 2011 edition; check the current review status at iso.org | COSMIC option in section 4 |
| COSMIC Measurement Manual, cosmic-sizing.org | Version 5.0 (Part 1 Principles, definitions and rules, May 2020; Part 2 Guidelines, May 2020) | Counting rules to follow |
| B. Boehm et al., Software Cost Estimation with COCOMO II, Prentice Hall | 2000 | Background on parametric models |
| [Internal rate card] | [Version, valid to YYYY-MM-DD] | Section 7 |
| [Internal estimating history] | [Extract date] | Section 12 |

## Standard and licence note

Structure aligned with the estimating, contingency and reserve concepts
of the PMI PMBOK Guide, Eighth Edition (2025), the estimate class concept
of AACE International Recommended Practice 17R-97, and the functional
size measurement methods standardised as ISO/IEC 20926:2009 (IFPUG) and
ISO/IEC 19761:2011 (COSMIC). These are copyrighted works: only their
names, concepts and the five-class structure are used, and no text,
tables, definitions or accuracy ranges are reproduced. The PERT formula
is common public practice. All text and worked figures are original and
illustrative. Check the current editions at pmi.org, aacei.org, iso.org
and cosmic-sizing.org and obtain the documents for their full rules.
PMBOK is a registered mark of the Project Management Institute, Inc.
Template licence: MIT.