A business case that cannot be wrong is not a business case. It is a narrative with numbers attached.
This matters more for a 40-person company than for a large one. A big organisation can absorb a programme that quietly fails. An SME cannot: the same budget was the only budget, and the people who spent six months on the project were not doing their normal jobs.
The test is simple: read the document and ask what observation, twelve months from now, would prove the investment did not work. If no such observation exists, the case has not been made. This article sets out what a usable case commits to, which metrics hold up, how to attribute the result, what the full cost really includes, what payback period is credible, and how the case changes between 20 and 200 people.
What should a business case for digital transformation contain?
A business case for digital transformation should contain four commitments and one honest cost. The commitments are a measured baseline, a single target with a date, an attribution rule written before work starts, and a kill condition that would stop the project. The cost must include your own people's time, not only licences and fees. Anything less describes hopes rather than an investment.
A baseline. The current value of the metric, measured, not estimated. If you cannot measure it today, that is the first piece of work, and it is cheap. Following twenty real orders through the business with a stopwatch, as described in the first 90 days of a digital transformation, is usually enough.
A target and a date. One number, one deadline. "Improve efficiency" is not a target. "Reduce order-to-cash from 43 to 30 days by Q3" is.
An attribution rule. Written before the programme starts: how you will know the change came from this work rather than from seasonality, price changes or headcount.
A kill condition. The observation that would cause you to stop. Programmes with no kill condition do not get stopped; they get renamed.
Which metrics survive contact with reality?
The metrics that survive are the ones already collected for another purpose, because nobody has an incentive to shade them. Order-to-cash days, first-pass yield, cost per transaction, time to close the books and defect escape rate all tend to hold up. They are recorded by finance or production anyway, and someone outside the project will notice if they move the wrong way.
Metrics invented for the programme rarely survive, because the programme owns both the definition and the measurement. "User adoption" and "process maturity score" are the usual examples: easy to improve on paper, and silent about whether the company earns more or spends less.
| Process | Metric that holds up | Where it is already recorded | Common trap |
|---|---|---|---|
| Order handling | Order-to-cash days | Accounting, receivables ledger | Counting from invoice, not from order |
| Production | First-pass yield | Quality records, scrap log | Rework booked as good output |
| Finance | Working days to close | Month-end calendar | Closing early by deferring corrections |
| Sales | Days from request to quote | Email or CRM timestamps | Measuring only the quotes that went well |
| Service | Share of queries answered same day | Ticket or mailbox history | Excluding the hard queries |
Pick one metric per process and keep it for the life of the case. Changing the metric halfway through is the most common way a weak result is disguised as a strong one.
How do you attribute value to a transformation?
Attribute value by using a comparison you decided on before the work started, such as a control site, a control product line or a pre-agreed seasonal adjustment. The method matters less than fixing it in advance. Choosing the attribution rule after seeing the results is how a programme proves whatever it needs to prove, and the owners will rightly discount it.
| Method | Works when | Weakness |
|---|---|---|
| Control site or team | You run two similar sites or teams | Rarely available below 100 people |
| Control product line | Lines share customers and seasonality | Lines influence each other |
| Staggered rollout | The change can go live in waves | Takes longer to reach everyone |
| Before and after, seasonally adjusted | Only one site, stable demand | Weakest; agree the adjustment upfront |
Small companies usually end up with the last row, and that is acceptable if it is honest. Agree in writing how the comparison will treat a price increase, a lost customer or a new hire before any of them happen. The same discipline shows up in forecasting, where it is the difference between a model and a story; see demand forecasting without a data science team.
Where the money actually leaks
Internal time. Almost every case we read counts licences, implementation fees and hardware, and omits the weeks your own people spend in workshops, testing and data cleanup. For a 60-person company that is frequently the largest single line, and leaving it out is what turns a credible eighteen-month payback into a real one of thirty.
Count internal time at a loaded rate. The Federal Statistical Office puts average labour costs across the Swiss economy at CHF 63.62 per hour worked in 2020, of which 79.7% was wages and 17.4% employer social contributions. Three people giving one day a week for six months is 78 days, roughly 620 hours, or about CHF 40,000 at that average, before anyone has paid a supplier. Use your own rates, but put the line in.
There is a structural reason the line is larger in small firms. In 2024 only 14% of small EU enterprises employed an ICT specialist, against 78% of large ones, according to Eurostat. In a company of 40, the testing and data cleanup fall to the operations and finance people, whose normal work does not stop. The data side of that is set out in the five data foundations an SME needs before AI, and the ERP-specific version, where cleanup routinely overruns, is in ERP data migration.
What is a realistic payback period?
In the process-led programmes we have assessed in mid-market industrial and services companies, the first measurable improvement typically lands six to nine months after go-live, and payback takes eighteen to thirty months. Cases promising payback inside a year usually count avoided cost that was never going to be spent. These ranges are typical observations, not commitments, and they depend heavily on scope.
Two public reference points help test a payback claim. The first is the asset's useful life. The Federal Tax Administration's standard depreciation rates allow 40% a year on the book value of data-processing hardware and software, against 30% for production machinery and 8% for factory buildings. The tax authority assumes software loses most of its value within a few years, so a case that needs seven years of benefits to pay back is relying on a system that will probably be replaced first.
The second is how far ahead anyone can plan. SECO's SME portal advises a realistic five-year budget and notes that the second and third years are easier to plan than the fourth and fifth. Treat benefits claimed for years four and five with the same caution, and ask whether the case still works without them.
What a fundable one-pager contains
| Line | Weak version | Fundable version |
|---|---|---|
| Baseline | "Order handling is slow" | "Order-to-cash: 43 days, measured over Q1" |
| Target | "Significant improvement" | "30 days by 30 September" |
| Attribution | "Tracked by the project" | "Compared against the Basel site, unchanged" |
| Kill condition | absent | "Below 38 days by June, or we stop" |
| Cost | Licence only | Licence, configuration, and 0.4 FTE internally |
The right-hand column is not harder to write. It is harder to sign, which is the point: it is the only version that transfers risk to the person proposing the work. The same page is the measure line of a one-page digital strategy, so the strategy and the business case can be reviewed in the same quarterly meeting.
Who should own the number?
The person who owns the process should own the number, not the person running the project. A project manager can report a metric but cannot be accountable for it after go-live, and a metric with no owner three months after go-live usually stops being measured at all. Ownership belongs with whoever lives with the process every week.
In a company without a PMO this is simpler than it sounds. It is usually the person whose week gets worse when the number gets worse. Ask who that is and you have your owner. Most stalled programmes, including the AI pilots described in why AI pilots stall in Swiss companies, fail this test before they fail any technical one.
How does the business case change between 20 and 200 people?
The structure stays the same between 20 and 200 people, but the evidence and the audience change. A 20-person company usually has no control group and decides in one conversation between owners, so a seasonally adjusted before and after with a written kill condition is enough. A 200-person company may have a second site to compare against, a bank or board to convince, and enough volume to measure monthly.
Most Swiss companies sit nearer the small end. The Federal Statistical Office counted 52,476 enterprises with 10 to 49 employees in 2023, against 9,791 with 50 to
- There, the danger is skipping the case entirely because "we all know it needs
doing". Write the page anyway. It takes an afternoon, and it is the only record of what you expected when the result comes in.
At the larger end, the danger is the opposite: a case written to win approval, with benefits from every department added together. Insist on one metric per process and an owner for each. If a benefit has no owner, take it out of the total.
If part of the uncertainty is technical rather than commercial, such as whether a new process or product is feasible at all, a research-backed preliminary study can be cheaper than finding out in production. Innosuisse's innovation cheque funds up to CHF 15,000 of a research partner's costs for Swiss organisations with fewer than 250 full-time employees. It does not pay for software, but it can turn a guess into a number before the main case is written.
Start with the number you already trust
Pick the metric your owners already argue about. Baseline it properly. Commit to a target, a date and a kill condition, and count the internal time. That single page is worth more than a hundred-slide business case, because it can be wrong.
The same discipline applied to the shop floor, where the number is usually equipment effectiveness, is in Industrie 4.0 in Swiss manufacturing. Our digital transformation practice writes the case this way before quoting the work, because a case that cannot be wrong cannot be defended either. For manufacturers and distributors, our industrial page shows where this usually starts, and what a Swiss company should pay for consulting covers how to put outside help into the cost line.
Sources
- Federal Statistical Office (BFS) — Arbeitskosten, labour cost per hour worked and its composition, 2020
- Federal Tax Administration (ESTV) — Merkblatt A 1995: Abschreibungen auf dem Anlagevermögen geschäftlicher Betriebe, standard depreciation rates for direct federal tax
- SECO SME Portal — Investment planning: investing wisely, five-year budgets and monitoring against plan
- Eurostat — ICT specialists: statistics on hard-to-fill vacancies in enterprises, share of enterprises employing ICT specialists by size, 2024
- Federal Statistical Office (BFS) — Kleine und mittlere Unternehmen, enterprises and employment by size class, 2023
- Innosuisse — Innovation cheque, up to CHF 15,000 for a preliminary study with a research partner
Related reading
- Digital transformation for an SME: what to do in the first 90 days
- How to write a digital strategy for an SME: it should fit on one page
- ERP data migration: the part that overruns, and why
- What should a Swiss company actually pay for consulting?
- Digital transformation consulting
Working on this right now?
Tell us where you are in two questions. A consulting partner reviews every enquiry within 2 business days.