Estimation and ROI - Pinpoint Estimates Are Mostly Lies

About this article

As the fourth installment of the “Solution Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains estimation and ROI.

Architects who speak only in tech are half-fledged; speaking in numbers is full-fledged. This article handles FP method / story points / TCO / ROI / NPV/IRR, initial cost vs operational cost, phased-investment decisions, and AI-era estimation-accuracy improvement - the numerical tools needed to bridge tech and management.

What are estimation and ROI in the first place

Imagine a big household purchase. When buying a car, you “calculate not just the sticker price but insurance, taxes, gas, and parking for 5 years, then compare against the value of a shorter commute” — this is the personal version of ROI (Return on Investment).

IT project estimation and ROI follow the same structure. Calculate the total cost (TCO) including not just initial costs but operational costs, and compare against the resulting business effect to judge whether the investment is worthwhile — by numbers.

Without estimation and ROI, “technically correct” alone won’t earn management approval, and the project never starts. The shared language between tech and management is numbers.

Why estimation and ROI are needed

Get on the management-decision platform

Decisions on budget, personnel, and period are all done by numbers. “Technically correct” alone doesn’t get approved - investment-effect numbers are needed.

Priorities become clear

When multiple project candidates exist, starting with the highest ROI is rational. Without numbers, it becomes emotional.

Post-completion evaluation possible

To judge “success or failure” after project completion, comparing original assumptions with actuals is needed. Without ROI set, can’t verify.

Cost components

Project costs are thought of as initial + operational. Judging by initial alone causes the pattern of operational-cost deficits.

The modern way is estimating with 3-5 year TCO (Total Cost of Ownership), including operational cost invisible from initial alone.

Effect components

Effects split into quantitative effects and qualitative effects. Quantitative effects can be quantified; qualitative effects are hard to quantify but high in importance.

Operational time reduction is counted as effect in nearly all projects, the most-used effect. Calculate via hourly-wage conversion.

ROI calculation formula

Simple ROI calculation is below. Complex metrics exist, but simple formulas pass for explaining to management.

The general approval line is 3-year ROI 100%+. 200% means double-return after recovery.

NPV (Net Present Value)

ROI accounting for time value. The thinking that “JPY 1M now and JPY 1M 3 years later have different values” - converting future cash flows to discounted present value.

NPV = sum(per-year cash flow / (1+discount rate)^n) - initial investment

At 5% discount:
JPY 1M 3 years later ~= JPY 0.86M now

Large-scale / long-term projects use NPV. The discount rate is decided per company, usually 5-10%.

Payback Period

The metric showing in how many years investment is recovered. More intuitive than NPV, easy to land with management.

The general guideline is recovery within 3 years - exceeding requires additional explanation.

Estimation methods

Major effort-estimation methods are below. Not 1 method - combine multiple and compare results to raise accuracy.

For agile projects, Planning Poker + Velocity is practical. Estimate by relative complexity, not absolute values.

Estimation buffer

On the premise that estimates always shift, stack buffers (margins). Per novelty / uncertainty, see 20-50% buffer.

“Pinpoint estimate” is impossible - initial estimates becoming 1.5x isn’t rare. Not budgeting buffer is a typical estimation failure.

Concrete ROI calculation example

Calculate ROI using internal application-workflow digitization as an example. Concrete numerical calculations are an architect’s basic skill.

[Investment]
- Initial dev cost: JPY 5M
- Annual ops cost: JPY 1M x 3 years = JPY 3M
- Total investment: JPY 8M

[Effect] (3 years)
- 500 hours/month x JPY 3000/hour x 12 months x 3 years = JPY 54M
- Operational mistake reduction: JPY 0.5M/year x 3 years = JPY 1.5M
- Total effect: JPY 55.5M

[ROI]
(55.5 - 8) / 8 x 100 = 594%
Payback: about 6 months

Showing in numbers makes management decisions instant. Vague “operational efficiency” doesn’t get approved.

Handling qualitative effects

How to handle effects hard to quantify is the difficult part of ROI calculation. Forcibly quantifying or treating as qualitative effects in parallel - judgment needed.

Forcibly quantifying all qualitative effects loses persuasion, so the realistic answer is the 2-part composition of “quantifiable effects + list of qualitative effects.”

TCO (Total Cost of Ownership)

Cost over the entire lifecycle is called Total Cost of Ownership. Not just initial purchase price - compare in totals including operations, maintenance, retirement, opportunity cost.

Preventing “penny-wise, pound-foolish” is TCO analysis. Cheap initial cost with high operational cost is more expensive long-term.

Decision criterion 1: project nature

Depth of ROI analysis varies with project nature. Strategic investments emphasize qualitative aspects too, sometimes uncuttable by simple ROI.

Decision criterion 2: org culture

How to produce ROI varies with management’s decision style. Number-loving management wants detailed calculations; vision-emphasis emphasizes qualitative.

How to choose by case

Operational-efficiency projects (internal applications, RPA, etc.)

Operational efficiency like RPA evaluated with simple ROI + time-reduction monetary conversion + 3-year TCO. “X hours/month reduction x hourly wage x 12 months x 3 years” is direct quantification, Payback in front. Buffer +20% enough, 2-track estimation of analogous + bottom-up.

New business / B2C services

NPV + Payback + qualitative-effects list. Sales prediction is 3-point estimation of optimistic/pessimistic/most-likely, initial approval in PoC budget frame → main investment after seeing results. With high uncertainty, +50% buffer; also set early-withdrawal judgment criteria.

Infrastructure reform / cloud migration

5-year TCO comparison + 6R analysis + risk-reduction effects. Total comparison of on-prem maintenance vs cloud migration, including electricity, ops personnel, hardware updates. Also list qualitative effects of security strengthening / disaster response in parallel.

