I knew the look on my boss’s face when he came to me with a new project idea. It was clear: he didn’t know exactly what he wanted. But the effort involved — that I was supposed to tell him right away.
Effort estimates in project management are predictions. Those are always difficult. Especially when they concern the future, as Mark Twain once remarked. Experience shows they tend to be more accurate when there is already experience with similar, comparable ventures. Many projects are one-of-a-kind, however, and that leads to a long list of failed estimates.
Here are a few examples:
| Project | Planned Cost | Actual Cost | Completion | Cost Factor |
|---|---|---|---|---|
| BER – Berlin Brandenburg Airport | approx. €2 bn | over €7 bn | 2020 | 3.5 |
| Elbphilharmonie Hamburg | approx. €77 m | approx. €866 m | 2016 | 11.2 |
| Sydney Opera House | approx. AUD 7 m | approx. AUD 102 m | 1973 | 14.6 |
| Big Dig Tunnel Boston | approx. USD 2.8 bn | approx. USD 14.6 bn | 2007 | 5.2 |
| Aircraft Carrier USS Gerald R. Ford | approx. USD 10.5 bn | over USD 13 bn | 2017 | 1.24 |
| Passenger Ship Queen Elizabeth | approx. £3.9 bn | approx. £6.2 bn | 2020 | 1.59 |
| FBI Virtual Case File | approx. USD 170 m | over USD 600 m | Cancelled (2005) | 3.5 |
| Boeing 787 Dreamliner | approx. USD 6 bn | approx. USD 32 bn | 2011 | 5.3 |
| Airbus A400M | approx. €20 bn | over €30 bn | 2013 | 1.5 |
The risk of a faulty effort estimate increases with the degree of innovation in a project. And the less precisely project planning is carried out, the more often you can expect actual costs to deviate from planned ones. Effort estimation almost always operates within the tension defined by the project management triangle.
What is effort estimation and what are efforts?
One of the most common questions a project manager asks is: “How long will this take us?” Behind this question lies effort estimation — a central element of every project planning process.
Effort estimation is the forecasting of the resources needed to fulfill a defined project task across the various project phases. It encompasses primarily:
- Working time of people
- Materials
- Infrastructure
- Travel costs
- Services
Some systems distinguish only between two classes: Time and Material. Here:
- Time is the work performed, measured in hours or working days
- Material is everything else
Distinguishing it from related terms is important. Time estimation refers to the duration until completion and also includes non-productive periods. Cost estimation converts effort into financial figures and forms the basis for calculating project costs. Effort estimation is the foundation for both. It is a prerequisite for capacity planning and realistic workload management.
Effort estimation plays a critical role in the project management cycle. It influences:
- Initial project approval
- Resource allocation
- Scheduling and milestones
- Risk management
- Ongoing project controlling
In practice it is an essential part of project planning and project controlling. To support a continuous improvement process, it is important that the development of estimates is recorded in the project documentation.
What types of effort estimation methods are there?
The most important methods for effort estimation include:
- Top-Down and Bottom-Up
- Delphi method
- Analogy-based estimation
- Planning Poker
- COCOMO model
- Function Points
Some of these methods are already more than 50 years old; others became popular with agile project management.
Top-Down vs. Bottom-Up approaches
The two fundamental directions are Top-Down and Bottom-Up. In both cases, a scope description must be available — for example, in the form of a requirements specification, a functional specification, or a work breakdown structure (WBS).
With the Top-Down approach, you look at the overall project and derive the effort for sub-areas from it. This method is suited to early project phases when details are still unclear. A construction company might, for example, estimate the total effort for a residential building based on the enclosed volume, then break it down by individual trade.
The Bottom-Up approach starts with individual work packages. You estimate each task separately and sum these to arrive at the total effort. When developing a new smartphone app, for example, you would determine the effort for UI design, back-end development, testing phase, and further modules individually and then add them together.
A good project management tool supports both approaches and can be very helpful in keeping track of everything. In a Gantt chart, deviations between Bottom-Up and Top-Down can be visualized clearly.
Expert estimation: Delphi method and other techniques
Expert estimation leverages the knowledge and experience of specialists who have worked on similar projects or tasks. The best-known variant is the Delphi method:
- Experts independently submit anonymous estimates
- The results are aggregated and fed back to the group
- Experts reconsider their estimates and submit new ones
- The process is repeated several times until a consensus is reached
Further techniques of expert estimation include:
- Wideband Delphi: An extension with group discussions between estimation rounds
- Planning Poker: An interactive variant from agile software development
- Three-Point Estimation: The combination of optimistic, realistic, and pessimistic estimates
Analogy-based estimation: comparisons with similar projects
In analogy estimation, you use experience values from similar, completed projects. The underlying idea: what held true in the past applies — with adjustments — to current ventures as well.
One of my customers uses this method for all new projects. To do so, he has built up a large database of typical work packages with associated effort figures over the years using the project management tool Allegra. He has also categorized the tasks. When a new project comes along, the relevant category is determined for each work package and the effort for that category is automatically adopted as the estimate. The actual effort required is fed back into the database at the end of the project. With this approach, the customer was able to massively improve his estimation accuracy.
For effective analogy estimation you need:
- Solid documentation of past projects
- Clear similarity criteria
- Adjustment factors for differences
- A critical assessment of comparability
Parametric models: COCOMO, Function Point Analysis
Parametric models use mathematical formulas to calculate effort. They are based on empirical data and statistical relationships. I’ll say it upfront: I’m not a fan of these methods. The formulas suggest a precision that doesn’t actually exist. The problem is the parameters: their accuracy largely determines the quality of the estimate, and accurate parameters require a large number of similar ventures to have been carried out under similar circumstances in the past.
I had a colleague who was responsible for project costing at our company. I still remember two of his sayings. The first was connected to his cigarette consumption. For that, he occasionally needed small change, which he would try to get from the department secretary with the line: “Can you give me change for five marks without insulting me?” The second saying was: “Tell me what the assembly weighs and I’ll tell you what its development costs.”
That said, I would still like to briefly introduce the most important parametric methods.
The COCOMO model (Constructive Cost Model) is a classic in software development. It calculates effort based on the estimated code volume and other influencing factors. The basic formula is:
Effort = a × (Size)^b × EAF
Where EAF (Effort Adjustment Factor) is a magic number that accounts for various project characteristics.
Function Point Analysis takes a different approach. It measures the functional scope from the user’s perspective rather than a technical one. The method captures:
- Inputs
- Outputs
- Queries
- Data stores
- Interfaces
These are weighted and combined into function points. Effort can then be derived from empirical values.
Agile estimation techniques: Planning Poker, T-shirt sizes, Story Points
With the spread of agile methods, specific estimation techniques have become established that emphasize speed, team consensus, and relative magnitudes.
Planning Poker combines expert opinion with group dynamics. The team estimates requirements (user stories) by having each member simultaneously reveal a card with an estimate. When values differ, team members discuss their reasoning and estimate again. The process encourages exchange and leads to more realistic results.
The T-shirt sizes method dispenses with precise numbers and uses order-of-magnitude categories such as XS, S, M, L, and XL instead. This simplification works surprisingly well for rough assessments and prevents false precision.
Story Points are a relative unit of measure for effort. The team selects a reference task and evaluates all others in relation to it.
What are the prerequisites for a reliable effort estimate?
The quality of an effort estimate depends strongly on certain prerequisites, which we will identify below.
1st prerequisite: Know the solution concept
Imprecise requirements and vague ideas about the solution lead to imprecise estimates. The most important prerequisite for a reliable effort estimate is therefore — alternatively — a solution concept that is as detailed as possible (functional specification), a product breakdown structure, a prototype, or a list of stories.

