↑ ↓ selectEnter openEsc close

    The whole guide for printing: vyvoj.solutia.cz/en/guide/print

    Part I The decision: does it make sense?

    Chapter 5: Will it pay off? The business case

    ~14 min readUpdated Lukáš Mikula (opens in a new window)

    On average, large IT projects deliver 56% less value than they promised McKinsey and Oxford, 2012. Moreover, the actual benefit is often not measured, because the goals were only phrased as “improving conditions.” A good business case compares the project with the “do nothing” option, quantifies the benefits in money, and sets 3–5 metrics with a baseline. And it has a single owner who is responsible for the benefits, also after launch.

    Benefits are overestimated more than costs

    The costs of large IT projects overrun the plan by 45% on average, while benefits fall short by 56% McKinsey and Oxford, 2012. The weakest part of a business case can therefore be the very benefits meant to justify the investment. For each benefit, write down who will measure it, how, and when. The calculation should use the total costs over 5 years from chapter 4, not the contract price. Otherwise, your payback period will come out years shorter than it really is.

    A goal you cannot measure is not a goal

    “Modernize and streamline our processes” sounds good, but you will never find out whether it worked. “Cut application processing time from 12 to 5 days by the end of 2027” is something you can measure. Set 3–5 metrics, and for each one state:

    • the baseline value today (measure it before development starts),
    • the target value and date,
    • who measures it and where the data comes from.

    Judge success by the metric values after 6 and 12 months of operation, not just by whether you launched the system on time.

    Digitalization of the state without measurable goals (NKÚ 2026)

    In 2020–2024, the state spent over CZK 50 billion on digitalization, yet only 18% of services are fully online (1,621 of 8,916). The Supreme Audit Office (NKÚ) assigned 87 audit findings to the “unmet objectives” barrier. Goals were often phrased as “creating conditions” without measurable indicators, so the benefit could not be verified. For eJustice, the Ministry of Justice met 2 of 20 goals NKÚ, 2026. The lesson: the money gets spent, but without metrics nobody can say what it produced.

    Source: NKÚ, 2nd summary report on digitalization, 2026

    Five types of benefits and how to calculate them

    • Time saved: number of people × hours saved per week × number of working weeks × hourly cost. Count only part of the result as a benefit. Not every hour saved turns into other useful work.
    • Fewer errors: number of errors per year × cost of one error (correction, complaint, fine) × expected reduction.
    • Higher revenue: additional sales × margin, not total sales.
    • Lower risk: probability of an event × its impact × how much the system reduces it.
    • Legislation: the cost of the cheapest alternative way to meet the obligation. Not the amount of the fine.

    Example: 20 people each save 2 hours a week. With a gross salary of CZK 80,000, an hour of work costs the employer about CZK 670 (salary × 1.338 for contributions, divided by 160 hours). Over 46 working weeks, that comes to CZK 1.23 million, and if only half of the time saved can be put to use, roughly CZK 615,000 a year. That is a number you can take to the finance director.

    Add the savings from the old solution: licenses, support, and operations that will really go away. Then ask the key question: does the project pay off even if the benefits are halved and the costs are a quarter higher? If so, you have a strong business case.

    Calculator

    Will it pay off? Even in a worse case?

    Start with an example, or enter the costs and benefits in money. The calculator works out the payback and shows how the pessimistic scenario turns out: benefits halved, costs a quarter higher. Amounts exclude VAT.

    Example projects (illustrative values, not real projects)

    Costs (excluding VAT)
    Everything you pay before the system goes into service: the development price, a contingency for uncertainty, data migration, training, and your people’s time. Ideally the “acquisition” value from the calculator in chapter 4.

    Development, contingency, data migration, your people’s time.

    What the system costs every year after launch: maintenance, further development, hosting, licenses, and internal administration. Ideally the average annual cost from the calculator in chapter 4.

    From the calculator in chapter 4, not just the support price.

    Benefit: time saved
    How many people will work with the system and save time as a result. Count only those for whom you really expect savings.
    How many hours a week one person saves, for example because they no longer have to retype data or search for information. Ideally, measure how long the task takes today.
    The average gross salary of these people. The calculator adds employer contributions (33.8%) and divides by 160 hours to find what one hour of work costs the organization.

    One hour then costs the organization salary × 1.338 / 160 hours.

    The weeks people actually work: 52 weeks minus vacation, public holidays, and sick leave. Usually around 46.
    The share of saved time people actually use for other useful work. Without a clear plan for what they will do instead, count on half or less.

    Not every hour saved turns into useful work.

    Other annual benefits
    How many errors, complaints, or corrections per year you handle today in the process the system will change. For example, incorrectly entered invoices or lost applications.
    What one error costs you on average: time to fix it, complaints, a discount to the customer, or a penalty.

    Correction, complaint, penalty.

    The share of errors the system eliminates, for example through input validation or automatic data transfer. Be realistic; not all errors will disappear.
    Other annual benefits in money: higher revenue (revenue increase × margin, not total revenue), lower risk (probability × impact × how much the system reduces it), or meeting a legal obligation (the cost of the cheapest other way to meet it).

    Revenue increase × margin, lower risk, legislation (cheapest alternative way to comply).

    What you stop paying for today’s solution: licenses, support, server operations. Count only costs that will really go away after launch.

    Licenses, support, and operations that will really go away.

    Total annual benefits CZK 615,000 (time saved CZK 615,000, errors CZK 0, other CZK 0).

    Will it pay off?

    It pays off only if the benefits materialize in full. In the pessimistic scenario, it does not pay back within 5 years.

    Base scenario

    benefits and costs as you entered them

    Payback

    4.6 years

    pays back within 5 years

    Net benefit over 5 years
    CZK 145,000
    ROI over 5 years
    6%

    Pessimistic scenario

    benefits −50%, costs +25%

    Payback

    No payback

    not even within 30 years

    Net benefit over 5 years
    CZK −1.9 million
    ROI over 5 years
    −58%

    The base scenario assumes a benefit of CZK 615,000 per year (half in year 1), running costs of CZK 225,000 per year, and an investment of CZK 1.5 million.

    Without JavaScript, we show the calculation with the prefilled values.

    Cumulative net benefit by year (payback = crossing zero)
    • Base scenario
    • Pessimistic scenario
    Chart as a table
    Cumulative net benefit by year (benefits − running costs − investment)
    YearBase scenarioPessimistic scenario
    InvestmentCZK −1.5 millionCZK −1.88 million
    Year 1CZK −1.42 millionCZK −2 million
    Year 2CZK −1.03 millionCZK −1.98 million
    Year 3CZK −636,000CZK −1.95 million
    Year 4CZK −246,000CZK −1.92 million
    Year 5CZK 145,000CZK −1.9 million

    How we calculate: time saved = people × hours per week × weeks × hourly cost × utilization rate; fewer errors = number × cost per error × reduction. Each year = benefits − running costs (optionally only half of the benefits in year 1). Payback = when the sum of annual results equals the investment. ROI = (benefits over 5 years − costs over 5 years) / costs.

    The pessimistic scenario reflects the experience that large IT projects deliver on average 56% less value than promised McKinsey and Oxford, 2012. The example projects are illustrative: the benefit of the small application is the example from the chapter text, while its investment and running costs are made up; the costs of the mid-sized and large systems match the examples of the calculator in chapter 4, and their benefits are made up for illustration. A 50% utilization rate and half of the benefits in year 1 are rules of thumb. No discounting.

    Always compare with the “do nothing” option

    Keeping the current state also costs money. The old system ages, its support gets more expensive, and outages loom. At the Ministry of Foreign Affairs (MZV), for example, the cost of supporting the old system rose from CZK 1.2 million to CZK 15.3 million a year NKÚ, audit conclusion KZ 24/26 (chapter 4). Without putting a number on the do-nothing option, you cannot judge whether the change pays off. So compare three options: keep the current state, buy or customize an off-the-shelf solution, and develop custom software (chapter 2).

    A business case is not a one-off document. After discovery and after the first stage, you will know more. Recalculate it at both points. Submit every reduction in scope for approval again, together with its impact on the benefits. Otherwise the project may stay within budget but fail to serve its purpose.

    Who is responsible for the benefits

    A single sponsor from the business should be responsible for the benefits, also after launch. Do not shift this responsibility to the head of IT or to the vendor. The benefits are estimated and signed off by the process owner on your side.

    The decision to continue should not rest only with the person who pushed the project through. A classic experiment showed that the most money is added to a failing choice by people who are personally responsible for the original decision Staw, 1976. So separate the person who runs the project from the person who assesses its status, and agree on stop criteria in advance.

    Escalation of commitment: the more money and reputation have already gone into a project, the harder it is to stop. Decide based on criteria written down in advance, not on how much the project has already cost.

    More in chapter 25: The human factor

    Template

    One-page business caseFill it in before the project is approved, and recalculate it after discovery and after the first stage.
    ONE-PAGE BUSINESS CASE
    Project: …
    Date and version: …
    
    1. PROBLEM
    What does not work today, whose work it complicates, and how we know (data, not impressions):
    …
    
    2. GOAL AND METRICS (3–5)
    Metric | Today | Target | By when | Who measures | Data source
    Example: Time to process an application | 12 days | 5 days | 12/2027 | head of department | timestamps in the system
    …
    
    3. OPTIONS
    A) Do nothing: what it costs us to keep the current state (support, licenses, risks, outages)
    B) Buy or customize an off-the-shelf solution
    C) Build custom software
    
    4. BENEFITS IN CZK PER YEAR
    Time saved: …
    Fewer errors: …
    Higher revenue: …
    Lower risk: …
    Legal compliance (cheapest alternative way to comply): …
    
    5. COSTS
    Total costs over 5 years (acquisition, operations, maintenance, further development, internal time): …
    
    6. RETURN ON INVESTMENT
    Payback period: …
    Does it pay off even with half the benefits? yes / no
    
    7. RISKS AND ASSUMPTIONS
    What must hold for the benefits to materialize (people learn the system, the process changes, the data is of good quality):
    …
    
    8. WHO IS RESPONSIBLE
    Sponsor (responsible for benefits, also after launch): …
    Product owner (decides on scope): …
    Who independently assesses project status: …
    
    9. STOP CRITERIA (agreed in advance)
    E.g.: if after discovery the costs come out more than 50% above the approved budget, we go back for approval.
    …
    
    10. WHEN WE RECALCULATE
    After discovery · after the first stage · 6 and 12 months after launch
    
    FOR PUBLIC AUTHORITIES, ADD
    Link to the information strategy · 3E (sound financial management) · cost-benefit analysis (CBA) · source of funding · OHA opinion yes/no
    How it goes wrongHow to do it right
    How it goes wrongGoal: “modernize and streamline our processes.”How to do it rightGoal: “cut application processing time from 12 to 5 days by the end of 2027.”
    How it goes wrongThe vendor estimates the benefits in its proposal.How to do it rightThe process owner on your side estimates and signs off the benefits.
    How it goes wrongOnly “new system or nothing” is compared, without the cost of doing nothing.How to do it rightThree options, including the cost of keeping the current state.
    How it goes wrongCosts = contract price.How to do it rightCosts over 5 years, including operations, further development, and internal time.
    How it goes wrongScope gets cut, but the benefits in the presentation stay the same.How to do it rightAfter every cut, the benefits are recalculated and approved again.
    How it goes wrongThe project is assessed by the person running it.How to do it rightStatus is assessed by someone independent; stop criteria are agreed in advance.

    Questions

    Questions for the vendor

    1. What benefits did you measure on similar projects, and how?
    2. Which of our goals can be measured directly in the system (processing times, error counts), and which do we have to measure ourselves?
    3. Which features are key to the benefits, and which could be postponed without losing benefit?
    4. What data do you need so that we can measure the baseline before development starts?
    5. What would happen if we postponed the project by a year?
    • Until December 31, 2026, the obligation to demonstrate effectiveness, economy, and efficiency (3E) is set by Act No. 320/2001 Coll., on Financial Control.
    • From January 1, 2027, it is replaced by Act No. 231/2025 Coll., on Management and Control of Public Finances. Its principle of sound financial management (Section 3) contains the same 3E: public funds must be handled effectively, economically, and efficiently Act No. 231/2025 Coll.. A business case built according to this chapter holds up under both acts.
    • Ministry of Finance methodological guideline CHJ No. 3 (version 3.0 of September 1, 2026) is already based on the new act and assesses economy over the whole lifecycle MF, guideline CHJ No. 3, 2026.
    • Effectiveness metrics and a cost-benefit analysis (CBA) serve as a basis for audits, including audits by NKÚ. For goals without indicators, NKÚ states that the benefit cannot be verified.
    • For projects financed from EU funds, failing to meet goals risks a reduction of the grant. For eISIR, the managing authority of the Integrated Regional Operational Programme (IROP) withdrew almost half of the allocation NKÚ, 2026.

    Solutia video