Software Project Estimation: A 2026 CTO's Playbook

What software project estimation actually is

Software project estimation is the disciplined practice of forecasting the effort, time and money a software build will take — and, just as important, the confidence range around that forecast. It is not a single date or a single dollar figure. Done well, it hands a CTO three things: a most-likely number, an honest band around it, and a written list of the assumptions that would move it.

That last part is where most quotes fall apart. A number without its assumptions is a guess wearing a suit. This playbook is written for the person on the buying side — the CTO, founder or product lead comparing vendor proposals — and it covers which estimation method to demand for your situation, how to read a quote for the tells that it’s wrong, what costs hide below the headline, and how to write a brief that pulls every vendor’s number toward reality.

Why Fora Soft wrote this playbook

Fora Soft has shipped 250+ projects since 2005, and our 50 in-house engineers run custom software development end to end: they scope, estimate and build every project. We write fixed-bid and time-and-materials proposals most weeks of the year, and every delivered project feeds a post-mortem that calibrates the next estimate. When our numbers miss, they almost always miss for one of the five reasons in the next section. None of them is “the engineers were slow.”

The reference points behind this guide are real builds with post-delivery data: BrainCert (e-learning, $3M ARR in 2024, 100K+ customers, 500M+ classroom minutes), CirrusMED (HIPAA telehealth), VALT (video surveillance, 770+ US organizations, 50,000+ users), and TransLinguist (interpreter video for the UK NHS framework). Each one taught us something about where estimates drift that we couldn’t have learned from a spreadsheet.

If you’re scoping vendor quotes right now, you can also skip straight to a second opinion: we’ll read your brief or early spec and return a structured breakdown, no charge.

What the data says about estimates that miss

Here’s the uncomfortable baseline: most large software projects miss their estimate, and the misses are big. McKinsey and the University of Oxford studied 5,400+ large IT projects (2012) and found they ran, on average, 45 % over budget and 7 % over schedule while delivering 56 % less value than predicted. Worse, 17 % went so far over, at 200 % to 400 % on cost, that they threatened the company’s existence.

The overruns aren’t evenly spread; they’re fat-tailed. Flyvbjerg and Budzier (HBR, 2011) looked at 1,471 IT projects: the average cost overrun was 27 %, but one in six turned into a “black swan” with a 200 % cost overrun and nearly 70 % schedule overrun. Their later 2022 analysis of 5,392 projects put roughly 18 % of IT projects more than 50 % over budget, with a tail that averages far worse. The lesson for a buyer isn’t “projects are doomed.” It’s “plan for the tail, because a point estimate hides it.”

Where does the money leak? PMI’s Pulse of the Profession reports that 28 % of organizations with a failed project named inaccurate cost estimates as a primary cause (2017), and 52 % of projects hit scope creep (2018). Standish’s CHAOS data has long put only about a third of software projects in the “successful” bucket (roughly 29 % successful, 52 % challenged, 19 % failed in 2015), though that figure is contested by researchers, so treat it as directional, not gospel. Read together, the sources agree on one thing: estimation discipline, not raw coding speed, is what separates the projects that land from the ones that need a board conversation at month six.

Why an early single number is a guess: the cone of uncertainty

Ask for a firm price before anyone has designed the system and you’re asking for fiction. The reason has a name: the cone of uncertainty. Barry Boehm’s data (1981), later popularized as the “cone” by Steve McConnell (2006), shows that at the concept stage a software estimate can honestly land anywhere from 0.25x to 4x of the eventual actual — a 16x span. That range only tightens to roughly ±25 % once requirements and design are done.

Figure 1. The cone of uncertainty. Early estimates carry a 16x span; each phase of learning narrows the band toward the eventual actual.

Two things follow for a buyer. First, an early number should always come with its band and the assumptions that would move it — a vendor quoting a precise figure on day one is either padding heavily or hasn’t done the math. Second, if you need a tighter number, buy the learning that narrows the cone: fund a short discovery or design phase, then re-estimate. Paying for a two-week discovery to turn a 4x range into a 1.5x range is the cheapest risk reduction on the whole project.

Five reasons software project estimates fail

1. Vague scope (the number-one killer). “Build us an Uber for X” is not a scope; it’s a mood. It hides 50 decisions (payments, identity, disputes, dispatch, surge pricing), and each one carries a 10x cost swing depending on the answer. Ambiguous scope is why two competent vendors can quote $80k and $300k for the “same” project.

