First, my biases.
1) I'm one of the co-authors of the Better for Less paper which had some influence in the change of Government post 2010.
2) Though I'm certainly not a co-author, I had a minor input into the Boiling Frogs paper. It's a wonderful paper that should rightfully influence many in Government and Business.
Behind these papers exist concepts such as the necessity for iterative processes, to treat things as they are, to focus on user needs and to start small.
3) I'm a supporter of GDS. That does not mean I blindly support them, I have taken issues with the tyranny of agile. However, the work that has been done over the last five years is remarkable.
So, to say that I'm seething at the rumoured changes to break up GDS is an underestimate. I do hope Bryan is wrong on these rumours. Now, to be clear - I am all for reducing GDS over time by enabling departments to provide services but Government is not ready to do this now.
In 2013, I wrote a paper for the Cabinet Office (called Governance of Technology Change) on how to organise, structure and ultimately distribute services. It was based on iterative principles, focused on user needs and started small. I believe it spent the next couple of years gathering dust. However, I'm going to go through a few of the basic elements in that paper and explain how I think it should be done. The paper contained a number of basic forms of doctrine, derived from the problem of how to continuously manage an evolving landscape. I've picked a few :-
User needs
The governance system must clearly reflect user needs in all its decision-making processes. The users include not only departmental users but also the wider public who will interact with any services provided. It is essential, therefore, that those users needs are determined at the outset, represented in the creation of any proposal and any expected outcomes of any proposal are set against those needs.
Coordination
The governance system must provide a mechanism for coordination and engagement across groups including departments and spend control.
Shared learning
The governance system must provide a mechanism of shared learning – for example, discovery and dissemination of examples of good practice.
Context
The governance system must accept that there are currently no single methods of management that are suitable for all environments. Hence a mechanism of describing the context of any proposal is required (for example, one appropriate technique is mapping) which allows for the use of multiple methods and techniques (for example, Agile, Lean and Six Sigma according to where each is appropriate).
This requires situational awareness.
Structure
Within the paper, a structure was derived to apply the doctrine. This structure is shown in figure 1. Now it looks complex but actually, it is rather simple - OCTO (Office of the CTO), IT Supply, Departments, Capability, Decision and Security. We will ignore Decision and Security for this post.
Figure 1 - The structure (with focus and capabilities)
*The above is a simplified view of the structure used, removing the subgroups into capability of a group
Any new project or request to spend significant sums across government first goes to OCTO (spend control). Each request is accompanied with a map of the landscape that is being changed. The first purpose of creating a map is to demonstrate that the department understands what is being built.
Any new project or request to spend significant sums across government first goes to OCTO (spend control). Each request is accompanied with a map of the landscape that is being changed. The first purpose of creating a map is to demonstrate that the department understands what is being built.
The request is examined by spend control (to show compliance to policy) but analysed through an analysis group (also part of OCTO). What we're looking for is areas to challenge, duplication, bias and points of learning in the map. In your typical private company of any size, duplication is rife due to a lack of communication mechanisms. I regularly find hundreds of different groups building the same thing in a single company despite endless committees on architecture and project inventories. If you don't have a mechanism for understanding your landscape then don't be surprised if most of your IT expenditure is duplicated waste.
To begin with, OCTO starts with a single map. You have little information to challenge the request other than to question whether the department is treating activities in the right way or complying to policy.
Figure 2 - First Map.
However, add a few more maps for other requests and then you'll quickly start to discover a common language and duplication between the maps (shown as green dots in figure 3).
Figure 3 - later maps.
Keep on adding maps and you start to build a profile for the landscape. You can start to see how much duplication you have, where you have bias (people custom building that which is commodity) and where items exist that are suitable for provision as common services (i.e. repeated and commodity like).
Figure 4 - Profile
Within OCTO, the co-ordination capability (your internal consultancy) can respond to the department either advising them to use components from another department or a common service or challenging how the project is being built or how to comply with a general policy. OCTO is not only your learning function but enabler. It does so in an iterative manner, improving its understanding of the landscape with each request (and map). Since each map starts with user needs this also reinforces the doctrine of user need throughout Government.
When we spot potential common services this is passed to the IT supply group. This group ensures delivery of common services and provides a registry of common services online throughout Government (G-Cloud, the Ebay of Government services would be ideal). The actual delivery itself maybe by a department (if it has the capability to build a cross governmental service) or an external source (e.g. AWS) or purpose built by its own capability i.e. GDS. Hence bit by bit we cut out the duplication and build a platform of discrete Government services across all of Government. NB. I use the word platform in the sense of a collection of small and discrete Government services (i.e. payment, identity) and not in the sense of a consultant led orgy to build a new Death Star or a coding platform.
There is also a strategy function because the more maps you have, the easier it becomes to exploit the landscape, open source the right components in order to change the environment and anticipate change through weak signals etc. The capability group is involved in developing cell based structures and ensuring we have not only aptitude but the right attitude in place. This is a bit beyond this post other than to say that departments have to demonstrate they have the capability to build the services. This also gives me an opportunity for another gratuitous plug for Boiling Frogs. Please do read that paper.
As I explained in "stopping self harm in corporate IT" the core function of OCTO (and spend control) is learning and hence enabling. Ultimately over time the Departments should be providing services to each other i.e. doing the delivery. This can be achieved in an iterative manner as above. Bit by bit. Service by service. However, to do this in a federated structure you absolutely need a mechanism of communication and learning otherwise you'll just end up (as with most corporates) with hundreds of duplicated examples of the same thing being built. Just ask yourself, how many pet IoT or AI projects doing roughly the same thing are actually going on in your organisation right now? If you're of any size the answer is "you don't know" and from experience, it's going to be vastly more than whatever number you just thought of.
Hence, I'm all for GDS over time becoming distributed with departments providing services. But why not carve up GDS into the departments right now? UK Gov doesn't have the maps, we don't have the analysis functions and we don't have the capability within departments. This isn't the same as saying Departments haven't improved, many have dramatically. You already have examples of emergent behaviours of collaboration between agencies, for example Highways England and High Speed Rail in DfT. However, this is not uniform. Weaken GDS at this time and we are unlikely to achieve our aims but instead lose our centre of gravity, threaten the symbiotic relationship with Old Street (you think it's just coincidence that as Gov improved so did UK tech in London?) and some talent along the way. We run the risk we could well end up in the bad old days of pre 2010 and the only people I can see who would benefit are big consultancy firms and large tech vendors likely to swoop in with their "Let us build a Death Star" mantra.
Hence, I'm all for GDS over time becoming distributed with departments providing services. But why not carve up GDS into the departments right now? UK Gov doesn't have the maps, we don't have the analysis functions and we don't have the capability within departments. This isn't the same as saying Departments haven't improved, many have dramatically. You already have examples of emergent behaviours of collaboration between agencies, for example Highways England and High Speed Rail in DfT. However, this is not uniform. Weaken GDS at this time and we are unlikely to achieve our aims but instead lose our centre of gravity, threaten the symbiotic relationship with Old Street (you think it's just coincidence that as Gov improved so did UK tech in London?) and some talent along the way. We run the risk we could well end up in the bad old days of pre 2010 and the only people I can see who would benefit are big consultancy firms and large tech vendors likely to swoop in with their "Let us build a Death Star" mantra.
This is not progress, this is regression.
If you want to fix this, you need an iterative process and that learning capability. You'll need those maps. Oh, and before you say "we'll get a consultancy to make the maps for us" ... the only people capable of doing this are the Departments themselves and the only people capable of challenging are GDS and OCTO.
Now this was my view from 2013. It hasn't changed since. I certainly cannot agree to carving up GDS now, nor the inevitable hiring of a big "stratchegery" (well, it's never strategy) consultancy firm to advise on the carve up. In my view it's dreadful strategic play (if you're Government) and not how to fix Government IT. I do hope Bryan is wrong on the rumours.
Added 1st August
Asked "Doesn't this take a long time?".
Nope. The problem with most large projects (certainly in the corporate world) is that we usually don't have a clear idea of what is involved. Mapping it out can quickly resolve issues of contract structure, organisation, methodology and purchasing. Mapping itself should be quick and can save time and money. To hear more on this, have a listen to Tony Malone from the Highways England (courtesy of LEF).
One you have a map for a project (as a department), then in the above structure you send it to OCTO. The reason for the co-ordination capability in OCTO is to provide a single point of contact. Analysis of a map, comparison to others and response should happen in the background in a matter of hours. In a well run structure you should be talking hours to map and hours to get a response. Days at a push.
The biggest resistance to mapping is usually that it exposes what is there and the assumptions made. Alas some people just don't like being challenged. But when you're talking tens of millions for a project then being challenged should be the norm.
Added 2nd August
Just as a reminder (as if it really needs to be said) but the mapping method is creative commons share alike. I've put together a list of some useful posts if you need it.
Also, I view Wardley mapping as the equivalent of Babylonian Clay Tablets. Someone will find a better method of mapping that is visual, context specific and has position along with movement.
