Project Estimation Accuracy: How to Get Software Estimates You Can Trust

An accurate software estimate is not a single number that the final bill matches to the franc. It is a range, built from clear information and stated assumptions, that you revise as the project teaches you more. Accuracy improves when you fix the inputs (scope, requirements, history) before you polish the arithmetic. This article explains why estimates miss, which techniques are worth using, and what you can do on your next project.

TL;DR

• Most estimation error starts with poor information: unclear, unstable or wrong requirements, not bad math.
• No single technique is best. Combining several independent estimates, tuned to your context and your own historical data, performs more reliably.
• Give ranges, state assumptions, and re-estimate as requirements firm up.
• Record actuals after every project. Your own history is the cheapest accuracy upgrade available.
• A senior person who stays on the project from the first call to handover removes a common source of drift.

What “accurate” actually means for a software estimate

Many founders ask for a fixed number early and treat it as a promise. Steve McConnell, author of a widely read book on software estimation, frames it differently: estimation is primarily a test of whether project targets are realistic and controllable, not a guarantee that the outcome will match an early figure.

He also makes a point that most buyers miss. Precision on paper means little when the assumptions underneath move. In his words, an estimate accurate to ±5% is useless if the underlying assumptions change by 100%. A tidy spreadsheet cannot rescue a vague brief.

So when you judge estimation accuracy, ask three questions:

1. Is the scope written down in a way two people would read the same?
2. Does the estimate show a range and the assumptions behind it?
3. Is there a plan to revise it as you learn?

If the answer to all three is yes, the number is probably more trustworthy than a confident figure with no reasoning behind it.

Why accurate estimates matter

For a startup, the estimate sets the runway, the launch window and the conversation with investors. For an established business, it decides whether a project gets funded at all. Planning literature for agile teams lists what reliable estimates support: reliable delivery, sensible prioritization and trade-offs, trust, a sustainable pace for developers, and fewer quality problems.

The last two are easy to overlook. When estimates are too low, teams cut corners to hit the date, and you pay for it later in bugs and rework. When they are too high, good projects never start. Either way, the cost of a bad estimate is rarely visible on the day it is made.

Why software estimates miss

A 2024 systematic literature review in ACM Computing Surveys groups the reasons behind inaccurate agile effort estimates into five categories: information quality, the team, estimation practice, project management, and business influences. The same review names a common single cause: poor information, meaning unclear, unstable or erroneous inputs.

Here is what each looks like in practice.

Information that is unclear or changing

“A marketplace with payments” can mean three weeks of work or six months, depending on how many seller types, payout rules and currencies exist. If the brief is vague at estimate time, the estimate is a guess dressed as a figure. If requirements shift mid-project, the original number was measuring a different product.

The team and its experience

A 2007 study of 43 internal software projects found that higher project uncertainty went with larger effort-estimation errors. The same study linked stronger estimation and development processes, better estimation management and more experienced estimators to smaller errors in duration. Who estimates matters, and so does how often they have done it.

Estimation practice

Estimating from memory, estimating alone, or estimating once and never looking back all reduce accuracy. Forgotten activities are a classic culprit: testing, deployment, data migration, accessibility, content entry, handover documentation. They are not in anyone’s head when the number is produced.

Project management and business pressure

A target date set by a launch event or an investor meeting can quietly turn an estimate into a negotiation. The number shrinks to fit the date, but the work does not.

Whose explanation do you believe?

A 2004 study in IEEE Transactions on Software Engineering found that the perceived causes of estimation error depend on the respondent’s role, how information is collected, and how it is analyzed. An account from project managers alone is therefore unbalanced. The practical lesson: when you run a post-mortem, hear from developers, product owners and the client side, not just whoever managed the schedule.

Estimation techniques for software projects

Software teams use a handful of families of techniques. A catalog of estimation approaches describes them roughly as follows.

Technique	How it works	Best when
Expert judgment (including Planning Poker)	Experienced people reason about the work and give numbers	Scope is small or familiar, and you have people who have built something similar
Bottom-up (work breakdown)	Split the project into tasks, estimate each, add up	Requirements are detailed enough to list tasks
Top-down	Start from a total budget or size and divide it	Very early, when you only need an order of magnitude
Analogy	Compare with completed projects	You have comparable past projects with recorded actuals
Weighted functional counting	Count features or functions and weight them by complexity	You need a repeatable size measure
Parametric models (for example COCOMO)	Fit a cost relationship to historical data	You have a solid dataset and a stable process