2nd prerequisite: Know the resources and dependencies
The available resources significantly influence the effort. Assess:
- Qualification and experience of the team
- Availability (part-time, other projects)
- Learning curves with new technologies
- External dependencies on other teams or suppliers
3rd prerequisite: Know the risk factors
Every project carries uncertainties. Identify these and assess their impact on effort. Typical risk factors include:
- Technological uncertainties
- Changes in requirements
- Dependencies on third parties
- Resource bottlenecks
Instead of a single value, create three estimates:
- Optimistic (Best Case)
- Realistic (Most Likely)
- Pessimistic (Worst Case)
From these, a weighted average can be calculated using the PERT formula: (Optimistic + 4×Realistic + Pessimistic) ÷ 6
Why do effort estimates fail and how do you avoid typical pitfalls?
Effort estimates fail with remarkable regularity. A look behind the scenes reveals the reasons and points to ways to improve. The most common causes for the failed estimates of the projects listed above were:
| Category | Description | Occurrences |
|---|---|---|
| New technological developments | Use of new or unproven technologies, e.g. engines, IT systems | 9× |
| Planning errors | Incorrect or incomplete planning, unrealistic time or cost targets | 7× |
| Management failure | Poor project leadership, miscommunication, lack of controlling | 6× |
| Political influence | Political interests, prestige projects, short-term decisions | 4× |
| Design changes | Changes during the construction or development phase | 4× |
| Supply chain problems | Issues with suppliers, coordination of global production | 3× |
| Insufficient testing / quality deficiencies | Inadequate testing phases, errors at commissioning | 3× |
| Corruption / inefficiency | Opaque contracts, inflated prices, nepotism | 2× |
| Approval delays | Problems with regulatory approval or certification | 2× |
| Technical failure / cancellation | Project had to be discontinued or completely redesigned | 1× |
The phenomenon of systematic underestimation (Hofstadter’s Law)
“It always takes longer than you think, even when you take into account Hofstadter’s Law.” This self-referential statement by cognitive scientist Douglas Hofstadter describes a universal phenomenon: people systematically underestimate the time required for complex tasks.