2. Anchoring on the first optimistic number. Someone says “three months” in a hallway, the CFO hears it, and every later estimate gets measured against that throwaway figure and rejected if it’s bigger. Real estimates carry a range from the start so there’s nothing false to anchor on.

3. Ignoring non-functional requirements. “Build the feature” is the easy half. “Make it 99.95 % available, GDPR-compliant, scalable to 100k daily users, and accessible” is the half that gets skipped, and it can be 30–60 % of the work. An estimate with no NFR line is an estimate for a prototype, not a product.

4. Missing third-party dependency risk. “We’ll just integrate their API” assumes the API is documented, stable, rate-friendly and compliant. It often isn’t. We once lost two weeks to a payment API that rate-limited at a threshold no doc mentioned; the fix was ours to build, not theirs.

5. Founder-mode discounts. When the person who wants the project to happen is also the person estimating it, optimism wins every time. That’s not a character flaw, it’s a known bias — and the fix is structural: we send every internal estimate over $100k to a senior engineer who wasn’t in the room to argue it down.

The five estimation methods, and when each wins

There is no single right method — there’s a right method for your level of uncertainty and your contract type. If you want the full mechanics with a worked spreadsheet for each, our companion piece breaks down the five software development cost estimation methods end to end. Here’s the buyer’s-eye summary.

Bottom-up. Break the work down to user stories or function points, estimate each, sum them, then add QA, management and risk reserves. It’s the default for a fixed bid because it’s the only method precise enough to sign your name to. Budget one to three days of a senior engineer’s time for a $200k project.

Top-down analogous. “Project Y took six months and $250k; this looks similar.” Fast and fine for a first conversation, dangerous for a contract. Say the ±30 % out loud so nobody treats the midpoint as a promise.

Parametric. Drive the estimate from a calibrated model — function points, complexity factors, team productivity. It needs historical data to be worth anything, so we use it as a first-pass sanity check against the bottom-up, not as the headline number.

PERT 3-point. Estimate optimistic, most-likely and pessimistic, then compute a weighted mean and a standard deviation. It converts three guesses into a defensible range. Use it on the one or two modules where the unknowns actually live, and bottom-up the rest.

Monte Carlo. Give every task a probability distribution, simulate the project 10,000 times, read a confidence curve off the output. Reserve it for large, risk-heavy programs with a PMO that will actually use the curve.

Worked example: a 3-point estimate with a confidence band

Say a mid-sized module comes back from three senior engineers as: optimistic $180k if everything lines up, most-likely $260k, pessimistic $420k if the known risks bite. PERT weights the most-likely case four times and averages: mean = (O + 4M + P) / 6 = (180 + 4×260 + 420) / 6 = $273k. The standard deviation is (P − O) / 6 = $40k.

Figure 3. A 3-point estimate turned into an 80 % confidence band. The arithmetic is simple; the honesty is in reporting the band, not the midpoint.

Now you can talk to your board in ranges instead of a single fragile number. An 80 % confidence band is roughly the mean ± 1.28 standard deviations — here, $273k ± $51k, or about $222k to $325k. That sentence — “most-likely $273k, and I’m 80 % confident it lands between $222k and $325k” — is worth more to a board than any precise-looking single figure, because it’s the one that turns out to be true.

Worked example: an OTT platform (bottom-up plus parametric)

Some projects need two methods at once. Take a video-on-demand and live streaming platform with branded apps for web, iOS, Android and connected TV, a 10,000-hour catalogue, live scheduling, and an ad-supported tier alongside subscriptions. The application layer is bottom-up territory; the infrastructure isn’t.

Bottom-up for the apps. Roughly 190 person-weeks of engineering for a v1 across five platforms; with QA, management and risk reserves it lands near 260 person-weeks, or about 10,000 engineering hours. At a specialist blended rate (the boutique tier we quote, not a US mid-market $150–250/hr shop) that maps to a band on the order of $650k to $1.1M, which you communicate as a 70 % confidence range, not a promise.

Parametric for the infrastructure. Streaming cost scales with usage, so you model it per unit: CDN at roughly $0.02–0.03/GB against expected monthly traffic, an encoding tier sized to new content per week, storage per catalogue-hour, plus DRM, analytics and ad-server line items. At a v1 audience that’s on the order of a few thousand dollars a month, and it grows with viewers, which is exactly why it belongs in a separate, usage-driven line rather than buried in the build price.