Planning Poker and why independence helps

Researcher Magne Jørgensen describes Delphi-style processes such as Planning Poker as useful because people reveal independently formed estimates at the same moment, so nobody anchors on the loudest voice. The discussion that follows can then expose activities that individuals left out. If two developers say three days and a third says ten, the third has probably seen something the others missed. That disagreement is the most valuable output of the session.

Bottom-up versus top-down

Bottom-up gives more detail but needs a stable scope. Top-down is fast but coarse. A sensible sequence is top-down at the very first conversation (“this is a CHF-six-figure project, not a CHF-five-figure one”), then bottom-up once discovery has produced a real backlog.

Analogy and parametric models

Both depend on history. If your last four web applications took between 11 and 16 weeks, that is a better anchor for the fifth than any generic formula. Parametric models formalize the same idea but need data you may not have yet.

Which technique is the most reliable?

None, on its own. Jørgensen states that there is no universally best effort-estimation method, because the relationships between size, effort and cost drivers vary by context and methods should be tailored to the organization and project. Reliability tends to improve when you use relevant historical data, company-specific checklists and several independent estimates combined.

The same guidance on estimation approaches advises using several methods together where possible, reporting the spread instead of hiding it in an average, giving a range, re-estimating as requirements become clearer, and recording actuals.

A practical recipe for a small team:

1. Have two or three people estimate independently.
2. Compare the numbers and discuss the largest gaps.
3. Cross-check with one past project of similar shape.
4. Report a low, likely and high figure, not a single value.
5. Write down the assumptions that would move the range.

The low, likely and high figures also work as a simple form of three-point estimation, a common technique that weights optimistic, pessimistic and most likely outcomes.

How to improve estimation accuracy, step by step

1. Improve the information before you estimate

The ACM review recommends raising the quality of available information, using the INVEST criteria for user stories, writing stories from the developer’s perspective, using checklists, analyzing the impact of changes, and identifying uncertainty explicitly. INVEST stands for stories that are independent, negotiable, valuable, estimable, small and testable. If a story fails “estimable”, the honest estimate is “we need a short spike to find out”. The review is open on the ACM site for anyone who wants the detail.

It also notes an imbalance in the research: of 75 proposed approaches, 66 aim at estimating effort, and only nine tackle information-quality problems. Most of the tooling attacks the symptom. Your best leverage is on the cause.

2. Baseline the scope and control change

The international standard on software project planning, ISO/IEC/IEEE 16326:2019, treats planning as continuous: plans set out scope, activities, schedules, resources, responsibilities and criteria, and are regularly revised. Its guidance also calls for stakeholder involvement in defining requirements, a requirements baseline, a work sequence that covers the full scope, and documented evaluation of changes to scope and requirements.

In plain terms: agree what is in, write it down, and when something changes, say what it does to cost and time before anyone starts on it. That one habit prevents most arguments about “scope creep”.

3. Use a checklist built from your own projects

Jørgensen reports that relevant historical data and company-specific checklists improve accuracy by reducing forgotten activities, reusing experience, and supporting realistic contingency allowances. A starter checklist for a web project might include:

• Authentication, roles and permissions
• Email and notification flows
• Payment and invoicing edge cases
• Integrations with CRM, ERP or shop systems
• Data import from the old system
• Hosting, monitoring and backups
• Accessibility and browser testing
• Content entry and translation (relevant in Switzerland, where German, French, Italian and English versions are common)
• Documentation and handover

Every time a task surprises you, add it to the list.

4. Record actuals and run honest retrospectives

Estimation skill grows only with feedback. After each project, compare estimate with actual by task type, not only in total. A project that came in on budget can hide a 60% overrun on integrations offset by a surplus on design. For the post-mortem, follow the 2004 study’s advice: combine interviews with stakeholders in all relevant roles, experience reports from completed projects and statistical analysis of project characteristics.

5. Pick estimators by experience

The 2007 study suggests selecting estimators according to how many projects they have managed, investing in detailed planning, and accounting for uncertainty when managing expectations. When you hire a studio, this translates into a simple question: who will produce the estimate, and will that same person be there when the work is done?

A worked example: estimating a customer portal

Imagine a Swiss SME wants a customer portal connected to its ERP. Here is how the approach above plays out.

Week 0, rough range. By analogy with similar portals, the team says the work lies between a small and a mid-sized build. This is a top-down order of magnitude, labeled as such.