Regulatory compliance / security strengthening

Risk amount on violation + response cost comparison + loss if not done. ROI calculation unneeded (no choice not to do), put “avoid up to JPY X billion in personal-info-leak losses” forefront. Judge by regulation-fulfillment level over TCO.

Estimation-accuracy / ROI numerical gates

Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.

The iron rule for estimates is stacking buffer on the premise they shift. Below are industry-standard guidelines.

Pinpoint estimates are lies - missing correctly with range is honest. Presenting “JPY 30-45M, 50% buffer,” landing at JPY 42M gets evaluated as “expected.”

For estimates, “miss correctly with range.” Feigning accuracy loses trust.

Estimation / ROI pitfalls and forbidden moves

Typical accident patterns in estimation. All pay the cost of burying projects.

The 2013 Healthcare.gov launch failure (initial $94M estimate ballooning to $2B added, 1-year medical-policy stagnation) and Japan local-government core-reform projects (initial JPY 300M / 18 months becoming JPY 1.2B / 48 months, redo of council approval) - typical cases of the cost of pinpoint estimates.

Estimates designed on premise of shifting. Missing correctly with range is more honest than hitting pinpoint.

| “High ROI always gets approved” — overconfidence | Falls due to other-project comparison / budget constraints; alignment with management agenda matters | | “Estimate accurately” — aiming for pinpoint | Accurate estimation is impossible; showing in range (min-max) is honest |

AI decision axes

1. Compare via TCO (3-5 years) — include operational cost invisible from initial alone
2. ROI calculation simple formula + Payback — what lands with management is simple metrics
3. Always stack buffer — 20-100% per uncertainty, pinpoint is failure
4. Update estimation premise via AI — man-month basis is outdated, re-calculate via PoC-first

AI-era estimation shifts from “man-months” to “task units”

Traditional estimation used “how many man-months to build this feature” as the basic unit. In the AI era, this premise is breaking down. For the same feature, engineers who master AI tools differ in productivity by 3-10x from those who don’t, causing man-month-based estimates to lose accuracy.

What works instead is task-unit estimation. Decompose features into tasks and classify each as “automatable by AI” or “requires human judgment.” Count AI-automatable tasks with significantly compressed effort, and estimate human-judgment tasks at traditional effort levels.

AI can assist in this classification itself. Feed past project task lists to AI and instruct “classify tasks automatable with current AI tools,” and the estimate initial draft completes in short order.

A caution: overestimating AI effort-compression effects causes buffer shortfall, falling into the same failure as traditional “pinpoint estimates.” Conservatively count AI utilization effects as 30-50% compression and secure the remainder as buffer for safety.

Include AI costs (LLM API fees) in ROI calculations

Often overlooked in AI-project ROI calculations are LLM API usage costs. The development phase generates roughly $50-200/month per engineer in API fees, and embedding AI features in production services increases costs proportional to request volume.

ROI calculations need these as additional line items:

• Dev-time AI tool costs: GitHub Copilot, Claude, etc. subscriptions x headcount x months
• Production API costs: per-request price x projected traffic x months
• Vector DB / GPU infrastructure costs: infra costs when running RAG or inference in-house

Conversely, count AI-driven effort reduction on the ROI plus side. Convert development-period shortening, maintenance-effort reduction, and incident-response-time reduction to monetary values; the delta against API costs is the net ROI improvement. Rather than simply thinking “AI makes it cheaper,” comparing via TCO that includes new cost items is an honest estimate.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Cost composition (CapEx, OpEx, personnel)
• Effect quantification (time reduction, revenue increase)
• ROI calculation method (simple ROI, NPV, Payback)
• Estimation method (bottom-up, analogous, etc.)
• Buffer rate (margin per uncertainty)
• TCO period (3 years, 5 years, 7 years)
• Qualitative-effect handling (parallel listing or quantification)

Author’s note - cases of “estimation breakdown” causing project cancellation

Cases of estimation laxness burying projects are continuously told as standard talking points in the SI industry.

The 2013 Obamacare Healthcare.gov launch failure is a symbolic case caused by divergence between estimation and implementation capability. The US government’s medical-insurance-exchange site, with initial estimate of about $94M, scheduled October 2013 launch, but estimation of complex existing-system integration was sloppy, with system stoppage at thousands of concurrent connections on launch day. By 2014, estimated $2B added to recover. An incident slapping home that “estimation optimism stopped a nation’s medical policy for 1 year.”

Another, Japan local-government core-system reform projects are often reported - initial JPY 300M / 18 months estimate, with requirement-change accumulation finally reaching JPY 1.2B / 48 months, with procurement revisions and council-approval redo losing additional 1 year. The result of ordering “pinpoint estimate” without stacking buffer - entered the negative spiral of every change collapsing budget / deadline / council approval.

Both show the cost of not designing estimates on the premise of shifting. A case group teaching the practical truth that aiming to miss correctly with range rather than aiming to hit pinpoint results in more peaceful project landings.

Related Articles

https://en.senkohome.com/arch-intro-solution-overview/ https://en.senkohome.com/arch-intro-index-solution/ https://en.senkohome.com/arch-intro-solution-nfr/

Summary

This article covered estimation and ROI, including TCO, 3-point estimation, buffers, ROI, Payback, NPV, qualitative effects, and AI-era premise upheaval.

Compare via TCO, hit with Payback, honest with buffer, re-calculate on AI premise. That is the practical answer for estimation / ROI in 2026.

Next time we’ll cover “PoC design.” Plan to dig into Go/No-Go criteria, period setting, and effect-verification practice, plus numerical gates preventing “PoCs that never end.”

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.