Effort, Duration and Cost Estimation

Introduction

Project planning depends on credible answers to three related but different questions: How much work is required? How long will the work take? What will it cost? These questions concern effort, duration, and cost respectively. Confusing them produces unrealistic schedules, weak budgets, and poor management decisions.

Estimation is not prediction with certainty. It is a reasoned assessment based on available information, historical evidence, models, assumptions, and professional judgment. Early estimates normally have wider uncertainty because requirements, technology, team composition, and constraints are not yet fully known. As the project develops, estimates should be refined rather than silently replaced.

This chapter presents practical estimation approaches used in software projects: expert judgment, analogous estimation, parametric estimation, bottom-up estimation, three-point estimation, story points, and software-sizing techniques.

Learning Objectives

By the end of this chapter, the learner should be able to:

• distinguish effort, duration, cost, and productivity;
• select an appropriate estimation technique for a project situation;
• apply expert judgment, analogous, parametric, bottom-up, and three-point estimation;
• explain story points and software-sizing measures such as lines of code and function points;
• calculate simple estimates using defensible assumptions;
• document uncertainty, assumptions, exclusions, and confidence levels; and
• recognize estimation risks, ethical responsibilities, and the appropriate use of tools and AI.

1. The Three Fundamental Quantities

Effort

Effort is the amount of labor required to complete work. It is usually expressed in person-hours, person-days, or person-months. One person-day is a measurement convention, not necessarily one calendar day of work. An organization must define whether it means, for example, eight productive hours or a standard accounting day.

Duration

Duration is elapsed calendar time between the start and finish of an activity or project. Duration depends on effort, staffing, dependencies, working calendars, interruptions, approvals, and resource availability.

A simplified relationship is:

This is only an approximation. It assumes that work can be divided sufficiently, contributors are available throughout, and coordination overhead is negligible. Software work commonly violates all three assumptions.

Cost

Cost is the monetary value of resources consumed. A basic labor-cost relationship is:

Effort must use the same time unit as the labor rate. If effort is 240 person-hours and the rate is £50 per person-hour, labor cost is £12,000. Hardware, software licenses, travel, contractors, training, contingency, and overhead may need separate treatment.

Productivity

Productivity expresses output per unit of effort. For a size measure S and effort E:

For example, if a team delivers 600 function points using 12 person-months, productivity is 50 function points per person-month. Productivity comparisons are meaningful only when measurement definitions, quality expectations, technology, and project context are reasonably comparable.

2. Estimation as a Managed Process

Estimation is best treated as an iterative process:

1. clarify scope and deliverables;
2. identify the product or work breakdown structure;
3. choose a suitable size or estimation basis;
4. select one or more estimation techniques;
5. state assumptions, constraints, exclusions, and risks;
6. calculate effort, duration, and cost;
7. review the estimate with knowledgeable stakeholders;
8. record uncertainty and confidence; and
9. refine the estimate when evidence changes.

A good estimate is traceable. A reviewer should be able to see what was estimated, how it was estimated, which evidence was used, and what could make it wrong.

Estimate, target, and commitment

An estimate is an analytical assessment of likely effort, duration, or cost. A target is a desired business outcome. A commitment is an agreed obligation supported by resources and governance. Treating a target as if it were an estimate encourages optimism bias and schedule pressure. A responsible manager may record both: for example, a forecast of 16 weeks and a management target of 14 weeks, with the risks made explicit.

Progressive elaboration

At initiation, requirements may support only a rough order-of-magnitude estimate. During analysis and design, uncertainty reduces. During implementation, estimates can be based on identified tasks and observed performance. This is not inconsistency; it is normal progressive elaboration.

3. Major Estimation Techniques

3.1 Expert judgment

Expert judgment uses the knowledge of experienced practitioners, project managers, architects, analysts, or subject specialists. It is particularly useful when historical data are scarce or the technology is novel.

A sound expert estimate should be elicited systematically. The estimator should identify assumptions, estimate components separately, explain uncertainty, and invite independent review. Group methods such as wideband Delphi reduce the influence of a dominant participant: experts estimate independently, discuss differences, revise estimates, and repeat until a reasonable convergence is reached.