What stays out of the estimate. Content licensing varies so wildly it doesn’t belong in an engineering quote at all. A vendor who folds rights costs into the build number is either guessing or padding, so assume zero on the engineering side and budget rights separately.

Does AI change the estimation math in 2026?

Yes, but not the way the sales decks claim, and not uniformly. AI-assisted coding compresses some tasks and leaves others untouched, so the honest answer is “discount specific line items, not the whole estimate.” The evidence in 2025–2026 is genuinely mixed, and a CTO should know it before accepting an “AI makes us 40 % faster” discount.

On one side, METR’s 2025 randomized study put 16 experienced open-source developers on their own mature repositories and found early-2025 AI tools made them 19 % slower, even though the same developers predicted they’d be 24 % faster and still believed they’d sped up afterward. METR’s own February 2026 follow-up notes that newer tools have shifted the picture, so the number isn’t a verdict. It’s a caution against pricing in speedups you haven’t measured on your own codebase.

On the other side, Google’s DORA research found in 2024 that a 25 % rise in AI adoption correlated with a 1.5 % drop in delivery throughput and a 7.2 % drop in stability; by 2025, with 90 % of developers using AI daily, throughput turned positive while stability still slipped. The pattern is “AI amplifies”: it magnifies whatever discipline (or chaos) a team already has. For estimation that means trusting measured local data, treating greenfield boilerplate and test scaffolding as the places AI genuinely compresses, and keeping senior architecture, discovery and integration effort at full weight. We use AI-assisted engineering internally and see real gains on the compressible parts, which is why our numbers come in lean, but we don’t discount the work that AI doesn’t touch.

The hidden costs nobody puts in the quote

The build price on the front of a proposal is the part everyone competes on, which is exactly why the rest gets left off. Year-one total cost of ownership typically runs 30–50 % above the headline build. Here’s where it hides.

Figure 4. The headline quote versus realistic year-one cost of ownership. The hidden band (discovery, compliance, monitoring, maintenance) adds roughly 45 % on this build.

Discovery and design (5–15 % of the project). Architecture, prototypes, a sprint plan. Vendors who skip it and start coding recover the cost later through change orders. You pay either way, just less predictably.

Project management (10–15 %). Planning, stand-ups, demos, stakeholder communication. Roughly one PM per four engineers is normal; cheaper shops hide it inside the engineer rate, which makes their number look lower until it isn’t. Our guide to software project management has the full case.

Senior code review and architecture oversight (about 8 %). A lead spot-checking pull requests and design choices is what keeps year-two tech debt off your books. It rarely appears as a line item, and it’s the first thing a lowball quote cuts.

Compliance audits. These are real dollars in 2026: a HIPAA risk assessment runs roughly $10–15k, a SOC 2 Type 2 audit $15–60k in auditor fees (a full first-year program with tooling and a pentest can reach $30–150k), and a SaaS penetration test $8–25k per cycle. Our HIPAA and SOC 2 cost breakdown walks through the full stack.

Monitoring, third-party services and on-call. Observability tooling, error tracking, an on-call rotation, plus the Stripes and Twilios and Auth0s of the world — a few hundred to a few thousand dollars a month at v1, growing with usage.

Maintenance after launch. Budget 15–25 % of the original build cost per year to keep the system healthy — dependency updates, security patches, small fixes. Software isn’t a purchase; it’s a subscription you pay to your own codebase.

Fixed-bid or time-and-materials?

Short answer: fixed-bid when the scope is genuinely clear, time-and-materials when it isn’t, and a hybrid more often than either purist would admit. Fixed-bid transfers risk to the vendor, so the vendor prices that risk in — you pay a premium for certainty, and you get change-order friction whenever the scope moves. It fits well-defined work: a compliance retrofit, an MVP with a locked feature list, a migration.

Time-and-materials fits ambiguous, discovery-heavy work — an early-stage product where next sprint depends on this sprint’s user feedback. A fixed bid on that kind of work is wrong by week three; weekly T&M milestones with a hard budget cap keep you in control without pretending you can forecast what you haven’t learned yet. The common best answer is the hybrid: T&M for discovery to narrow the cone, then a fixed bid for the build once the scope is real.

Seven red flags that an estimate is wrong

