(draft)
There has been a lot of chatter recently about rebooting GDS (Government Digital Service). Don't get me wrong, GDS has made mistakes but some were actually my fault. I made a terrible assumption in writing the "Better for Less" paper to do with mapping and how much people were aware of it. In hindsight, I should have pushed mapping into that paper rather than leave it as background noise.
So, in order to avoid making this mistake again, I want to extend this question of rebooting GDS and tackle the scenario of you're newly minted CxO (CIO, CEO et al) or Dept Head or - it doesn't really matter.
The first thing you're probably going to feel is a bit of panic. Who put me in charge? I know there is the temptation to stamp your mark on organisation, to create that strategy which will propel the company to fortune but I'm going to ask you to hold your horses. The Titanic might be sinking and we've got to plug the massive great big hole before messing around with the deckchairs or plotting a new course.
To begin this journey, I'm going to introduce you to the strategy cycle (figure 1). It's fairly simple :-
1) Have a purpose, a moral imperative.
2) Observe the landscape you're operating in and the climatic patterns that impact it (in terms of business we call these economic patterns). These patterns are useful for anticipation of change.
3) Orient your organisation around the landscape using basic principles (known as doctrine).
4) Decide where you're going to play, game the landscape to your favour and act. This is collectively known as leadership.
5) It's a cycle - every time you or anyone else acts it can change your purpose, the landscape, where you need to act etc.
I'm going to assume you don't have a map of your business landscape. You might have things like business process maps, systems maps, mind maps and a host of other things called maps but none of these actually are maps. The odds are, you're blind to the environment. But that's ok, so is almost everyone else.
When it comes to using the strategy cycle then is these early stages we're going to skip climatic patterns, anticipation, gameplay, leadership and all that good stuff. Instead, we're going to focus on doctrine and how to stop the organisation from actively harming itself. We're going to plug the Titanic! We're just going to loop around adding doctrine.
Now, there are forty patterns that make up doctrine. These are all universally useful to any organisation but not all doctrine is made the same i.e. some is more important than others. Hence, I've provided a phased implementation of doctrine and we're going to start with principles in phase I (marked in blue). These principles are challenge assumption, know your users and know your user needs.
But how to introduce challenge in the organisation? Doesn't challenge already exist? Why challenge?
Ok, for most organisations you have endless lists of committees - global architecture group, business strategy forum, policy committees etc. They are generally full of well meaning people but there's usually not a lot of actual challenging going on and communication is nearly always suboptimal. If the organisation is of any size it'll have lots of waste, failed efforts, bias and duplication but no-one can really tell you how bad the problem is. When most CxOs stumble on this, they often want to take stock.
Taking stock of a large estate (whether IT or otherwise) is usually a pretty daunting task and the problem we're trying to solve is not "what we have" but "don't do silly things". Hence we really don't need to know how much waste we have, we just want less of it. To solve this we're going to introduce a group which will become a future bedrock of strategy in the organisation. That group is Spend Control.
The beach-head of Challenge
The purpose of spend control is simply to challenge what we're doing. It's important to remember that it doesn't control the budgets. Those budgets belong to other departments. Spend control simply says that if we're going to spend more than £25K on something then that has to be presented us and exposed to a bit of challenge. To begin with, spend control should simply ask - who are the users, what are their needs and by what metric will we measure those needs?
You can even reinforce this by going around leaving posters of "What is the User Need?" or sticking it on the back of your phone as per Liam Maxwell (former UK Gov CTO)
Who are the users, what are their needs and by what metric will we measure those needs - surely everyone does this? You'd be surprised. Last time I counted, less than 20% of organisation could clearly identify their users and far less could describe their users needs. You might be lucky and be in one of those exceptional organisations but chance are, you're not.
So, how does spend control work? Well, a project owner turns up at spend control with a project that they've got budget to spend £100K on. Spend control asks who are the users, what are their needs and how we will measure this? The response can often be "I don't have a clue, it's only a £100K".
Well, spend control's job is to ask the project owner to find out. But remember, the project owner is also the budget holder and so they can simply ignore spend control on the grounds that "It's a waste of my time". You'd be amazed at how many people try to get exceptions to spend control because they're too important to be challenged on basic questions.
Let us assume the project owner does the work anyway. They might be successful but the problem for the project owner is should something go wrong then there is paper trail that they refused to ask the most basic of questions. This is the other side of challenge - you need to ask the questions and audit what happened. Now, what is happening here is spend control is not only building up a picture of things we might be doing (the projects coming into spend control), the users we serve, their needs and how we measure success but it's also building up a picture of which project owners listen, accept the challenge, succeed in projects and also understand their users. This is all good stuff.
At some point, maybe six months or a year into the process, then spend control needs to have a showdown with one of those failing project owners. You need to emphasise that people can't keep on just doing stuff without understanding the users, their needs and some basic metrics to measure against. This showdown is rarely comfortable but you need to push for no exceptions to the idea of being challenged. Once you're there, the beach-head of challenge has been established then we can start to ramp things up.
Introducing Awareness.
At this stage, we going to extend spend control to ask more questions. We're going to go beyond just simply users and their needs but start to look at what is needed to build a project. I've highlighted the extended set of phase I doctrine that we're going after in blue.
The first thing spend control is going to ask people for is a map. This is a fairly simple exercise, you simply start with the users, their needs and then work out the components involved in making that happen. You do this through a chain of needs i.e. this needs that which needs that etc. The tricky bit with a map is you ask people to also put down how evolved the components are. There's an entire book on this, so I won't repeat that here. I've provided a very simple map for a tea shop.
The point of the map is we can challenge more i.e. there's a lot of components missing from this map for a tea shop from chairs to sit on to a method of taking payment. By sharing a map with others we can often find basic things that have been missed. We can also challenge in terms of what we're doing i.e. why are we custom building kettles?
These maps are in fact maps of capital (with flows and stocks). So we can add metrics to the map. Each line is a bidirectional exchange of capital i.e. the user gets a physical flow (the cup of tea) in return for a financial flow (money to pay for the cup of tea). The capital itself can be physical, financial, social, risk, information ... all sorts of things and yes we can build P&Ls from this.
The point is, we're now asking who are the users, what are their needs, how will we measure this, what components are involved, where is the money going and challenging across the lot. As we get more maps, we can even discover duplication between maps i.e. we're building the same thing twice. The worst I've found in Government is 118 times. The worst I've found in the private sector is a Finance company that has managed to rebuild the same thing over 1,000 times. Do remember, it's not because people are daft but because of suboptimal communication. People just don't realise they are doing this.
Let us repeat those steps just to be clear.
Step 1 - Focus on the user needs which means you also need to identify the users.
Step 2 -
Know the details i.e. what is involved in building the thing. This allows others to challenge, find missing components and create a common image which can be communicated with others.
Step 3 - Reduce duplication. When we have several maps then we usually start finding duplication rather rapidly. In general, I hold a view based upon experience that over 90% of the P&L of most organisations is waste. It's a far bigger problem than people realise and I'm genuinely surprised by organisations that have any sort of handle on this problem.
Step 4 - Reduce bias. I can't tell you the number of times I've come across organisations custom building what is a commodity because it's so common that it is normal. I've had people looking to invest in robotics (with lovely business cases provided to show an ROI for the capital investment within 12 months) to improve the efficiency of some workflow for a problem that only occurs because they're custom building something which is a commodity. In this case, the item was custom built racks, the problem was standard servers didn't fit into their custom built racks requiring people to remove cases, drill holes and add new plates. The "proposed solution" was to replace people with robots. The actual solution was to stop making custom built racks and start using standard racks. This sort of stuff is very common.
Hence, use the maps to challenge and question - why are we custom building this thing?
At this point, you want to give the changes another six months or a year to bake into the process. Spend control should be challenging across a much broader spectrum of things from the user needs, to the components involved, to duplication, to bias and where we're spending money. The process of making a map is fairly quick - a few hours or so - but expect more resistance. Everyone likes to talk about the importance of challenge but no-one actually likes to be challenged. Expect lots of demands for exceptions and why this is too complex to go through the process and a host of other excuses.
Don't get disheartened. In some cases, spend control will be able to really help others by showing them that what they're building is also being built by others. This will enable people to focus their efforts on stuff that matters, to get rid of the common (the boring) or even identify opportunities across multiple maps for building common services. But there will always be those who think they're too important. Just remember to record the advice given, those who ignored and what the end result of the project was. Build that evidence base. I'm afraid you'll probably need a few more confrontations with failed projects before it becomes accepted that challenge is not a bad idea.
What is also happening behind the scenes is you're also now building a view of the landscape you're competing in. All those maps are connected, part of a wider landscape and you're starting to get a view of this and your estate.
Finishing Phase I
At this stage, whilst things should be getting better, you're still going to have oodles of failed projects. You need to have built that evidence base and trust before you really embark on this part of the journey which is all about completing phase I (highlighted in blue).
To begin with, we going to have to start breaking down projects. Just because we have a map, doesn't stop people trying to build the entire map in some Death Star like project outsourced to their friendly SI. You'll need to introduce ideas like FIRE (Fast, Inexpensive, Restrained and Elegant - see Lt Col Dan Ward) and constraints. What we need to do is break things up.
Step 5 - break into small contracts.
The usual resistance to this is because it makes the landscape more complex as I've got multiple contracts now and interfaces between them. Please note the interfaces already existed and no amount of pretending they don't by trying to hide it in a big contract is going to make them go away. But breaking into small contracts is vitally important because it means we can now apply appropriate methods.
Step 6 - apply appropriate methods.
You might not be aware of this but there is no magic one size fits all method for project management anymore than there is for purchasing. You need to apply multiple methods at the same time. Hence you'll tend to outsource those more industrialised components on the right whilst building in-house with agile techniques those uncharted and uncertain components on the left. You'll also use different purchasing mechanisms.
The overwhelming majority of large scale failures that I see come from misapplication of techniques and almost all of them can be anticipated before the project has even started. Typically, we'd take a project like the one above and outsource it all in one big contract. To mimic this, I've just marked all the "mini contracts" as outsource. Now the components on the left hand side are uncharted i.e. novel, new and changing. We can't actually specify them because they constantly change. Hence sticking them in a contract with components that can be specified always ends up with excessive change control cost overruns. People argue that next time we need to specify it better but you can't. The solution is to use appropriate methods.
Step 7 - Learn about context i.e. what works where.
Helping and advising project owners on how to manage their environment is where spend control can truly shine. At this stage spend control will already be on the path to becoming the intelligence function that every organisation needs. But let us not get carried away with the future. At this stage you've completed all the doctrine in phase I and should be embedding that into the organisation through spend control. You're challenging across multiple aspects from the user, user needs, components, how we treat them, where we spend money etc. All the time you're learning about the environment and what methods work where, removing duplication and bias and hopefully becoming fitter and leaner.
You should be a couple of years into your journey. We've still several more phases of doctrine to go and we're years away from creating adaptive cell based organisational structure that use multiple cultures to cope with evolution (see below) but we're better than we were. We're also a good 5-10 years away from being able to effectively anticipate change, to use maps to target the landscape and to start learning how to manipulate the market and write strategy.
At the beginning, I did say hold your horses on organisational change and strategy because the honest truth is most people haven't got a clue how to do this - it's pretty much all random, blind luck, memes picked out of the air. The reason why you felt panic is because you didn't know what to do. The good news is, most executives don't either.
Rather than blindly stumbling around, it's far better that we've made our first steps and mapping is itself a journey. You will eventually get to the point that you can play those more advanced games but let us get these basics sorted first. As a a rule of thumb in the private sector, by the time you complete the first phase of doctrine then you should probably set a stretch target of demonstrably reducing waste in the P&L to about 50% or below i.e. less than 50% of the P&L expense is waste. Obviously, some players are already far better than others. In Gov, there tends to be less waste because there are pre-existing mechanisms of challenge such as the MPA, NAO and PAC but even in such spaces, it's more than possible to save billions.
When it comes to the original question of rebooting GDS, I can't emphasise enough the importance of focusing and doubling down on spend control.
