Capital Project Business Case Development for Manufacturing

A capital project is usually approved on a story of volumes, prices and start dates, and judged years later on numbers nobody agreed at the time. A strong business case states each assumption clearly enough to test, names who owns it, and shows what would change the decision. That makes the approval meeting sharper and the later review fair to everyone. See how iFactory AI helps test capital project assumptions against plant data.

Why Approved Cases Disappoint Later

Most business cases are built to win approval, and the numbers are chosen to fit. Years later, the plant is judged on figures that were never tested, owned or reviewed.

Flyvbjerg and colleagues argue that the root cause of overrun is behavioral bias, not scope change or complexity, and they recommend de-biasing estimates with reference class forecasting or similar methods. You do not need to accept every claim to use the lesson. Compare each estimate with the record of your own past projects.

Give the Case a Clear Structure

Public-sector guidance uses a five case model, as summarized in a CIO wiki article. The idea carries well into plant projects, with simple questions for each part.

Build an Assumption Register

The register is the heart of a checkable case. Each assumption becomes a row with a value, a source, a confidence level and an owner, so the case can be argued with facts.

Appraise With NPV, Payback and Sensitivity

Net present value discounts each year's cash to today's value, and payback counts the years to recover the outlay. Show both, and show how fast they move when an assumption changes.

Check Estimates Against Your Own History

Reference class forecasting asks one plain question: how did similar past projects turn out? Build a small grid using your own portfolio before trusting a new estimate.

Use Stage Gates With Evidence Rules

Gates work when each one asks for stronger evidence than the last. Early gates are cheap to stop, and late gates are costly, so test the shaky assumptions first.

Inputs Specific to Greenfield Projects

Scenarios and Kill Criteria

Track the Case After Approval

A case that stops at approval teaches nothing. Keep the register alive, and compare each assumption with real data as the project moves.

Common Mistakes in Capital Cases

Most weak cases fail in familiar ways. Reading this list before the next submission costs ten minutes and often saves a hard conversation at the review.

Contingency, Risk and Who Carries It

Contingency is a number that tends to be argued about and rarely explained. A clear case separates three ideas, and each belongs to a different person.

As a project moves through the gates, the estimate allowance should shrink because the design firms up. If it stays the same size at Gate 3 as at Gate 1, either the design has not progressed or the number was never based on anything. Both are worth asking about.

Risk reserves work best as a short register of named events. Each row carries a chance, a cost and an owner, and the sum is compared with the reserve. This turns an argument about a percentage into a review of specific, checkable risks, which is a far better use of a committee's time.

Benefits That Are Easy to Overstate

Cost estimates get the scrutiny, while benefits are often taken on trust. Test each benefit line with the same questions you would ask about a quote.

Working With Finance Without Losing the Plant View

Finance owns the discount rate, the depreciation rules and the tax treatment, and plant leaders own the physical story. Good cases keep both views visible and agree on the rules early.

Agree the discount rate, the evaluation period and the treatment of working capital before building the model. Changing them late makes every comparison with earlier projects unfair. Ask finance to publish a standard set of rules so that a packaging line and a new furnace are judged on the same basis.

Next, agree how benefits will be measured after start-up. A saving that cannot be seen in a plant report will not be believed in a review. Choose the measure, the data source and the owner now, and record them in the register next to the assumption. When the review arrives, nobody needs to debate the method.

Finally, agree what counts as success. A project can miss payback by a few months and still be a good decision, while another can meet payback and leave the plant worse off. Writing down the pass mark at approval, with a tolerance, removes much of the later argument and keeps the review focused on learning.

Reading the Register at Each Gate

The same register serves every gate, and the questions change as the project matures. Use the pattern below to keep meetings short and focused.

Over time the register becomes a record of how your own organization estimates. Patterns appear quickly, such as ramp-up that always runs long or quotes that always rise between feasibility and award. Those patterns are worth more than any outside benchmark, because they describe your suppliers, your people and your sites.

Share the findings openly. When project teams see that a missed estimate leads to a better next estimate, and not to blame, they begin to write honest assumptions on the first draft. That change in behavior is the real prize, and the tooling only makes it easy to sustain.

Governance Checklist

How to Judge the Program

How iFactory AI Supports the Business Case

iFactory AI holds the plant baseline, links it to the assumption register, and tracks results after start-up.

A 90-Day Starting Plan

Frequently Asked Questions