Strengths include speed, contextual understanding, and applicability to unusual work. Limitations include anchoring, optimism bias, availability bias, political influence, and dependence on the quality of the experts.

3.2 Analogous estimation

Analogous estimation compares the proposed project or work package with completed projects that are similar in size, technology, complexity, team capability, and quality requirements. Historical effort is adjusted for meaningful differences.

For example, a previous customer portal required 10 person-months. The new portal has approximately 20% more functionality but a more experienced team expected to be 10% more productive. A simple multiplicative estimate is:

This calculation assumes that the adjustments are independent and approximately multiplicative. The result is not more accurate merely because it has decimal precision. Similarity must be justified, and historical data must be reliable.

3.3 Parametric estimation

Parametric estimation uses a measurable size parameter and an empirical productivity or cost rate. A general form is:

If size is 40 function points and the historical rate is 0.25 person-months per function point, effort is 10 person-months.

Some models use a power relationship:

where E is effort, S is software size, and a and b are parameters calibrated from historical projects. The exponent b may reflect diseconomies or economies of scale. Such models are useful only when the calibration dataset resembles the project being estimated. A model imported from another organization without validation can create an illusion of scientific accuracy.

3.4 Bottom-up estimation

Bottom-up estimation decomposes the scope into manageable work packages, estimates each package, and aggregates the results. A work breakdown structure might include requirements, user-interface design, database work, implementation, integration, testing, deployment, documentation, and project management.

If work-package efforts are E₁, E₂, …, Eₙ:

Allowances may cover identified integration work, management activities, or risk responses. They should not be an unexplained percentage used to conceal weak analysis.

Bottom-up estimation is generally more defensible once scope is sufficiently understood. It can, however, be time-consuming and may omit work that does not appear in the decomposition. Reviewers should check for testing, security, data migration, training, governance, and operational transition.

3.5 Three-point estimation

Three-point estimation explicitly represents uncertainty with three values:

• Optimistic (O): favorable but realistic conditions;
• Most likely (M): the mode or best assessment under normal conditions; and
• Pessimistic (P): an unfavorable but credible outcome, not an impossible disaster.

A commonly used weighted estimate is the triangular or PERT-style mean:

The PERT-style formula gives greater weight to the most-likely value. It assumes the three values describe the same work and that the chosen distribution is a reasonable approximation. For O = 4 days, M = 7 days, and P = 16 days:

A simple triangular expected value is instead (O + M + P) ÷ 3. The method must be stated because the results differ.

For independent activities, a simplified variance approximation often used with PERT-style estimates is:

The independence assumption is important. Shared technical risks, common resources, and dependencies create correlation; simply adding variances can then misrepresent uncertainty.

4. Software-Sizing Techniques

Effort cannot be estimated well unless the work or product has some measure of size. Size is not the same as effort. A large product may require little effort if it uses mature components; a small product may require substantial effort if its quality, safety, or integration demands are high.

Lines of code

Source lines of code (SLOC) measure software text, usually excluding comments or counting them according to an agreed rule. A rate such as 50 SLOC per person-hour can support a parametric estimate only if language, development practices, generated code, reuse, and counting rules are comparable.

SLOC is difficult to use early because the code does not yet exist. It can also reward verbose programming and disadvantage high-level languages or configuration-based solutions. It is more useful for historical analysis than for early requirements estimation.

Function points

Function points measure user-visible functionality rather than code volume. Traditional function-point analysis classifies functions such as external inputs, external outputs, external inquiries, internal logical files, and external interface files, then applies complexity weights. The exact counting rules must be defined by the adopted standard or organizational method.

A simplified relationship is:

Function points can be useful across programming languages, but counting requires trained judgment and stable requirements. Variants such as COSMIC function points use different measurement concepts; results should not be mixed without adjustment.

Use-case points and feature measures

Use-case points estimate size from actors, use cases, and technical or environmental factors. They can help during requirements analysis but depend heavily on consistent classification. Feature counts, interface counts, data entities, and transactions may also be useful when they have been calibrated against local project data.

Story points

Agile teams often estimate relative size using story points. A story point combines perceived effort, complexity, uncertainty, and sometimes risk. It is not a universal unit of time and should not be converted directly into hours across teams.

