Finance rarely rejects a digitization project because it is too expensive. More often the request is rejected because nobody can say what the money buys, what is not included, and what happens in the second year. A short budget with clear lines answers these questions before they are asked.
This article is for the head of operations or finance who has to put a number next to a digitization project and defend it. It is about the structure of the budget, not about prices. Your own quotes and your own hours are the only numbers that count.
Four lines are enough
Most process digitization projects can be described with four cost lines:
- Work. The time of people who design, build or configure the solution, test it and move the data. Count internal hours as well as supplier hours. Internal time is not free; it is time taken from other tasks.
- Licences and tools. Subscriptions, per-user fees, hosting and any one-off purchase. Note whether the price depends on the number of users or on volume.
- Training and change. Time for people to learn the new way of working, short guides, and a period when the old and new ways run side by side.
- Running costs. Support, updates, small changes, monitoring and the part-time attention of a named owner. This line repeats every year.
If a cost does not fit any of the four, it probably belongs to a different project. Write it down separately instead of hiding it in the total.
Fill each line with a method, not a guess
For each line, write the method next to the number. This makes the budget easy to check and easy to change.
- Work: list the main steps (describe the process, set up the tool, connect it to other systems, test, migrate data) and estimate hours for each. Multiply by an hourly cost your finance team already uses.
- Licences: take the price from a quote or a public price list and multiply by the number of users or the expected volume. Write the date of the quote.
- Training: number of people times hours of training, plus the extra time the first weeks of use take. Be honest that early use is slower.
- Running costs: a share of the build cost is a common starting point, but a better one is a list of recurring tasks with the hours each needs. See what to budget in years two to five of custom software for how to think about this line.
A worked structure with placeholders
Here is how a one-page budget can look. The letters stand for your own figures.
| Line | Method | First year | Every following year |
|---|---|---|---|
| Work | hours per step times hourly cost | A | small changes only |
| Licences and tools | quote times users | B | B |
| Training and change | people times hours | C | little or none |
| Running costs | recurring tasks times hours | D | D |
| Total | A + B + C + D | B + D (+ changes) |
The useful result is the last column. A project with a low first-year cost and a high yearly cost can be more expensive over three years than one with the opposite shape. Finance will see this quickly, so show it first.
Give a range and write the assumptions
A single figure sounds precise but is usually wrong. Give a low and a high estimate for each line and list the two or three assumptions that move the result most, for example "the number of users stays below the current level" or "data can be imported without manual clean-up". If an assumption fails, everyone knows which line to revisit.
Add a small reserve for the parts you cannot see yet. Say openly that it is a reserve and what it is for, so that it is not mistaken for padding.
Compare with the process as it is today
A budget alone says what you will spend. Finance also needs to see what you spend now. Use the method in the cost of one manual process, calculated in one hour to estimate the current yearly cost of the manual process, including rework and waiting. Put the two totals side by side. If the digital process is not cheaper, say what you gain instead: fewer errors, faster answers or less dependence on one person. Do not turn those into invented savings.
How to present it to finance
Keep the conversation short and prepared:
- Start with the decision you need and the total over three years.
- Show the four lines on one page, with the method for each.
- Name what is not included, such as changes to neighbouring systems.
- Say who owns the running costs after the project ends.
- Propose a review date, for example after six months, when you compare the real figures with the plan.
Finance usually accepts a range with honest assumptions more readily than a precise number that later turns out to be wrong.
What to do this week
Take one process you are considering for digitization. Write the four lines on a single page and put a method next to each, even if the numbers are rough. Then ask someone from finance to read it and mark every line they would challenge. If you are still choosing which process to start with, score the candidates by hours, errors and owner before you budget.
Sources
- Our related articles linked above.
- The four-line structure and the presentation steps are a general working approach, not a standard; adapt them to your own company. The letters in the table are placeholders. No figures or client results are claimed in this article.