1. A single number, no range. “$200k” with no band means the vendor hasn’t priced uncertainty. Real estimates carry a range or an explicit risk-reserve line.

2. No non-functional requirements in the breakdown. If the line items are all features and none are availability, security, performance or scale, those will show up later as “out of scope.”

3. Hours that round to even thousands. “Portal: 200 hours. Dashboard: 150 hours.” Genuine bottom-up estimates produce odd numbers — 87, 142 — because they sum from real stories. Round numbers are a top-down guess wearing a bottom-up costume.

4. No discovery phase. “We can start coding Monday” means there’s no design step, and mid-project re-architecture costs three to five times what the discovery would have.

5. Zero pushback on your brief. A senior team challenges ambiguous scope, presses for NFR clarity and proposes alternatives. “Sure, we’ll build exactly what you wrote” means nobody senior read it critically.

6. Quotes that vary more than 3x across vendors. When bids range from $80k to $300k, the problem is your brief, not the vendors. Tighten it and re-quote — don’t average the confusion.

7. Fixed-bid with no change-order policy. A real fixed bid spells out how scope changes are priced. Without that clause, the vendor absorbs your changes for free until they can’t, then hands you a six-figure surprise at month four.

Red flags tell you which quotes to reject. Deciding whether to sign the one that survives is a different job, and it belongs to whoever owns the budget rather than the backlog. We wrote that side up separately as a buyer’s playbook for reading a software cost estimate: how to tell a ROM number from a definitive one, which contract model matches each, and the five questions to answer before you sign.

How to write a brief that gets accurate quotes

A tight brief is the single highest-impact thing a buyer controls. A vague two-pager gets you quotes that vary 5x; a structured brief pulls them inside 1.5x and, as a bonus, exposes which vendors actually engaged with the problem. Twelve sections cover it:

1. Company background: who you are, what you do, size, funding stage.

2. Problem and users: the pain you’re solving, who feels it, and what they do today.

3. Functional scope: user stories or epics with acceptance criteria — outcomes, not just features.

4. Non-functional requirements: performance targets, security and compliance, scale (daily and peak users), availability SLA, accessibility level.

5. Tech preferences: a stack if you have an opinion, or an explicit “recommend the best fit.” Both are fine; silence isn’t.

6. Timeline and milestones: which dates are hard (a launch event, a contract renewal) and which are soft.

7. Budget framework: a range, fixed, or T&M. Hiding the budget just makes everyone guess and waste time.

8. Evaluation criteria: what actually weights your decision — price, portfolio fit, technical depth, communication.

9. IP and data clauses: code ownership, data residency, sub-contracting, source-code escrow.

10. Submission requirements: format, deadline, who reviews, and your decision timeline.

11. Risk register: the known unknowns you want priced. Including one marks you as a sophisticated buyer.

12. References and portfolio: the kinds of past work you want to see.

Mini-case: how a tighter brief held a telehealth build

Situation. A US telehealth founder came to us the way most buyers arrive — with a two-page brief (“HIPAA video visits, scheduling, patient and clinician portals, billing handoff”) and three prior quotes that ranged from roughly $180k to over $500k for what looked like the same product. The spread wasn’t vendor greed; it was ambiguity. Nobody had written down the non-functional half.

Plan. Before estimating a dollar, we ran the brief through the twelve sections above and a one-hour scoping call: locked the NFRs (HIPAA controls, audit logging, availability target, 10 clinicians and 3,000 patients, US-only, English-only), named the third-party risks (the practice-management billing integration), and decomposed the app to user stories. Then we did the boring, disciplined thing — a bottom-up breakdown, a top-down analogous check against CirrusMED, our own HIPAA telehealth build, and an independent senior review that argued two line items down.

Result. With the NFRs written down, the estimate converged on a defensible band instead of a 3x spread, and the delivered project landed within about 15 % of the most-likely figure — the accuracy bottom-up is supposed to give when the scope is real. The founder didn’t get a cheaper number; they got a number they could take to their board without flinching. If you want the same treatment on a quote you’re weighing, book a 30-minute scoping call and bring the brief.

Fora Soft’s five-step estimation workflow

Step 1: brief intake. A one-hour call with a senior engineer and a delivery lead to confirm scope, NFRs and hard constraints, and to find analogous projects in our 250+ project history.

