Is the Cost Underestimated?

Check only whether the estimate runs low — not whether it's worth doing

My estimate for this plan is: [total cost / timeline]. Check one thing only: is this estimate systematically low? 1) List the cost lines that usually get missed — communication, migration, rework, training, compliance, maintenance, opportunity cost; 2) Give each a magnitude and a basis, not “there may be some”; 3) Name the line that most often overruns on comparable projects and by how much; 4) Separate one-off from recurring costs, and annualize the recurring ones; 5) Give a conservative number and a worst case, and say which step drives the gap. Do not judge whether the plan is worth doing.

How to use

Fill in “quoted price” and “internal headcount” separately. Mixed together, the underestimate hides in the headcount.

Good for

The budget is approved and the plan is promised externally, and you need to know whether the real cost lands on you in two or three months.
You're comparing two options with a 15% price gap, and something tells you the cheaper one is more expensive later.

Not for

You're still choosing a direction and the shape of the plan isn't set — costing it now produces assumptions; run a small pilot instead.
You have 9 months of runway left and need to get budget approved — what's missing is the benefits case; this prompt only makes your number bigger without winning the argument.

Example

Input

We're launching a new membership tier in three months. Development quoted ¥280k; my own estimate is ¥350k including internal headcount, and I'm putting ¥400k in the annual budget.

What you get

The line you're missing isn't development, it's migration: 12,000 existing members' tiers, points, and order history have to be recomputed, and at 4 minutes of manual checking each that's 800 hours, roughly ¥120k. Then recurring cost: benefits need someone to maintain and configure them, at least half a headcount, ¥150k a year that isn't in the project budget. A conservative number is around ¥620k, and the worst case hinges on migration rework — if the order-history format doesn't reconcile, another ¥100k and another month.

Common mistakes

Using it to build a case against something already decided: inflate every line, conclude nothing can be done, when you simply don't want to do it.
Giving a total with no breakdown — it can't tell which line is low, so it hands back a scarier number based on industry averages.

Try tweaking it like this

Swap “check for underestimation” for “which three optimistic assumptions does this estimate rest on,” with a falsification condition for each.
Add “give me a P50 and a P90,” forcing a range instead of a point, which is what you need when budgeting upward.