Board meeting, item five: a new B2B customer portal. The sales director argues that without it the company is losing orders to competitors. Asked about cost, the IT director says: “Somewhere between €400,000 and a million, depending on scope.” The CFO puts down her pen. The CEO asks for a specific number at the next meeting, because no decision can be made on a range like that.
A month later there is one number on the table: €640,000. It looks serious, it has decimals in the spreadsheet, and nobody asks where it came from. The board approves it, procurement sends out an RFP, and the three proposals that come back are €420,000, €780,000 and €1.1 million. Each is now judged against a number that was a guess from the start.
This article is for CEOs, CFOs and the people who prepare their board papers. It shows how to build the cost estimate and business case for an IT project before any vendor proposals arrive. The thesis may feel uncomfortable: at this stage an honest budget is a range with assumptions, and a good board decision covers the first stage, not the whole project. A single number given too early does not reduce risk. It hides it.
Why does the board get one number when it should get a range?
Because one number fits more easily into a budget spreadsheet and a board minute. A range looks like a lack of preparation. Yet at the start of a project knowledge of scope is thin, and cost follows from scope. Steve McConnell, in a Construx white paper, describes the “cone of uncertainty”: at the initial concept stage, actual cost can turn out up to four times higher or four times lower than the estimate. Critics such as Laurent Bossavit point out that these specific ratios come from expert judgement rather than a measured dataset, but the direction is not in dispute: uncertainty only shrinks as decisions about scope are made.
Data on budget overruns shows what happens when that uncertainty is ignored. McKinsey, together with the University of Oxford, analysed more than 5,400 IT projects in 2012. Large projects, with initial budgets above USD 15 million, ran on average 45% over budget and 7% over time, while delivering 56% less value than predicted. Your project may be smaller, but the mechanism is the same: a budget approved before scope is understood becomes the yardstick for every later disappointment.
So what should the board receive? A range with clearly stated assumptions, an explanation of what must be done to narrow it, and a request for a decision on exactly that step. This is not dodging accountability. It is recognising that a decision worth several hundred thousand euros or more deserves a few weeks of work that let you make it with your eyes open.
What must an IT project cost estimate contain?
An estimate that shows only the vendor’s price is incomplete. A full one covers everything the company will spend because of the project, whoever it pays. Structure it in ten lines.
Analysis and discovery. Refining requirements, wireframes, architecture, delivery plan. Usually a separate, short engagement.
Build. The delivery team’s work: developers, testers, UX designers, analyst, project manager.
Integrations. Connections to ERP, CRM, payments and partner systems. Often underestimated, because their complexity shows up on the side of systems that already exist.
Data migration. Moving, cleansing and verifying data from legacy systems.
Licences and infrastructure. Cloud, component licences, tooling, test environments.
Security and compliance. Penetration testing, a GDPR review, sector-specific requirements.
Internal costs. The time of your own staff involved in the project (more below).
Rollout and change management. Training, materials, communication, a period of running old and new systems in parallel.
Run and evolve. Costs after go-live over three to five years.
Contingency. Calculated, not added as a round percentage.
Describe each line in three columns: amount or range, source of the estimate (proposal, analogy, calculation, assumption) and owner, the person accountable for it. The “source” column matters most, because it shows the board which figures are firm and which are guesses. If half the budget has “assumption” as its source, that is important information, not an embarrassing detail.
How do you estimate build cost before proposals arrive?
Without proposals, build cost can be estimated in three ways. Use at least two and compare the results.
Analogy. Comparison with similar projects, your own or publicly documented ones. If the company built a similar system three years ago, its actual cost (not its budget) is a valuable reference point. Bent Flyvbjerg calls this reference class forecasting and has long argued that it is an effective defence against planners’ optimism. The weakness of analogy is choosing the comparison: projects always seem more unique than they are.
Parametric estimate. Team composition times duration times rate. This is arithmetic a board grasps immediately. An illustrative example: a team of four senior specialists and one mid-level engineer working for eight months. According to ARDURA’s 2026 benchmark for engineers from Poland, a senior backend developer costs about EUR 335–485 per day and a mid-level one about EUR 240–335. Taking EUR 410 and EUR 290 per day and 20 working days a month, four seniors cost about EUR 32,800 a month and the mid-level engineer about EUR 5,800, so roughly EUR 38,600 a month, or about EUR 309,000 over eight months. Equivalent in-house or Western European rates will be higher; the method is the same. For comparison, ARDURA’s software development services page states that a typical three-person team (two developers and a QA engineer) costs about EUR 14,500–28,700 a month depending on seniority. The weakness of this method is that it requires an assumption about duration, which is exactly the unknown.
Bottom-up estimate. A feature list, each feature estimated by the people who will build it, summed at the end. It is the most accurate, but needs a well-described scope, so at concept stage it is usually not yet possible. It works well after discovery.
What if two methods give very different results? Do not average them. The gap is information: usually it means the analogy misses something that is different in your project (new integrations, larger data volumes, regulatory requirements), or that the parametric estimate assumes too short a duration. Record both figures, explain the difference and show the board which assumption must be checked to resolve it. That question often becomes the first task of discovery.
For a quick sense of scale on smaller projects, our MVP cost calculator gives an indicative cost and time range from the product type, platform, features and integrations. General timeframes from our services page: a simple MVP takes two to three months, a mid-size application four to eight months, an enterprise system eight to eighteen months. Such ranges do not replace an estimate, but they let you check that yours is in a sensible order of magnitude.
Which internal costs do boards most often leave out?
Internal costs are the most frequently omitted line, because they generate no invoice. Staff are paid anyway, so their time seems free. It is not: if the head of customer service spends two days a week for six months in workshops, acceptance sessions and testing, her team gets less of her attention and her other work waits.
The key buyer-side roles are the product owner (who makes decisions on scope and priorities, usually for a large share of their time), subject matter experts (who know the processes and answer analysts’ questions), acceptance testers (users who check that the system does what they need), administrators of the systems you integrate with, and the person managing the vendor and the contract. Count their time in person-days and multiply it by the fully loaded cost of employment.
An illustrative example, with assumptions stated for the calculation. A product owner at half time for ten months is about 100 person-days. Three subject matter experts at one day a week over the same period add roughly 130 more. Ten users testing for two weeks before go-live are 100 person-days. That is about 330 person-days in total. At an assumed fully loaded cost of EUR 350 per day, it comes to around EUR 115,000, a significant share of a EUR 600,000 project, even though it will never appear on an invoice. Your figures will differ, but the order of magnitude usually surprises boards that have not counted it before.
The second group of overlooked costs is data work. Migrating data from a system that has been running for ten years almost always reveals duplicates, gaps and inconsistencies. Someone must decide what to do with them, and that is usually work for subject matter experts, not developers.
The third group is the transition period. For weeks or months, old and new systems may run in parallel, staff learn new tools and work more slowly, and the service desk gets more tickets. These costs are real even if they do not sit in the project budget. Show them to the board so they are not a surprise in the first quarter after go-live. We cover IT team costs in the language of finance in our article on IT team budgeting for 2026.
How do you calculate total cost of ownership over three to five years?
Build cost is usually the smaller part of a system’s lifetime cost. After go-live the system has to be maintained: libraries and components updated, bugs fixed, changes made as the systems it integrates with change, and it must be monitored, secured and evolved. Add infrastructure, licences and user support.
Total cost of ownership (TCO) is the sum of build and running costs over a chosen horizon, usually three to five years. The horizon should match the realistic life of the system and the period over which you count benefits. Comparing five years of benefits with build cost and no running cost is the most common mistake in business cases.
How do you estimate running costs before choosing a vendor? You can assume a maintenance team of a given composition and price it parametrically, as with the build. You can also draw on the company’s experience with similar systems. Either way, record the assumption and its source. For SaaS options, compare the subscription over the whole horizon with the cost of building and running your own system, not one year’s subscription with the build cost.
An illustration shows why this matters. If building the portal costs EUR 300,000 and running and evolving it needs a team of two people all year, maintenance at the rates described above can cost well over EUR 150,000 a year. Over five years, maintenance easily exceeds the build cost, before infrastructure, licences and user support. A board that approved EUR 300,000 has in fact committed to several times that amount; nobody showed it.
The practical lesson: when comparing options, ask not only about build cost but also how many people, with which skills, will be needed to run the system after go-live. An option that is cheaper to build but based on a niche technology can be more expensive to run, because specialists are harder to find.
We break down the components of TCO and the hidden costs of software in our article on total cost of ownership. Here one rule is enough: the board should approve TCO, not build cost, because TCO is what it will pay.
How much contingency should you include, and how do you justify it?
Contingency written as “plus 15%” with no justification is the first line a CFO wants to cut, and rightly, because nobody knows what it pays for. Contingency calculated from a risk register is much harder to challenge.
Separate two things. A risk reserve covers events you can name: the ERP integration turns out harder, the data needs more cleansing, a key subject matter expert is unavailable. For each risk you estimate probability and cost, and the sum of the products gives the reserve. A management reserve covers what you did not foresee and is released by board decision, not by the project manager. Our glossary entry on risk management in IT projects covers the basic techniques.
How large should they be? There is no single value, and anyone quoting a universal percentage is simplifying. The size should follow from uncertainty: higher at concept stage before discovery, lower once scope and architecture are defined. The McKinsey and Oxford finding of a 45% average overrun on large projects is not a norm to copy, but it is a reminder that near-zero contingency on a project with unclear scope is a statement of optimism, not a plan.
Link contingency to the contract model too. Under fixed price the vendor takes on part of the risk and builds it into the price, so your contingency can be lower, but you pay for that risk in the price. Under time and materials the risk stays with you, so contingency must be higher, but you pay only for what actually happens. A comparison of models and how they share risk is in our article on team subscription, time and materials and fixed price.
How do you build scenarios: base, cautious and minimum?
A single number hides the fact that project scope is a decision, not a fact. Three scenarios show the board what it gets for what money and let it choose deliberately.
Minimum scenario. The smallest scope that solves the main problem. For a B2B portal this might be ordering, order status and invoices, without a product configurator or partner integrations. Lowest cost, fastest launch, part of the benefits.
Base scenario. The scope the business expects, with realistic assumptions about integrations and data. Your main recommendation rests on this one.
Cautious scenario. The same scope as the base case, but with assumptions that may not hold: harder integrations, more data cleansing, a longer transition. It shows what the project could cost if several risks materialise.
Add a “do nothing” option: what keeping the current state costs over the same horizon. It is an often-missing reference point, and without it you cannot judge whether the project pays. Maintaining the old system, manual order handling, lost sales and the risk of failure on an unsupported technology all have a price.
Scenarios also help in talking to vendors. Instead of asking for a price on one rigid scope, you can ask for the minimum scenario with priced extension options. That lets you start with a smaller commitment and extend scope once the first part starts delivering benefits.
How do you present benefits and ROI so the CFO accepts them?
The benefits side of a business case is usually weaker than the cost side. Costs have proposals and rates; benefits have adjectives: “streamlining”, “better customer experience”, “competitive advantage”. The CFO cannot check them, so she does not count them.
Split benefits into three categories. Revenue: additional sales, larger basket value, lower churn. Cost: less manual work, lower legacy maintenance, fewer errors. Risk avoided: end of support for a technology, regulatory penalties, outages. For each benefit give the measurement method, today’s baseline, the target value, the date and the owner, a business person who signs up to that number. A benefit without an owner is a wish.
A well-described benefit reads something like this: “The share of orders placed through the portal will grow from 0% to 40% within twelve months of launch; each order a customer places on their own saves on average 12 minutes of service team time, which at current volume means X hours a month; owner: sales director; measured monthly from the order system report.” The numbers are illustrative, but the structure shows what a CFO expects: a baseline, a target, a mechanism, an owner and a measurement method. A benefit like that can be checked after a year, and that turns the business case from a promise into a commitment.
Avoid double counting. If the portal shortens order handling, you can count the time saved by the service team or the additional sales that team can handle in the time saved, but not both. Also avoid converting saved hours into money if nobody plans to change headcount or move people to other work. Time that dissolves into the organisation does not improve the bottom line.
Finally, the indicators: payback period (when cumulative benefits exceed cumulative costs), net present value at the company’s discount rate, and possibly ROI. Show them for each scenario. How to estimate the return on custom software realistically is covered in the calculator in the CEO’s head, and how to calculate the return on external specialists in our article on ROI of IT outsourcing.
How do accounting and tax change the picture of the budget?
It matters to the board whether a project hits profit in one year or is spread over several. The same cash outlay can look very different in the income statement depending on whether it is capital expenditure or an operating cost.
A few principles are worth knowing before talking to your finance team. Software built for own use can be capitalised as an intangible asset if it meets the criteria of the applicable framework. Under IFRS, IAS 38 separates the research phase, which is expensed, from the development phase, which can be capitalised when its conditions are met. Local frameworks, such as the German HGB or the UK’s FRS 102, have their own rules and options. SaaS subscriptions and cloud services are usually operating costs. Vendor delivery services can be an operating cost or part of the value of capitalised software, depending on what they relate to. Tax depreciation rules differ again by country.
These distinctions affect the choice of option. A SaaS solution and a custom-built system can have similar TCO over five years but a completely different profit impact in year one. A company focused on operating profit in a given year may prefer a different structure from one that looks mainly at cash flow.
This is not tax or accounting advice. The point is that the budget presented to the board should show not just cash but also the profit impact in each year, agreed with finance before the meeting, not during it.
What does a one-page business case for the board look like?
The board will not read forty pages. A business case should fit on one page, with appendices for those who want to check the detail. The table below shows a structure that works as a starting point.
| Section | What it contains | Board question it answers |
|---|---|---|
| Problem and objective | What does not work today, what it costs, what we want to achieve | Why are we doing this? |
| Options | Minimum, base, cautious, “do nothing”, possibly SaaS | What are our choices? |
| Build cost | Range for each option, source of estimate | What does it cost to build? |
| Internal costs | Person-days on our side, transition period | What does it cost us internally? |
| TCO over 3–5 years | Build plus maintenance, licences, infrastructure | What will we pay in total? |
| Contingency | Risk reserve and management reserve | What if something goes wrong? |
| Benefits | Measurable, with baseline, target and owner | What do we get, and who is accountable? |
| Indicators | Payback, NPV for each scenario | Does it pay? |
| Profit impact | Split between capital and operating costs | How will it affect profit year by year? |
| Stages and decisions | First stage, its cost, criteria for going further | What are we deciding today? |
| Assumptions | List of assumptions with a confidence rating | What does all of this rest on? |
The last row is the most important, even though it usually comes last. The list of assumptions lets the board see which parts of the budget are firm and which are hypotheses to test in the first stage. A good business case does not pretend to a certainty it does not have.
How do you make the decision in stages rather than all at once?
The best response to uncertainty is not a bigger contingency but smaller decisions. Instead of approving the whole project at once, the board approves the first stage with a clearly defined cost and criteria that, once met, bring it back for the next decision.
A typical split looks like this. Stage one is discovery: refined requirements, architecture, a prototype, a narrowed estimate. It takes a few weeks and costs a fraction of the whole. At ARDURA, discovery on software development projects takes one to two weeks and is used to define scope and architecture. Stage two is a minimum version launched to some users, on which you test the first benefits. Stage three is growth to full scope, funded on the results of stage two.
The criteria for moving between stages should be written down in advance. For discovery: scope described, cost range narrowed to an agreed width, key risks identified, contract model decided. For the minimum version: benefits measured with real users, cost within range, no blocking technical issues. If the criteria are not met, the board can change scope, change vendor or stop the project, losing a fraction of the budget rather than all of it.
How do you put such a decision to the board? Instead of a motion to “approve a project budget of X”, the board receives a motion to “approve discovery for Y, to finish by Z; at the end we will receive a narrowed estimate, a recommended contract model and a vendor shortlist for the RFP, and on that basis we will decide on stage two”. The CFO gets an amount that can be controlled, and the sales director sees the project start now rather than after another quarter of discussion. Show the board the full range for the whole project at the same time, so nobody is surprised by the scale when the stage-two decision comes.
This approach also changes the logic of funding. Instead of an annual project budget, successive stages are funded on the value delivered. This is often called agile budgeting, or funding value rather than projects.
How does the budget shape vendor selection and the contract model?
A budget prepared before choosing a vendor is not only a board paper. It is also a tool for talking to the market. A few decisions are worth making deliberately.
First, whether to give vendors the budget range. Without it, vendors propose solutions of very different scale and proposals are hard to compare. Disclosing a range need not mean everyone prices at the top, provided the RFP has a precise scope and clear evaluation criteria. Second, whether to buy discovery as a separate engagement first. It reduces risk for both sides, and you can use the resulting document in later vendor selection if the contract transfers its rights to you.
Third, the contract model. Fixed price gives budget predictability but needs a precise scope and carries a risk premium. Time and materials gives flexibility but needs active scope management and caps. A team subscription moves the conversation from project price to monthly cost and delivery pace. Each model needs a different contingency and a different way of reporting to the board.
Fourth, how to compare proposals with the budget. Compare them with the range and its assumptions, not with a single number. A proposal below the bottom of the range signals that the vendor left something out or assumed something different, and it is worth checking that before signing rather than after the first change request. If the project extends an existing system whose condition you do not know, consider commissioning an independent technical due diligence before budgeting; at ARDURA the Code Health Audit starts from EUR 4,500, takes one to two weeks and has a fixed scope.
What are the key takeaways before the board meeting?
An IT project budget prepared before vendor selection does not have to be guesswork, but it must not pretend to certainty it does not have. A good estimate shows a range, its sources and its assumptions, and a good board decision covers the first step that will narrow that range.
Remember six things. First, present a range with assumptions instead of one number, and say what must be done to narrow it. Second, structure the estimate in ten lines, including internal costs, data migration and the transition period, and give the source of each estimate. Third, ask the board to approve TCO over three to five years, not just build cost. Fourth, calculate contingency from a risk register and keep it separate from a management reserve. Fifth, show three scenarios plus “do nothing”, and assign each benefit to a named owner. Sixth, ask for a staged decision: discovery first, then a minimum version, then full scope.
If you need to narrow the range before a board meeting or an RFP, see how we work in custom software development, or book a call. Discovery takes one to two weeks and ends with a scope, an architecture and an estimate you can take to the board.