Budget a multi-year software program as phases with a decision gate between each, not as one number: discovery at 3 to 7 percent, a first release at 30 to 40 percent, two or three increments at 15 to 20 percent each, and running costs of 15 to 25 percent of the build per year from go-live. Hold 15 to 25 percent contingency yourself, outside the vendor's quote. Commit to the first release and present later phases as estimates each gate can stop.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
The budget that gets a software program approved and the budget that gets it delivered are usually two different documents, and the gap between them is where programs die. The first is a single number, chosen to be approvable. The second is a phased plan with contingency, running costs and a way to stop. This post is about writing the second one from the start: how to structure the phases, how to size contingency, what the finance team will ask, how to think about capital and operating spend without pretending to be your accountant, and how to present the whole thing to a board so that it survives contact with year two. It is one chapter of our buyer's guide to enterprise software development.
Why does a single number fail?
A single number for a three-year program is wrong in both directions. It is too high for what you know today, because it prices work that has not been scoped, and too low for what you will eventually do, because it omits the capabilities the business will ask for once the first release works. Worse, a single number has no decision points. Once approved, the program runs until the money is gone, and the only governance question is whether to add more. A phased budget replaces one approval with several smaller ones, each made with better information. Why software projects go over budget lists the mechanisms, and almost all of them are easier to catch at a gate than in a quarterly review.
What does a phased budget look like?
The table shows a core business platform of $500,000 (€435,000, £370,000) over 18 months, followed by two years of operation. The proportions transfer to larger and smaller programs.
| Phase | Duration | Share | Example | Certainty | Gate decision |
|---|---|---|---|---|---|
| Discovery | 4 to 8 weeks | 3 to 7 percent | $25,000 (€22,000, £18,000) | Fixed price | Proceed to build, change scope, or stop with a usable plan |
| Release one | 4 to 6 months | 30 to 40 percent | $175,000 (€150,000, £130,000) | Committed after discovery | Go live, measure adoption, confirm the increments |
| Increment two | 3 to 4 months | 15 to 20 percent | $90,000 (€80,000, £65,000) | Estimate, confirmed at gate | Continue, reorder, or pause |
| Increment three | 3 to 4 months | 15 to 20 percent | $90,000 (€80,000, £65,000) | Estimate | Continue or hand to run |
| Data migration and cutover | Spread across phases | 10 to 20 percent | $70,000 (€60,000, £50,000) | Estimate, firmed after discovery | Cutover readiness |
| Contingency | Held by you | 15 to 25 percent | $100,000 (€85,000, £75,000) | Reserve | Released by the steering group only |
| Running costs | From go-live, per year | 15 to 25 percent of build | $90,000 per year (€80,000 per year, £65,000 per year) support plus $40,000 per year (€35,000 per year, £30,000 per year) infrastructure | Quoted | Annual renewal |
Two things are deliberate. Discovery is a separate, small, fixed-price phase whose output is the plan for everything else, and it is worth paying for even if you then choose another vendor. The discovery phase for enterprise software explains what it delivers. And running costs are on the same sheet as the build, so nobody is surprised in month 19. Enterprise software support and SLAs has the detail on that line.
How much contingency, and who holds it?
Hold 15 to 25 percent of the program value as contingency. The low end for a well-understood process replacing one system, the high end for a program with several integrations, a data migration from multiple sources, or regulatory work. Hold it yourself, in your budget, released by the steering group, not padded into the vendor's quote where it becomes margin. Even well-scoped work sees 10 to 20 percent of its value in change requests, because building a system teaches the business what it actually needs. That is not failure. It is the reason contingency exists. The failure is a program with no contingency, which stops halfway and returns to the board for more money with nothing to show. MSA, SOW and change requests covers how to contract for the changes so that they are visible and priced rather than absorbed and resented.
What will finance ask?
- "What is the total?" Give the phased table and the five-year total, including running costs. Explain which lines are committed and which are estimates.
- "What do we get if we stop after phase one?" A working system for one workflow, in production, with its users. If the answer is nothing, the phasing is wrong.
- "What is the return?" Hours saved, errors avoided, revenue enabled, licenses retired, risk reduced. Quantify the two or three you can defend and leave the rest as qualitative. A program that retires $200,000 per year (€175,000 per year, £150,000 per year) in licenses and workarounds has a payback the finance team can check.
- "Why not buy something?" Have the answer ready. Build vs buy over five years is the comparison they want to see.
- "What is capital and what is operating?" See below.
- "Who owns it when it is done?" The code, the data, the cloud accounts, in the company's name. Who owns the code is the plain-language version of the clause.
- "What happens if the vendor fails?" Source code in your repository, documentation at each phase, a second team able to pick it up. This question is easier to answer when the first two are true.
Capital or operating spend, in plain terms
This is not accounting advice, and the rules differ by jurisdiction and reporting standard, so take the structure to your finance team and let them apply the rules. The shape is this. Money spent creating a new asset with a multi-year life, which is roughly the design and build of new software, is often treated as capital expenditure and depreciated over its useful life. Money spent keeping an asset running, which is roughly support, hosting, patches and licenses, is operating expenditure in the year it is spent. Discovery and early feasibility work sometimes sits on the operating side. The practical consequence is that a phased budget maps naturally onto the distinction: build phases on one line, running costs on another, and the finance team can treat each as they must. Vendors should be able to invoice in a way that makes the split clear, with build milestones separated from support fees, and you should ask for that at contract stage rather than at year end.
How do you present it to the board?
- Lead with the problem and the cost of not acting. The license bill, the staff hours lost to workarounds, the system that cannot be upgraded, the risk finding. One slide.
- Show the phased table. Commitment for discovery and release one. Estimates for the rest. Contingency visible, not hidden. Running costs on the same page.
- Ask for approval in two parts. Approve discovery and release one now. Approve the program envelope in principle, with each increment released at its gate by the steering group within that envelope.
- Name the gates and who sits at them. A steering group of the sponsor, the business owner, finance and IT, meeting at each gate with a go, change or stop decision. Why enterprise software projects fail shows what happens when that group does not exist.
- State the measures. Adoption, cycle time, error rate, licenses retired. Two or three numbers the board will see again at each gate.
- Say what stop looks like. A program that can be stopped at a gate with a working release in production is a lower-risk ask than one that cannot. Boards approve lower-risk asks.
The budget checklist
- Phases with a gate and a decision between each.
- Discovery fixed-price and separate.
- Release one committed, later phases estimated.
- Migration as its own line.
- Contingency of 15 to 25 percent, held by you.
- Running costs on the same sheet, from go-live.
- Build and run invoiced separately.
- Measures the board will see at every gate.
How 7L budgets with clients
7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens. We have supported more than one hundred organizations and we have sat in enough steering groups to know that the phased table above is the document that keeps a program alive. We quote discovery at a fixed price, commit to release one after it, estimate the increments with stated assumptions, and separate build milestones from support fees on every invoice. We modernize incrementally rather than big-bang, which is what makes a stoppable program possible. If you are preparing a budget for a board or a finance review, send us the outline and we will help you structure it, whoever ends up building it.
Frequently asked questions
How much contingency should a software program hold?
15 to 25 percent of the program value, held by you and released by the steering group, not built into the vendor's quote. Use the low end for a well-understood process replacing a single system and the high end for programs with several integrations, migration from multiple sources, or regulatory requirements. Expect 10 to 20 percent of the value in change requests even on well-scoped work.
Should I ask for one total or a phased budget?
A phased budget, with a gate between phases. Commit to discovery and the first release, estimate the later increments, and show running costs from go-live on the same sheet. A single total has no decision points and is wrong in both directions: too high for what is known today, too low for what the business will ask for once the first release works.
What should the first release cost relative to the whole program?
30 to 40 percent of the program, delivering one complete workflow into production with real users. That is large enough to prove the architecture and the integrations, and small enough that the business sees value within four to six months. If the first release is under 20 percent of the program it is probably a prototype rather than a release.
Is custom software capital or operating expenditure?
Often both, depending on jurisdiction and reporting standard, so ask your finance team to apply the rules. Broadly, the design and build of new software is frequently treated as capital expenditure and depreciated, while support, hosting, licenses and patches are operating expenditure. A phased budget with build and run on separate lines, and invoices that separate them, makes the split straightforward.
How do I justify the running costs to finance?
Show them as 15 to 25 percent of the build per year for support and maintenance plus infrastructure, and set them against what the program retires: licenses, workaround hours, the cost of incidents on the old system, and the risk of a system that cannot be patched. Running costs that are visible from the first approval are accepted. Running costs that appear in month 19 are a crisis.