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.

Document control

Approvals

Revision history

Contents

1. Estimate purpose and class
2. Scope baseline
3. Estimating approach
4. Functional size cross-check
5. Work package effort
6. Effort by role and phase
7. Rates and labour cost
8. Non-labour costs
9. Contingency, reserve and cost baseline
10. Confidence range and schedule implications
11. Assumptions, dependencies and exclusions
12. Comparison with history
13. Review, sign-off and re-estimation
14. Glossary and references

1. Estimate purpose and class

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.

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

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

3. Estimating approach

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

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

4.3 Conversion and comparison

5. Work package effort

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

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}$.

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

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

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

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

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

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$.

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.

9.3 Cost baseline and budget

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.

10. Confidence range and schedule implications

10.1 Range

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

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

11.1 Assumptions

11.2 Dependencies

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

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

13.1 Review checklist

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

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

14. Glossary and references

14.1 Glossary

14.2 References

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.