Field notes
This is not about budgeting. It is a deliberate attempt, at an early stage, to put an order of magnitude on the initiative's effect over the first three years, in the form of changed revenue and changed costs, so that the conversation can be about orders of magnitude rather than detailed guesses.
Revenue/cost is of course not always the deciding factor for whether an initiative should go ahead or not, but it is, just like many of the other aspects here, an important thing to describe for the sake of all stakeholders.
We recommend focusing on margin revenue. There are other value dimensions, but often the margin revenue alone is enough to justify a software initiative, and it is usually a good direction to start exploring. (The exception is for example public-authority systems, where the revenue dimension is often missing entirely.)
Beyond three different margin-revenue curves, we also try to capture other kinds of value with one more curve: more a build-up of future value than a cash flow. It can be used for example for goodwill and/or the valuation of the organisation.
The margin cost can be described in two main ways:
It is usually good to start with "Pay per use", since it gathers cost information from the Teams and Operations tabs. That information can then be used as input if you would rather land on a "fixed cost" instead.1
Again: we recommend focusing primarily on increased revenue, but there can of course be effects from internal efficiency gains too. For example, it may let further hires be postponed until revenue has grown more.
If the margin revenue does not require much material and logistics, the margin profit is usually very high. Most of the costs have already been taken (apart from the software initiative, which is part of the calculation). Then for example 80 % margin profit is nothing strange.
The first diagram, which shows the total effect, is inspired by Goldratt's Throughput accounting. Broadly speaking, the focus is on throughput (revenue), while investment (and inventory) should be avoided. When the S-curve kicks in and the margin revenue rises sharply, a large gap also opens up between the revenue curve and the direct costs. That gap is the profit.
The calculations for revenue, costs and effect are deliberately very simple, but hopefully the model quickly gives a first sense of scale that leads to new questions to think further about and analyse more deeply.
Finally, a roll-up is shown of:
If the initiative is of the Delivery type, warnings are also shown here for decisions expected to have a negative impact on future changeability.
1 Note that "pay per use" assumes that people in teams are billed 10 months per year, while infrastructure runs every month.