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.
Before you read this
This article is mostly about requirements and cost-benefit across a whole system. If IT vocabulary is unfamiliar, reading the primers "How a Web Service Works" and "Servers and the Cloud" first makes it far easier to follow. You can also look anything up in the glossary as you read.
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.
The components of cost and effect
Project costs are thought of as initial + operational. Judging by initial alone causes the pattern of operational-cost deficits.
| Cost class | Content |
|---|---|
| Initial (CapEx = Capital Expenditure, investment for asset purchase) | Design, dev, hardware, licensing |
| Operational (OpEx = Operating Expenditure, operating expenses) | Cloud fees, maintenance, license renewal |
| Personnel | Internal-staff effort |
| Training | Education for users / operators |
| Opportunity cost | Loss from postponing other projects |
| Risk cost | Loss expectation on failure |
The modern way is estimating with 3-5 year TCO (Total Cost of Ownership), including operational cost invisible from initial alone.
The effect side breaks down in the same way.
Effects split into quantitative effects and qualitative effects. Quantitative effects can be quantified; qualitative effects are hard to quantify but high in importance.
| Effect class | Content |
|---|---|
| Cost reduction | Operational time reduction, personnel-cost reduction |
| Revenue increase | New customers, average customer value increase |
| Risk reduction | Avoiding incidents / violations |
| Operational quality | Mistake reduction, customer satisfaction |
| Speed | Faster decisions |
| Strategic value | Data utilization, DX foundation |
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 nowLarge-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.
| Payback period | Evaluation |
|---|---|
| Within 1 year | Extremely advantageous |
| 2-3 years | Standard approval range |
| 4-5 years | Cautious consideration |
| 5+ years | Strategic value needed |
The general guideline is recovery within 3 years - exceeding requires additional explanation.
How the estimate is produced matters as much as the buffer on it.
Major effort-estimation methods are below. Not 1 method - combine multiple and compare results to raise accuracy.
| Method | Content |
|---|---|
| Analogous estimation | Comparison with similar projects |
| Function point method | Calculate by feature count |
| COCOMO | Calculate by line count and complexity |
| Bottom-up | Stack work items |
| 3-point estimation | Optimistic / pessimistic / most-likely |
| Planning Poker | Agile, relative estimation |
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.
| Uncertainty | Buffer |
|---|---|
| Existing tech / similar projects | +10-20% |
| New tech / inexperienced | +30-50% |
| Has research element | +50-100% |
| PoC stage | Unable to calculate, flexible operations |
“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 monthsShowing in numbers makes management decisions instant. Vague “operational efficiency” doesn’t get approved.
Handling qualitative effects, and choosing by project nature
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.
| Qualitative effect | Handling |
|---|---|
| Employee satisfaction | Quantify via attrition reduction |
| Brand value | PR effect, ad-cost conversion |
| Security strengthening | Avoid penalty on violation |
| Strategic advantage | Competitor comparison, market share |
| Data foundation | Future AI-utilization value |
Forcibly quantifying all qualitative effects loses persuasion, so the realistic answer is the 2-part composition of “quantifiable effects + list of qualitative effects.”
Total cost of ownership is what keeps the comparison honest.
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.
| TCO components | Content |
|---|---|
| Initial cost | Hardware, software, dev |
| Operational cost | Personnel, electricity, network |
| Maintenance cost | License renewal, patches |
| Update cost | Periodic replacement |
| Retirement cost | Data migration, disposal |
Preventing “penny-wise, pound-foolish” is TCO analysis. Cheap initial cost with high operational cost is more expensive long-term.
The nature of the project decides which numbers matter.
Depth of ROI analysis varies with project nature. Strategic investments emphasize qualitative aspects too, sometimes uncuttable by simple ROI.
| Project | ROI emphasis |
|---|---|
| Operational efficiency | Very high (cost-reduction effect emphasized) |
| New business | Mid (uncertainty of revenue increase) |
| Infrastructure reform | Mid (TCO emphasized) |
| Security response | Low (risk reduction primary) |
| Regulatory compliance | Calculation unneeded (no choice not to do) |
So does the culture of the organisation you are presenting to.
How to produce ROI varies with management’s decision style. Number-loving management wants detailed calculations; vision-emphasis emphasizes qualitative.
| Culture | Recommended |
|---|---|
| Number-emphasis | NPV, IRR, Payback triad |
| Balanced | ROI + qualitative effects |
| Vision-emphasis | Strategic value forefront, ROI supplementary |
By case, the way the numbers are assembled changes.
Operational-efficiency projects — internal applications, RPA and the like. 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.
A new business or a B2C service. 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 and 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 and 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.
Numeric gates for estimation accuracy and ROI
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.
| Item | Recommended | Reason |
|---|---|---|
| Buffer (existing tech / similar projects) | +10-20% | Standard uncertainty |
| Buffer (new tech / inexperienced) | +30-50% | Learning-cost expectation |
| Buffer (has research element) | +50-100% | PoC-first premise |
| Payback Period | Within 3 years | General approval line |
| 3-year ROI | 100%+ | Recovery+profit minimum |
| TCO evaluation period | 3-5 years | Include operational cost |
| Qualitative-effect handling | Parallel listing | Forced quantification drops trust |
| Estimation method | Multiple combined | Dual-track of analogous + bottom-up |
| NPV discount rate | 5-10% | Per company standard |
| Cloud-ops-cost / revenue ratio | 5-15% | Varies by industry |
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.
Pitfalls and forbidden moves
Here are the six most dangerous of the typical ways estimation goes wrong. Every one of them carries a price that buries the project.
| Forbidden move | Why it is bad → what to do instead |
|---|---|
| Presenting an exact-to-the-yen estimate | the standard municipal case of 300 million yen becoming 1.2 billion → present a range with a buffer |
| Judging on the initial cost alone | the running cost reverses the ranking → evaluate on TCO over three to five years |
| Producing the estimate by a single method | the accuracy is not there → double it up, analogy plus bottom-up |
| Forcing every qualitative effect into a number | you lose both persuasiveness and trust → separate what can be quantified from what is listed alongside it |
| Starting a new-technology project with no buffer | the estimate always turns out 1.5 times larger → a 30 to 50 percent buffer is mandatory |
| Never revising an estimate once it is set | it stays rigid when the premises change → run a PoC first and recalculate continuously |
Overconfidence in “a high ROI always gets approved” is out too. It can still fall to comparison with other projects or to budget constraints, which makes consistency with the management agenda the thing that matters. The Healthcare.gov launch failure of 2013 (an initial 94-million-dollar estimate that took two billion more, stalling health policy for a year) and Japanese municipal core-system replacements (an initial 300 million yen over 18 months becoming 1.2 billion over 48, with council approval to redo) are the archetypal cases of the price of an exact-to-the-yen estimate.
Three scenarios
If you are building solo or at a startup
Rather than a strict ROI calculation, approving against a PoC budget envelope and setting an early-exit criterion is the practical move. Present the effect purely as a time conversion — “X hours saved a month × hourly rate” — and allow a 50 percent buffer for the high uncertainty. If you have time to polish the numbers, spend it on one more round of verification instead.
If you are a small or mid-size SaaS
Decide on a set of three: simple ROI, payback within three years, and three-year TCO. Present a range from a double estimate — analogy plus bottom-up — with a 20 to 30 percent buffer, and recalculate the premises quarterly.
If you are a large enterprise
Getting it through the board means the full kit: NPV, IRR and payback, five-year TCO, and the qualitative effects listed alongside. Regulatory-compliance work needs no ROI calculation and is compared against the risk exposure instead; strategic investment leads with the qualitative effects. Changing how the numbers are assembled by project type is, I think, the craft of getting an approval through.
AI decision axes — The premises of estimation have changed completely
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
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.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (84/95)