Step 2: top-down sanity check. Thirty minutes comparing against two or three analogous builds to produce a range that acts as an upper-bound check on the bottom-up that follows.

Step 3: bottom-up breakdown. One to three days decomposing to user stories, estimating each in story points, and converting to person-weeks via real team velocity — reviewed by a senior engineer.

Step 4: risk register and reserves. Named risks (third-party dependencies, regulatory, performance unknowns) each get a price, plus a 10–20 % reserve for the unknown unknowns.

Step 5: independent senior review. A different senior engineer — not the estimator — walks every line and asks “why this number?” We typically adjust 5–15 % here, almost always calibrating out optimism.

A decision framework: pick a method in five questions

When you’re not sure which method to demand from a vendor — or run yourself — walk these five questions top to bottom. Each “yes” pushes you toward more rigor.

Figure 2. Which estimation method to demand. Contract type and scope certainty do most of the work; project size and dependency risk decide the rest.

Q1. Fixed-bid or time-and-materials? Fixed-bid demands bottom-up. T&M tolerates top-down or PERT.

Q2. How locked is the scope? Tightly locked points to bottom-up; real unknowns to PERT; a wide-open scope means run a discovery spike first — estimating open scope is guessing with a spreadsheet.

Q3. How big is the budget? Under $50k, top-down is fine. $50–500k, bottom-up. $500k–$5M, bottom-up plus PERT on the uncertain modules. Over $5M, add Monte Carlo.

Q4. Have you or the vendor shipped this before? Yes makes an analogous estimate reliable. No means budget for 30 %+ variance and reserve accordingly.

Q5. Who reads the estimate? Engineers want bottom-up detail; a board wants a range with confidence intervals and an assumptions list. When both are watching, produce both views.

Pitfalls to avoid

1. Estimating without an architect. A senior architect sees the risk a PM can’t — integration complexity, performance cliffs, third-party quirks. Never sign off an estimate without one in the room.

2. Confusing ideal hours with real hours. A senior engineer’s productive day is five to six hours after meetings, review and debugging. Estimate against that, not an eight-hour fantasy.

3. Forgetting integration and load testing. Unit tests ride along with features; end-to-end, integration and load tests get forgotten and quietly account for 10–15 % of the work.

4. Underestimating data migration. Importing legacy data is never “just a script.” Schema mapping, data quality, edge cases, rehearsals and rollback make it a project of its own above trivial size.

5. Ignoring deployment and DevOps. CI/CD, infrastructure as code, monitoring setup and security hardening are 5–10 % of effort that estimates love to skip.

KPIs that prove your estimates are improving

Quality KPIs. Estimate accuracy: actual within 15 % of estimate on at least 75 % of projects. Risk-reserve consumption: under 70 % used on average. If you keep blowing through it, the reserve is too small, not the projects too unlucky.

Business KPIs. Win rate on quoted work (30–45 % on warm leads is healthy), margin actual versus modelled (within 5 %), and time from brief to quote (under seven days for a $200k project).

Reliability KPIs. Post-mortem rate: every project gets an estimate debrief, target 100 %. Change orders per project: a high count is a scope-specification problem wearing a delivery costume.

When not to formalise estimation

Genuine R&D. If you don’t know whether the technical approach even works, you can’t estimate the work — and pretending otherwise just launders a guess. Run a two-week timeboxed spike, then estimate on the far side of it.

Hyper-iterative discovery. Early MVP exploration where each sprint depends on last sprint’s feedback is better served by T&M with weekly milestones than a fixed forecast that’s wrong by week three.

Sub-$10k tactical work. A one-week feature doesn’t need a five-step workflow. A senior engineer’s gut estimate, padded 30 %, ships it fine.

FAQ

What to read next

Ready to ship a project that hits its estimate?

Software project estimation isn’t about a magic number. It’s about discipline a buyer can verify. The failures are predictable: vague scope, optimism anchoring, missing NFRs, third-party risk, founder discounts. Match the method to your unknowns (bottom-up for fixed bids, top-down for a first pass, PERT under uncertainty, Monte Carlo for the board) and always report a band with its assumptions, because the cone of uncertainty is real.

The hidden costs run 30–50 % above the headline, and the brief is what pulls every vendor’s number toward the truth. The vendor who pushes back on your scope, lists the NFRs, and quotes a range is the one who lands within budget. The cheap quote that skips those steps costs more in change orders, every time.