A study by the Standish Group showed that 64% of all IT projects exceed their estimated effort. The average overrun is 68%. These figures have barely improved over the last 30 years.
An international airport operator analyzed 35 completed infrastructure projects. The result: only two projects came in under the estimated effort; 28 exceeded it by more than 25%.
To counteract this phenomenon:
- Add an empirically determined correction factor to your estimates
- Use historical data for comparison
- Rely on Bottom-Up estimates for more detailed results
Psychological factors: Optimism Bias and Planning Fallacy
People tend toward overoptimism regarding their own capabilities. Psychologist Daniel Kahneman coined the term “Planning Fallacy” — the systematic tendency to underestimate one’s own effort.
Even experienced experts fall prey to this bias. In one experiment, software developers were asked to estimate the time required for a clearly defined programming module. The average estimate was 14.4 days. The actual average was 26.7 days.
These psychological distortions occur because we:
- Weight success scenarios more heavily than potential problems
- Overestimate our own abilities
- Unconsciously apply “net values” for small units, without interruptions and side tasks
- Perceive past experiences selectively
A pharmaceutical company addresses this problem with a “pre-mortem” approach: before the final estimate, the team imagines the project has failed and collects possible reasons. This thought exercise helps identify blind spots and create more realistic estimates.
Political and organizational influences
Estimates do not arise in a vacuum. Organizational constraints and political factors often distort results considerably. Effort estimates are frequently the basis for proposals that compete with those of other providers. This creates a conflict that can exert pressure on the assessment. Some projects would never have been started if the real price had been named from the outset.
Further typical scenarios:
- Management sets desired deadlines (“We need this feature by the trade fair in June”)
- Estimates are treated as a bargaining chip and deliberately set low
- Competitive pressure leads to unrealistic promises
- Internal budgeting processes distort estimates (“What we don’t request now, we won’t get next year”)
- Project teams fear negative reactions to “too high” estimates
- Political or legal requirements force providers into unrealistic bids
I know a construction company that introduced a two-stage estimation process: first a purely technical estimate with no knowledge of external deadlines or budget specifications. Only in a second step are these factors taken into account — with transparent documentation of the adjustments.
Missing historical data and experience values
Precise estimates require a solid data foundation. Without reliable reference values, there is no anchor for realistic forecasts.
Many organizations suffer from:
- Lack of documentation of completed projects
- Absence of post-calculation (“post-mortem”)
- Insufficient metrics and key figures
- High staff turnover and loss of knowledge
I recommend a simple measure with a major impact: after every project, the original estimates are compared with the actual effort and the deviations are systematically analyzed. The insights flow into a central database. The improvement in estimation accuracy is already impressive after just a few projects.
Strategies for avoiding estimation errors
With these strategies you can reduce systematic estimation errors:
-
Deliberate overcompensation: Increase your estimates by an empirically determined factor. For new technologies, this can be 50–100%.
-
Independent estimates: Have several experts estimate independently before comparing results.
-
Reference Class Forecasting: Base your estimates on statistical data from similar, completed projects rather than on project-specific details.
-
Transparent risk allowances: Separate the base estimate from explicit buffers for identified risks.
-
Iterative refinement: Start with rough estimates and refine them as knowledge grows.
Use the “outside view” whenever possible: for every new project, identify at least five comparable, completed projects. The average deviation between estimate and reality for this reference class forms the basis for a project-specific correction factor.
How does effort estimation differ in agile and classic projects?
The approach to effort estimation varies fundamentally between classic and agile projects. Understanding these differences helps you choose the appropriate methodology for your context.
Fundamental differences in approach
Classic projects follow a plan-driven approach. Effort estimation is carried out at the beginning for the entire project scope. It forms the basis for budget, resource planning, and scheduling. The plan is at the center.
Agile projects, by contrast, embrace change. Effort estimation focuses primarily on the immediately upcoming work segment (Sprint). Value is at the center, not the plan.
An automotive supplier experienced this difference with two parallel development projects. The classically managed team created a detailed effort estimate for the overall project with more than 2,000 work packages. The agile team estimated only the most important epics roughly and focused on precise estimates for the next Sprint only. A subsequent analysis showed: the total deviation was similar for both approaches (approx. 25%), but the agile team delivered valuable results earlier and was able to integrate customer feedback more effectively.
Continuous vs. one-time estimation
In classic projects, the one-time, comprehensive estimate dominates. It is carried out at the start of the project and often remains the reference point — even when conditions change. Updates occur mostly only through formal change requests.
Agile projects rely on continuous estimation. New estimates are made before every Sprint. The team learns from past Sprints and steadily improves its estimation ability. Planning certainty grows as the project progresses.
Velocity tracking and burn-down charts
Agile teams use empirical data for estimation. Velocity — the number of story points a team can complete per Sprint — is the most important reference value. It is measured continuously and used to forecast future performance.
The process:
- Estimate all backlog items in story points
- Measure actual velocity over several Sprints
- Calculate the average as the basis for future forecasts
- Update the forecast after every Sprint
Burn-down charts visualize progress and enable early course corrections. Remaining work is plotted against time. Deviations from the ideal line signal problems.
Hybrid approaches for different project environments
The choice between agile and classic approaches is not an either-or decision. Many organizations develop hybrid approaches that combine the best of both worlds.
A global telecommunications company uses a three-tier model:
- Rough effort estimate for the overall project using Feature Points (similar to Function Points, but coarser)
- More detailed estimate for the next release (3 months) by experts
- Precise story-point estimate for the current Sprint by the team
This approach provides long-term planning certainty for senior management while preserving flexibility in the day-to-day development process.
Other hybrid models include:
- Agile implementation within a classic project framework
- Classic estimation for hardware/infrastructure components, agile estimation for software
- Relative estimation (story points) combined with absolute estimation (person-days)
Advantages and disadvantages of both worlds in practice
The strengths and weaknesses of the various approaches become apparent in practical application.
Advantages of classic effort estimation:
- Delivers an early overall forecast for budget and scheduling
- Provides detailed documentation for contract negotiations
- Enables precise resource planning
- Suits the regulatory requirements of many industries
Disadvantages of classic effort estimation:
- High initial effort required for detailed estimates
- Often creates false security through apparent precision
- Tempts teams to rigidly adhere to the plan despite changed circumstances
- Delays the recognition of misjudgments
Advantages of agile effort estimation:
- Faster to create with lower initial effort
- Continuous improvement through regular feedback
- Better adaptability when requirements change
- Early detection of deviations through empirical measurement
Disadvantages of agile effort estimation:
- Limited long-term planning certainty
- More difficult for fixed-price contracts and traditional procurement processes
- Requires disciplined teams with estimation experience
- Can lead to “commitments” rather than estimates with inexperienced teams
What tools and software can support effort estimation?
The right software can significantly simplify the effort estimation process and improve the quality of results. From simple spreadsheet programs to specialized AI-assisted solutions — the choice is wide.
Overview of relevant project management software
Many common project management tools offer integrated functions for effort estimation:
Microsoft Project remains a standard in classic project management. The software enables detailed effort estimates at the work package level, supports various resource types, and offers extensive analysis functions. Integration with other Microsoft products facilitates data exchange.
Jira dominates in the agile environment. The platform supports story-point estimation, velocity tracking, and automated burn-down charts. Numerous extensions offer specialized functions, for example for Planning Poker or release forecasting.
Smartsheet combines the familiarity of a spreadsheet with powerful project management functions. The intuitive interface lowers the barrier to entry. Several insurance companies use Smartsheet successfully for hybrid projects.
Further relevant tools include:
- Allegra: Strong in agile, classic, and hybrid project management, top-down and bottom-up
- Asana: User-friendly with simple estimation functions
- Monday.com: Flexibly configurable with visually appealing dashboards
- Wrike: Strong in integrating different working models
Specialized estimation tools and their areas of application
Beyond general project management solutions, there are tools designed specifically for effort estimation:
SLIM-Estimate is based on the Putnam model and is particularly suited to software development projects. It uses extensive historical data to calibrate estimates and takes into account factors such as team size, experience level, and complexity.
CostXpert targets precise budget and effort estimates for IT infrastructure projects. The tool includes databases with benchmarks for various hardware components, software licenses, and personnel costs.
QSM SLIM-Collaborate supports collaborative estimation processes. The tool makes it possible to gather, aggregate, and statistically analyze various expert opinions. A large telecommunications provider uses it for international projects with distributed teams.
For agile teams, specifically focused tools are available:
- Planning Poker Online: Simplifies the conducting of virtual Planning Poker sessions
- ScrumDo: Focused on story-point estimation and velocity analysis
- Estimator: Supports team-consensus estimation with real-time feedback
Advantages and limits of automated estimation
The automation of estimates through AI and machine learning is growing in importance. These technologies promise more objective and consistent results.
Advantages of automated estimation:
- Avoidance of human bias
- Greater consistency across different projects
- Faster creation and easier adjustment
- Ability to process large volumes of historical data
Limits and challenges:
- Dependency on the quality of historical data
- Difficulty accounting for unique project characteristics
- Lack of transparency with complex algorithms
- Resistance from subject matter experts toward “black-box” estimates
How do you improve effort estimates by learning from past projects?
Continuously improving effort estimates is not a luxury — it is a necessity. Organizations that systematically learn from experience achieve ever-greater precision.
Building a project database and metrics
The foundation is a structured collection of historical project data. An effective project database contains:
- Original estimates and actual effort figures
- Project characteristics and classifications
- Technologies and methods used
- Team size and composition
- External factors and framework conditions
Consistent metrics are crucial. Define clear key figures such as:
- Absolute deviation in person-days
- Relative deviation as a percentage
- Estimation Error Factor (actual effort / estimated effort)
- Velocity stability for agile teams
An engineering services provider introduced a central project database that now covers more than 200 completed projects. Every new project is classified using 15 criteria. When making effort estimates, an algorithm identifies similar reference projects and delivers statistical comparison values. The accuracy of estimates improved by 40% within two years.
Post-mortem analyses and retrospectives
After a project closes, a wealth of insights is ready to be tapped. Use them through systematic post-project reviews.
Effective post-mortem analyses for effort estimation include:
- Comparison of planned and actual effort at a detailed level
- Identification of the largest deviations
- Root-cause analysis without blame
- Derivation of concrete improvement measures
Agile teams use regular Sprint retrospectives to continuously improve their estimation ability. The question “Why did we accomplish more or less than we estimated?” becomes firmly established.
A software house in Scandinavia holds quarterly “Estimation Clinics.” Teams present their most precise and least precise estimates and discuss the differences. Insights are documented in a wiki and actively consulted for future estimates. Average estimation accuracy rose from 67% to 84% within a year.
Measuring and improving estimation accuracy
Measuring estimation accuracy forms the basis for targeted improvements. Instead of sweeping statements like “We’re usually off,” objective measures create clarity.
Proven approaches:
- Tracking estimation deviations by team, project type, and technology
- Analysis of typical over- and underestimation patterns
- Identification of particularly hard-to-estimate task types
- Evaluation of the accuracy of different estimation methods
A global consulting firm runs an internal estimation competition. Teams with the highest accuracy receive recognition and share their methods. This playful approach led to healthy competition and significantly improved estimation quality.
A specialized software agency for banks identified through systematic analysis that integration tasks with legacy systems were particularly frequently underestimated. As a consequence, they introduced a blanket correction factor of 1.7 for this task class. Estimation accuracy for integration projects rose from 55% to 82% within one quarter.
Continuous improvement process
Individual measures rarely have a lasting effect. Successful organizations have a continuous improvement process for effort estimation.
Elements of such a process:
- Regular review of estimation accuracy
- Systematic collection and analysis of deviations
- Active involvement of teams in the improvement
- Adjustment of methods based on insights
- Training and coaching to strengthen estimation competence
A mid-sized IT service provider integrated estimation improvement into its ISO-9001-certified quality management process. Quarterly evaluations and annual targets for estimation accuracy were established. After three years, the average deviation fell from 42% to 16%.
Organizational learning and knowledge transfer
Individual experience must be converted into organizational knowledge. Only then does the entire company benefit sustainably.
Successful approaches for effective knowledge transfer:
- Estimation workshops with mixed teams of experienced and new employees
- Documentation of estimation errors and lessons learned in accessible knowledge bases
- Creation of estimation checklists based on past experience
- Mentoring programs for inexperienced estimators
A leading automotive supplier uses an “Estimation Knowledge Board” — a visualized collection of the most important insights on effort estimation. Every completed project contributes at least one new insight. The board is placed centrally and actively consulted during estimation meetings.
Frequently asked questions
What is effort estimation?
Effort estimation is the systematic forecasting of the work effort required to achieve a project goal. It encompasses the calculation of time, costs, and resources and forms the basis for realistic project planning.
Why is a precise effort estimate crucial for project success?
A precise effort estimate secures project success by enabling efficient resource planning, cost certainty, and effective risk management. It helps avoid unforeseen delays and budget overruns, which is particularly important in global projects.
What methods of effort estimation are there?
Common methods include the Bottom-Up method, in which individual tasks are estimated in detail; the Top-Down method, which begins with a rough overall estimate; the analogy method, which draws on experience values from similar projects; and parametric estimation, which incorporates statistical models and historical data.
Who is involved in the effort estimation process?
The effort estimation process typically involves the project manager, subject matter specialists such as engineers, software developers, or construction managers, as well as experts from controlling and finance. In international projects, external consultants are often brought in to account for cultural and regional particularities.
How can you measure and optimize the success of your effort estimation?
You measure success through key figures such as the accuracy rate, deviation analyses, budget adherence, and resource efficiency. Through continuous feedback loops, retrospectives, and the use of advanced analysis methods such as AI, you can regularly review and optimize your estimates.
CEO Alltena GmbH
Christoph Friedrich is a computer scientist and certified Project Management Professional. He has extensive experience in the introduction and integration of project management tools as well as the analysis and definition of processes in project and service management.