A team may use a sequence such as 1, 2, 3, 5, 8, and 13 to express increasing uncertainty. After several iterations, velocity can be observed:

If a team completes 30 points per two-week iteration and 120 points remain, a simple forecast is four iterations, or eight weeks, assuming stable team capacity, backlog quality, and comparable work. This is a forecast, not a guarantee. Velocity should not be used to compare individuals or teams because estimation scales are local and can be gamed.

5. From Effort to Schedule

Converting effort into duration requires a resource-loaded schedule. Consider 40 person-days of work. With one fully available contributor, the theoretical duration is 40 working days. With four contributors, it is not automatically 10 days because of communication, sequential activities, reviews, dependencies, and specialist bottlenecks.

A useful practical distinction is capacity versus availability. A person may work eight hours per day but have only five hours available for project tasks after meetings, support, administration, and interruptions. Capacity planning should also account for holidays, part-time assignments, and ramp-up time.

A project schedule should identify dependencies and the critical path. Adding people to a task on the critical path may shorten it only if the work is divisible and coordination costs are acceptable. Some work is sequential, and late staffing can increase rather than reduce duration.

6. Cost Estimation and Reserves

A cost estimate should identify its components:

Contingency should be based on risk and uncertainty, not used as an arbitrary padding factor. The basis and authority for each reserve must be documented. A budget may include approved reserves while a performance baseline treats them according to the organization’s control rules.

7. Documenting Assumptions and Uncertainty

An estimate should be accompanied by an estimation record containing:

• scope and deliverables included;
• work breakdown or size measure;
• estimation method and calculation;
• data sources and historical comparisons;
• team composition and assumed availability;
• working calendar and productivity assumptions;
• technology, reuse, and integration assumptions;
• exclusions and unresolved requirements;
• risks, dependencies, and sensitivity factors;
• optimistic, most-likely, and pessimistic values where appropriate;
• estimate date, owner, and confidence range; and
• conditions that trigger re-estimation.

Ranges are usually more honest than false precision. For example, “12–16 person-months, medium confidence” communicates more useful information than “14.2 person-months” when requirements remain uncertain. A confidence range is not a promise that the final result must fall inside it; it is a statement about the basis and uncertainty of the estimate.

8. Applied Case: The Community Health Appointment Portal

The following is an illustrative case, not a report of an actual organization.

Background

A small public health organization wants a portal through which patients can search clinics, request appointments, receive notifications, and allow staff to manage availability. The organization has delivered two similar internal web systems. The proposed project must integrate with an existing identity service and a legacy scheduling database.

Problem

The sponsor initially requests completion in 12 calendar weeks with a budget of £60,000. The team must determine whether this is feasible and must explain the assumptions behind its estimate.

Analysis

The team creates a bottom-up work breakdown and estimates person-days using three-point estimates. The results are as follows:

The total expected effort is approximately 142.7 person-days, before explicit project-management effort and risk responses. Suppose project management is estimated at 12% of this subtotal:

Total estimated effort is therefore approximately 159.8 person-days, or about 160 person-days.

The proposed team has three contributors, but their average project availability is 80%. Effective capacity is approximately:

Ignoring dependencies, the labor duration is approximately:

This is about 13.3 five-day working weeks. Integration and security activities also impose sequencing constraints. Consequently, the 12-week target is high risk unless scope is reduced, additional suitable capacity is provided, or the target date changes.

Assume a blended labor rate of £375 per person-day. Labor cost is:

Adding £6,000 for hosting, security testing, and accessibility support produces a direct estimate of £66,000 before any approved contingency. The sponsor’s £60,000 budget is therefore not consistent with the current scope and assumptions.

Approach and solution

The project manager presents three options: retain scope and move the date; retain the date and deliver a smaller first release; or add appropriately skilled capacity while recognizing coordination and onboarding costs. The team recommends a minimum viable release with appointment search, request submission, and staff confirmation. Automated reminders and advanced reporting are deferred.

The estimate record identifies the legacy database as the highest uncertainty. A technical spike is scheduled early, and the estimate will be revised after the spike. The sponsor accepts a 13–14 week forecast for the reduced scope and authorizes a separate contingency reserve.

Outcome

