# How to justify a technology investment to your board > Boards don't reject technology, they reject risk nobody sized. How to build a case that starts from the cost of the problem and gets approved in phases. - Author: Marlon Trettin - Published: 2026-07-28 · Updated: 2026-08-29 - Language: en - Canonical: https://yowpi.com/en/blog/justify-technology-investment-to-the-board --- To justify a technology investment to your board, start from the cost of the current problem, measured with the department that suffers it, and present the project as a portfolio of bets with phases and continuation conditions. Boards do not reject technology. They reject risk nobody sized. ## TL;DR - The business case that gets approved starts with a baseline: what the problem costs today, with a number validated by whoever operates the process. - [Gartner](https://www.gartner.com/en/newsroom/press-releases/2026-03-24-gartner-says-cfos-need-to-rethink-the-roi-of-ai-investments) warns that treating technology as a single ROI calculation is a mistake. Each type of initiative has its own economics and needs its own measuring stick. - Phased approval, with a written continuation condition, cuts perceived risk. Boards approve more readily what they can stop. - The measurement work itself often reveals that part of the problem needs a fixed process, not new technology. Bringing that finding along strengthens the case. ## Why is your board sceptical about technology projects? Because recent history gives them reason. Budgets keep rising while measured outcomes do not follow, and anyone sitting on a board has watched that arithmetic up close: the budget was approved, the software arrived, the metric did not move. A board's "no" is rarely about the technology itself. It is about the memory of earlier proposals that promised transformation and delivered an idle license. The scepticism is not irrational; it is priced experience. That changes the job of whoever is proposing. The path stops being "sell it better" and becomes "prove this proposal has the architecture the previous ones lacked". ## Where does an approvable business case start? With the cost of the problem, not the benefit of the tool. Before talking about a system, measure what the current situation costs: hours spent on rework, errors that turn into returns, delays that make customers walk away, decisions stalled waiting on a report. That number is the baseline, and it changes the nature of the conversation. Without it, the board compares the investment against zero. With it, they compare the investment against the cost of carrying on. Three things decide that number's credibility. First, it has to be conservative; a case that only closes on optimistic assumptions is a case that does not close. Second, the total project cost goes in whole: license, implementation, integration with what exists, maintenance and your own team's hours. Third, the person who validates the measurement is the process owner, not the person proposing the project. When the sales director confirms in the meeting that his team loses 30 hours a week retyping orders, the discussion shifts from "what does the tool cost" to "what does carrying on cost". That measurement work usually reveals something else: part of the problem does not need new technology, it needs a fixed process. Bringing that finding along strengthens the proposal, because it shows you are not asking for budget by reflex. ## How do you present the investment without making it a single bet? By separating the bets by nature. In March 2026, [Gartner noted](https://www.gartner.com/en/newsroom/press-releases/2026-03-24-gartner-says-cfos-need-to-rethink-the-roi-of-ai-investments) that CFOs err by treating AI investments as a single ROI problem, when in practice they are a portfolio of bets with very different economics: routine automations with fast, measurable returns, process improvements with medium-term returns, and transformational bets carrying high risk. Each has its own cost and timeline, and needs a different measuring stick. The reasoning holds for technology in general, not only AI. In the board presentation, that becomes structure. Instead of a closed 18-month package, a portfolio with declared layers: what is a productivity gain returning in months, what is process improvement returning in quarters, what is a bet with acknowledged risk. The board can approve the first two layers and defer the third without killing the whole project. And each layer advances in phases with a written continuation condition: phase 1 has a fixed scope, a defined metric and a decision date; phase 2 only starts if the metric hits the agreed number. [Repap On's document management system](/en/cases/repap-on) shows what sits at the other end of that path: a platform large corporations use to control critical documents. Structures of that size are not born from a single approval, they grow out of a sequence of deliveries that worked. The effect in the room is concrete. A request that carries its own stopping condition is a request that treats the company's money with the same care the board does. ## An example of a phased proposal A hypothetical scenario, built on patterns we meet often. A distributor turning over roughly USD 25 million a year takes orders by messaging app, email and phone. Three people in sales spend part of the day retyping those orders into the ERP, and typing errors generate returns. The innovation manager measures before proposing: around 30 hours a week of retyping, plus the cost of error-driven returns. Validated with the sales director, the problem costs somewhere near USD 8,000 a month between hours and losses, on a conservative estimate. The proposal reaches the board in two phases. Phase 1: a single order intake channel integrated with the ERP, 12 weeks, with two agreed metrics — retyping hours and error rate. Phase 2: a self-service portal for the largest customers, conditional on phase 1's result. The board is not approving an 18-month transformation. It is approving 12 weeks with a clear ruler and the right to stop. That is a different size of decision, and it is why the answer tends to be yes. ## Frequently asked questions **I can't justify the investment right now. What should I do?** Then do not propose it right now. Measure. Establishing the cost of the problem consumes almost no budget and turns the wait into preparation: when the budget window opens, the case is already built, with a baseline and departmental validation. And if the measurement shows the problem costs little, you have just discovered the project did not deserve approval. That is a result too. **How do I measure the result when the gain looks diffuse?** A diffuse gain is usually a symptom of a missing baseline. Define two or three metrics before implementing anything, and define them on the process, not the tool: hours per task, error rate, cycle time. [Gartner observes](https://www.gartner.com/en/newsroom/press-releases/2026-03-24-gartner-says-cfos-need-to-rethink-the-roi-of-ai-investments) that part of the value appears before the financial result, in better decisions and adaptive capacity. Report the two planes separately: what has already become cash, and what is still capability built. **Will the implementation take too much of my team's time?** It will take time, and an honest business case declares that cost instead of hiding it in the footnotes. The way to limit the load is the same thing that unlocks the approval: short phases with fixed scope, involving few people at a time. Systems designed around the people who operate them, like [Reatop's environmental management system](/en/cases/reatop), start from that constraint: field routine cannot stop to accommodate a tool. The alternative, implementing everything at once, is what consumes the team for months and feeds the board's next refusal. ## The problem is rarely the budget When a technology proposal dies at board level, the cause is usually in the proposal: with no baseline and no exit condition, it asks the board to approve a risk nobody sized. You do not have a budget problem. You have a decision architecture problem. Build the case on the measured cost of the problem, separate the bets, and give the board control over each stage. The yes is closer than it looks. If you want a technical counterpart to review that architecture before you take the case to the board, the Operational Architecture Diagnostic is a 30-minute conversation to map the problem and the path: [talk to Yowpi](/en/contact).