BAU doesn’t have to be BAU
I read this tweet this week and instantly felt torn. I agree — but also see most managers in Government trapped between a rock and a hard place. Let me explain.
BAU in many people’s minds is an artificially binary model — it’s either a priority for investment or not; it’s good enough or not; it’s in the change/transformation portfolio or it’s not.
And I can see why many management-types like to think this way. Their money and focus is limited (and, usually, shrinking) — creating a two-tier system and sorting things into hot or not gives them an easy way to decide what to prioritise.
A common basis for categorisation is whether an activity or service will improve an organisation’s top line. For instance, is it a cost driver or profit driver? Lighting — mentioned in Jonny’s example — is the perfect example of something that would and usually should be treated as a cost centre. The business imperative for it is optimising for cost. I don’t want facilities management to be investing large sums of money in iterating our lighting set up — I want it to be good enough. Lighting is BAU.
That said, “good enough” isn’t static. I expect them to maintain the lighting. To make sure it stays safe, replace bulbs, get the data needed to optimise our usage to both reduce costs and our carbon footprint. And I expect them to maintain high observability of lighting as a service: if the usage suddenly goes up, they know why and explore how to respond; if the lights stop meeting our needs (maybe we all need bluer light), they are listening in the right ways to recognise the changing needs and adjust; and if we stop coming into the office, they turn the lights off.
As a facilities manager, though, I’d rightly see lighting as a cost centre. I’d understand my imperative is to have a service that meets user needs while optimising for cost. As it’s a fairly simple, predictable and stable set of needs, I’d be confident specifying and then bearing significant upfront costs for design and install. I’d also expect much, much lower costs going forward, and I’d likely outsource it because lighting isn’t a strategic capability for most firms.
Where your service is a “profit centre”, management calculations are slightly different — because you’re optimising for profit. Or, for outcomes, if you’re in the public sector. You have to figure out where the greatest value lies for your customers and for the business, and invest there. Money is still limited — the firm needs to stay within the bounds of its cashflow to be solvent — so you’re looking to prioritise for return on investment.
The job of identifying where the greatest prospective value lies is a really hard one. If your budgets and focused are limited and shrinking, you have to decide what you will stop doing in order to explore something new. At an organisational level you can decide to decommission a service that is no longer providing enough value to customers or the business. Or you can decide to invest less in existing services — usually by deciding what good enough for now looks like for the services you offer (preferably steered by your product manager).
When a service is currently meeting customer and business needs, has high observability in place and so can know quickly when that changes, and is maintained well, you’ll probably find the running costs of the service are really quite low already. It requires the organisation have good “sensing” functions, but for me this is nonetheless a state of BAU. In the future it might be decommissioned. Or it might need a radical redesign if customer needs change suddenly. But for at least a while the service will stay broadly the same. And as long as you have a solid service manager, they’ll be making sure that the burn rate of the team isn’t outpacing the value that iterations to the service provide.
The critical thing to notice in the necklace diagram above is that there’s no single point at which something becomes BAU. There’s no clear line where a mature service should become a “maintenance” team’s problem. Because BAU isn’t binary. If you’re running a large enough service to merit a permanent full-stack product team then “if you build it, you run it” is definitely the right philosophy to have in place.
If it’s a small service, with a small user base and a small budget, then that approach gets harder to justify financially and inevitably tradeoffs are made. This is where you might see people banding together to keep costs lower using common components, templates and shared platforms. They might use no/low code solutions. They might keep a full team in place but have them covering a number of related services rather than just the one. They’re still optimising for outcomes — they just have less money to invest.
Putting absolute budget limitations aside, most digital teams and leaders I know in government subscribe to that principle of continuous improvement. But few are able to live to that principle, at least not without some creative accounting, because of the massively outdated funding models that force them back to binary thinking.
Designed in the days when IT was mostly end-user compute, connectivity and telephony and mostly outsourced, government accounting practices are probably the single biggest obstacle to treating BAU as continuous improvement. Traditionally we bought IT via capital expenditures, with a predefined allocation of money given over a fixed term and generally multi-year contracts worth millions of pounds. Given the pace of innovation, technology becomes obsolete on such a regular basis that this funding approach — based on confident and accurate prediction of stable needs up front — no longer adds up.
Still the make up of departmental funding allocations is based on the traditional model: tech budgets are largely capital spend. This keeps many service teams suspended in a perennial state of public beta to avoid the death knell that is reclassification as “live”. What these teams need — what the services need — is adequate OpEx funding for BAU.
A rebalancing of departmental capital (CapEx) and operating expenditure (OpEx) is needed to enable longer term commitment to ownership and funding for continuous improvement of mature services.
Well, why don’t you just transfer it over — it’s all taxpayers’ money? I hear you say. Sadly in Government it’s not an easy change to make, and not all funding is created equal.
First, the specific CapEx and OpEx allocations for each department are written into law — and Accounting Officers (usually Permanent Secretaries) typically aren’t willing to go against commitments to Parliament and the Treasury without a really good reason (e.g. a pandemic).
And second, at a Government-wide level, the Treasury can’t allow a wholesale transfer of existing CapEx into OpEx budgets if they’re going to keep their commitment to increase the former whilst reducing the latter by 5% net. While borrowing for capital spend is sellable as investing in the nation’s infrastructure and spurring economic growth, operational spend is seen more as a gauge of the government’s ability to live within its means and so OpEx is where most belt-tightening happens. The result: CapEx is much more readily available in departmental budgets.
So though many teams and leaders subscribe to the principle that BAU should be continuous improvement, service owners will do whatever it takes to avoid their services being classified as BAU while funding rules are this rigid. And thus BAU becomes a shorthand for services that are inflexibly and inadequately funded for continuous improvement.
Without a more flexible mental model for BAU, the unnecessarily binary between “business as usual” and “transformation” forces leaders to choose between forever-beta and what is essentially disinvestment. Those with no choice but to reduce their CapEx end up shuffling the mature services that are delivering their organisation’s strategic outcomes into the same category as the more static, non-core internal services in their cost centres (like lighting).
It doesn’t have to be this way, of course. The Government breaks its own fiscal rules, and finds funding for the things it deems a priority. The Treasury defines the funding allocations and submits the Estimates, and could certainly engineer CapEx>OpEx transfers if it wished. It feels like getting this right is the next big cultural frontier for DigiGov to cross — and very much a hearts and minds challenge. So let’s stay hopeful, keep making the case for change, and work together to build a critical mass of awareness of this knotty but eminently fixable problem among the Whitehall leaders influential enough to force the issue if they wanted.