The organization obtains a transparent forecast rather than an unsupported promise. Stakeholders can see the trade-off between scope, schedule, resources, and cost. The decision also creates a baseline for later comparison between estimated and actual effort.

Learning points

• Effort, duration, and cost produced different values and required different assumptions.
• Bottom-up estimates benefited from three-point treatment of uncertainty.
• Resource availability, dependencies, and specialist constraints prevented direct conversion of effort into calendar time.
• A budget target did not automatically become a credible cost estimate.
• Early technical investigation reduced uncertainty before a major commitment.

9. Challenges, Ethics, and Governance

Estimates can be distorted by optimism bias, deliberate underestimation, anchoring on a sponsor’s preferred number, and pressure to win contracts. Ethical practice requires explaining uncertainty rather than hiding it. Managers should not punish teams for honest forecasts or reward estimates that are artificially low.

Governance should define who approves estimates, how baselines are changed, how actuals are recorded, and how estimation performance is reviewed. Accuracy should be assessed fairly: an estimate made with incomplete information should not be judged by the same standard as a detailed construction estimate. Comparing estimates with actuals helps improve organizational learning, but retrospective analysis should distinguish estimation error from scope change, external disruption, and management decisions.

Confidential salary data, supplier rates, and employee performance information must be protected. Estimates should not be used to infer individual productivity without context. In regulated or safety-critical environments, estimation records may form part of audit evidence and must be reproducible.

10. Technology and AI-Assisted Estimation

Project-management tools can calculate schedules, aggregate work packages, track actual effort, and perform scenario analysis. Historical repositories can support parametric models and reference-class forecasting. Monte Carlo simulation can model many possible outcomes, but its value depends on credible input distributions, dependencies, and historical calibration.

AI systems may summarize historical projects, classify work items, identify omitted activities, or suggest estimates from organizational data. They should be treated as decision-support tools. A model may reproduce biased historical estimates, misunderstand novel requirements, expose confidential information, or provide unsupported numerical confidence. Human experts must validate the scope, data quality, assumptions, and implications. AI-generated estimates should be traceable to evidence and clearly identified as provisional.

Best Practices

1. Define effort, duration, cost, and units before estimating.
2. Estimate from a visible scope or work breakdown.
3. Use historical data when it is comparable and trustworthy.
4. Combine methods where appropriate rather than relying on one number.
5. Separate assumptions, risks, exclusions, and reserves.
6. Use ranges when uncertainty is material.
7. Avoid converting story points into universal hours.
8. Account for availability, dependencies, coordination, and non-development work.
9. Record actuals and refine future estimates using evidence.
10. Communicate estimates as forecasts with confidence, not guarantees.

Chapter Summary

Effort measures labor, duration measures elapsed time, and cost measures monetary expenditure. They are related but cannot be substituted for one another. Expert judgment is valuable for novel work but must be structured to reduce bias. Analogous estimation relies on genuinely comparable historical projects. Parametric estimation uses calibrated relationships between size and effort. Bottom-up estimation builds from work packages and is especially useful when scope is understood. Three-point estimation represents uncertainty through optimistic, most-likely, and pessimistic values.

Software sizing may use SLOC, function points, use-case points, feature measures, or agile story points. Each measure has assumptions and limitations. Story points are relative team measures, while function points and SLOC can support calibrated organizational analysis. Converting effort to duration requires attention to capacity, availability, dependencies, and coordination. Cost estimation must include relevant labor, non-labor, indirect costs, and governed reserves. Transparent assumptions, ranges, historical validation, ethical communication, and iterative refinement are central to professional estimation.

Key Terms

Effort: Quantity of labor required to perform work.

Duration: Elapsed calendar time between start and finish.

Cost: Monetary value of resources consumed.

Productivity: Output produced per unit of effort.

Expert judgment: Estimation based on informed professional experience.

Analogous estimation: Estimation using adjusted results from comparable completed work.

Parametric estimation: Estimation using a calibrated mathematical relationship between size and effort or cost.

Bottom-up estimation: Estimation by aggregating detailed work-package estimates.

Three-point estimation: Estimation using optimistic, most-likely, and pessimistic values.

PERT-style estimate: Weighted estimate calculated as (O + 4M + P) ÷ 6.

Work breakdown structure: Hierarchical decomposition of project scope into manageable components.