Discovery. Over a short, paid discovery phase, the team lists user roles, the data in the ERP, the approval flows and the reports. Each item becomes a story, and any story that is not estimable gets a time-boxed spike.

Independent estimates. Three engineers estimate separately. Login and roles: 4, 5 and 5 days, so they agree. ERP synchronization: 6, 12 and 20 days. The gap is the finding. After discussion, it turns out the ERP has no stable API for invoices, and one engineer had priced a workaround. The range for that item is kept wide, and the assumption is written down: “ERP vendor provides a documented endpoint for invoices by a stated date.”

Range and assumptions. The proposal states low, likely and high totals, the five assumptions most likely to move them, and the date at which the estimate will be revisited.

Re-estimate and record. After the first release, the team updates the range, records actual days per item and adds “vendor API risk” to the checklist.

Nothing here is exotic. It is a discipline of making uncertainty visible early, when it is cheap to resolve.

What to ask a development partner about their estimates

If you buy software from an outside team, estimation accuracy is partly about how they work. Questions worth asking:

• Who builds the estimate, and who will build the product?
• Is the estimate a range, and what assumptions does it rest on?
• What happens to price and timeline when requirements change?
• How do you handle things nobody can estimate yet, such as an undocumented third-party system?
• Can I see how past estimates compared with actuals?
• What do I own at handover, and could another team take over?

Vague answers to these are a better warning than a high price.

How we approach it at Ampersand

Ampersand is a small Zurich studio, and every project is led from the first consultation to handover by senior engineers. That continuity is what keeps an estimate honest: the person who scoped the work is the person who answers for it, so requirements are not rewritten halfway and the team does not change under you. We work with clients across sectors, including UBS and the City of Lugano, and we favor transparency and client independence over lock-in.

If you have a project and want a realistic range before committing, see how our engagements are structured on the pricing page, which covers websites, apps, platforms, integrations, AI automation, migrations and advisory plans. Two published monthly prices give a sense of scale for ongoing work: the Guidance advisory plan is CHF 799 per month, and the Run & monitor support plan is CHF 750 per month. Project builds are scoped individually, which is exactly why we start with the questions above. You can also look at our past work to judge the kind of projects we take on.

Common mistakes to avoid

• Treating a range as weakness. A single number looks confident but hides the spread. Reporting the spread is more honest and more useful.
• Averaging away disagreement. When estimators differ widely, the gap points to missing information. Resolve it instead of splitting the difference.
• Estimating once. Planning is continuous, so re-estimate when requirements become clearer.
• Skipping the unglamorous work. Deployment, migration, testing and handover are usually where forgotten hours live.
• Letting the date set the number. If the launch date is fixed, adjust scope, not the estimate.
• Never closing the loop. Without recorded actuals, every project starts from zero.

FAQ

What is one common reason software project estimates are inaccurate?

Poor information is a leading one: requirements that are unclear, unstable or simply wrong at the time of estimating. A 2024 systematic review of agile effort estimation places information quality among five recurring categories of cause. Improving the brief usually does more than improving the formula.

Which estimation technique is the most reliable?

No single technique wins everywhere. Research from Simula points to tailoring methods to your context and combining independent estimates with historical data and checklists. In practice, that means two or three people estimating separately, a cross-check against a similar past project, and a reported range.

How accurate should an early estimate be?

Early estimates should be wide, because little is known. As requirements firm up, the range should narrow, and you should re-estimate at each stage. An estimate that stays narrow while assumptions change is a warning sign, not a comfort.

How can a small team get better at estimating?

Record actual effort for every project, by task type, and build a checklist from what surprised you. Hold short retrospectives with developers, product owners and the client side. After a handful of projects, your own history will beat generic rules of thumb.

Sources

• Demystifying the Black Art of Software Estimation (Steve McConnell, Microsoft Press Store)
• The Purpose of Agile Planning (InformIT)
• A Systematic Literature Review on Reasons and Approaches to Inaccurate Agile Estimation (ACM Computing Surveys, 2024)
• Factors affecting duration and effort estimation errors in software development projects (Information and Software Technology, 2007)
• Reasons for Software Effort Estimation Error: Impact of Respondent Role, Information Collection Approach, and Data Analysis Method (IEEE TSE, 2004)
• What We Do and Don’t Know about Software Development Effort Estimation (Magne Jørgensen, Simula, 2014)
• Estimation approaches (MSDBOK)
• ISO/IEC/IEEE 16326:2019 sample