Basis of Estimate — Software Services
No steel, no concrete — cost is effort. A software services estimate is overwhelmingly labour, which flips the BOE's emphasis onto how the work was sized, the productivity assumed, and the slipperiest variable of all: how stable the requirements are. It's a reminder that the estimating discipline travels far beyond construction. Built on AACE 74R-13.
What this standard adds
Software services is the most different cost-estimating domain in the module — a useful reminder that estimating principles span far beyond construction. The general BOE backbone (Lesson 14) still holds, but the make-or-break entries are entirely different: there are no battery limits or equipment lists, just effort, productivity, and requirements.
Why software services are distinctive
- Effort is the cost — Labour dominates; there's little material or equipment. Estimating is really about hours, roles, and rates.
- Sizing is abstract — "How big is the software?" has no tape-measure answer — it's gauged by proxies like function points, story points, or component counts.
- Productivity varies wildly — Output per person-hour depends heavily on team skill, technology, and complexity — far more variable than construction crews.
- Requirements are volatile — Software requirements routinely change during delivery; how stable they are is the dominant risk to the estimate.
What to document in a software BOE
| Element | Software emphasis |
|---|---|
| Scope & requirements basis | The requirements baseline assumed and its stability |
| Sizing method | How size was measured (function/story points, components) |
| Productivity assumptions | Effort per unit of size, and its source/history |
| Team & skills | Roles, skill levels, and rates assumed |
| Technology & environment | Platforms, tools, reuse, and constraints |
| Lifecycle & method | Waterfall/agile, and what phases are included |
| Assumptions & contingency | Volatility allowance and key risks |
Using the software BOE well
For a software services estimate, lead the BOE with the requirements baseline and its assumed stability, document the sizing method and productivity rates with their sources, and state the team, technology, and lifecycle assumptions. Carry explicit contingency for requirements volatility. Done well, it makes an inherently fuzzy estimate reviewable and honest about its biggest risk.
Nine things to remember
- 74R-13 tailors the general BOE to software services — effort, not materials.
- Cost ≈ size × effort-rate — sizing and productivity are the two pillars.
- Sizing is abstract — function points, story points, or component counts.
- Productivity varies wildly — document the rate and its source.
- Requirements volatility is software's "ground risk" — state the baseline and its stability.
- Document team, skills, technology, and lifecycle (waterfall/agile).
- Carry explicit contingency for volatility — don't assume frozen requirements.
- Agile reshapes the BOE — velocity and capacity replace a fixed feature list.
- Estimating is universal — the BOE does the same job in any domain.
Glossary
- Basis of estimate
- The documentation of how the estimate was prepared.
- Function point
- A unit measuring software functionality delivered.
- Productivity
- Effort per unit of size (e.g., hours per function point).
- Requirements volatility
- The degree to which requirements change — the key risk.
- Sizing
- Measuring the "size" of software work via proxies.
- Software services
- Software development and IT delivery work.
- Story point
- An agile relative-size estimate for a work item.
- Velocity
- Work an agile team completes per iteration.