Pipelines

Ah, the annual business planning exercise. An art installation in the creative use of numbers.

Organisations for the most part will go through such extended periods of financial contemplation every year, often about six months before a new financial year begins.

Everyone guesses some numbers using intuition, past performance and the game that is “How much do I need so how much do I put in for before it gets cut back to what I need”. Then some machinations happen and some people end up happy and others less so.

Of all of the processes involved in the running of a business, these kinds of exercises are the ones that have huge risks of clashing most violently with concepts of agile, iterative delivery. The idea of accurately forecasting capital investments work item by work item seems, well, just not very helpful, when it comes to iterative change projects.

So this year I’m trying something a bit different.

For the work that fits into the Known Problems/Known Solutions category, other than not being able to account for skyrocketing inflation, budgeting for things like SAN upgrades or network improvements in our offices to account for new patterns of work will work as usual. I can budget there for what we think we will need to pay for “stuff”.

But for the Known Problems/Unknown Solutions category, I’m instead taking an approach that talks in terms of change pipeline capacity, not specific projects with specific deliverables.

It starts with what we know already about the capacity we need to run iterative change sprints from what we have seen so far this year. A sprint needs a project manager, a business analyst and a service designer. It will also need a bit of a technical architect and a bit of a data architect. All those people sit in my team and can be costed out appropriately.

A sprint will also require involvement from people at one or more of our technology partners. And crucially, it will involve the equivalent of two people full time from various parts of the organisation, which in turn will require their jobs to be somehow backfilled.

My hunch at the moment is that as a relatively small organisation, the tightest bottleneck we have is the ability to release such subject matter experts, but without them you have technology happening to, rather than with an organisation, and change is thin if not non-existent.

We have a backlog of things to do, to each of which we have assigned a number of sprints. It’s a finger in the air stuff, but the volume of work far outstrips what I think is our maximum sprint throughput for the year.

So my budget for the year then becomes stated in terms of concurrent sprints, with options left open as to how many to have, and which things the sprints work on. Because you’ll obviously decide at the time.

What I hope this balances off is a rigorous understanding of what our costs might be for the year ahead, but without setting false expectations in stone as to what specific things will actually happen. In a way, it turns capital projects into a more operational capability, which I guess is something to which DevOps points. Our FD is happy so far, but we’ll see how it fares during the process.