SLOC: Source lines of code counted under defined rules.

Function point: A measure of user-visible software functionality.

Story point: A team-specific relative measure of size, complexity, effort, and uncertainty.

Velocity: Story points completed by a team in an iteration.

Assumption: A condition treated as true for estimation purposes.

Contingency reserve: Provision for identified uncertainty or risk responses.

Confidence range: An interval expressing the uncertainty surrounding an estimate.

Progressive elaboration: Refinement of plans and estimates as information improves.

Reference-class forecasting: Forecasting based on outcomes from a relevant class of past projects.

Review Questions

Short Answer Questions

1. Define effort, duration, and cost, and explain why they should not be confused.
2. What is the purpose of documenting estimation assumptions?
3. State one strength and one limitation of analogous estimation.
4. What do optimistic, most-likely, and pessimistic estimates represent?
5. Why should story points not be treated as universal units of time?

Long Answer Questions

1. Explain how a bottom-up estimate can be developed from a work breakdown structure.
2. Compare expert judgment, parametric estimation, and analogous estimation.
3. Explain the factors that prevent effort from being converted directly into schedule duration.
4. Discuss the benefits and limitations of SLOC, function points, and story points.
5. Describe the ethical and governance responsibilities associated with project estimates.

Analytical / Application Questions

1. A project has O = 10 days, M = 18 days, and P = 32 days. Calculate the PERT-style estimate and explain the assumptions behind it.
2. A team estimates 240 person-days of effort. Four contributors are assigned, but each is available 75% of the time. Estimate the theoretical working duration and identify at least three reasons the actual duration may differ.
3. A sponsor demands a fixed 10-week delivery date although the forecast is 14 weeks. Propose a structured analysis of scope, resources, dependencies, cost, and risk before accepting or rejecting the demand.

Multiple Choice Questions with Answers

Question 1

Which quantity measures the amount of labor required to complete project work?

A. Duration

B. Effort

C. Cost

D. Calendar availability

Correct Answer: B. Effort

Question 2

A task requires 120 person-hours and the labor rate is £40 per person-hour. What is the labor cost?

A. £160

B. £3,000

C. £4,800

D. £6,400

Correct Answer: C. £4,800

Question 3

What is the PERT-style estimate when O = 4 days, M = 7 days, and P = 16 days?

A. 7 days

B. 8 days

C. 9 days

D. 16 days

Correct Answer: B. 8 days

Question 4

Which technique estimates a project by aggregating estimates for detailed work packages?

A. Bottom-up estimation

B. Analogous estimation

C. Expert judgment only

D. Velocity comparison

Correct Answer: A. Bottom-up estimation

Question 5

What is the main characteristic of story points?

A. They are universal measures of hours.

B. They measure calendar duration directly.

C. They are relative measures used by a particular team.

D. They measure lines of source code.

Correct Answer: C. They are relative measures used by a particular team.

Question 6

A project has 40 function points and a historical rate of 0.25 person-months per function point. What is the estimated effort?

A. 10 person-months

B. 16 person-months

C. 40 person-months

D. 160 person-months

Correct Answer: A. 10 person-months

Question 7

Which statement about adding people to a software task is most accurate?

A. It always reduces duration proportionally.

B. It may fail to reduce duration because of dependencies and coordination.

C. It changes effort to zero.

D. It eliminates technical risk.

Correct Answer: B. It may fail to reduce duration because of dependencies and coordination.

Question 8

Which item should normally appear in an estimation record?

A. Only the final number

B. Unstated personal preferences

C. Assumptions, exclusions, data sources, and confidence

D. The sponsor’s preferred date without analysis

Correct Answer: C. Assumptions, exclusions, data sources, and confidence

Question 9

If a team completes 30 story points in a two-week iteration, what is its observed velocity?

A. 15 points per week

B. 30 points per week

C. 60 points per week

D. 2 points per iteration

Correct Answer: B. 30 points per week

Question 10

Which statement best describes a cost estimate?

A. It is always identical to effort.

B. It is the monetary value of labor and other relevant resources.

C. It is elapsed calendar time only.

D. It excludes non-labor costs by definition.

Correct Answer: B. It is the monetary value of labor and other relevant resources.