From HS2 to China and … back again.
There has been a lot of gnashing of teeth recently over the Government decision to involve Huawei in 5G and China’s National Rail company in HS2 (High Speed Rail) with endless concerns over human rights, exploitation of labour and security. There are many subjects being muddled together here, so let us start by unpacking this all. First up, HS2 and the question of outsourcing.
HS2 and Outsourcing.
James Findlay was the former CIO of HS2 and he had a problem. In order to reduce the risks of HS2, a decision was taken to build the entire railroad in a virtual world, a sort of early “digital twin” circa 2012. It turns out, it’s cheaper to dig up a virtual world and go — “whoops” — than it is the English countryside. The problem James faced was how to build this?
This was 2012 and there were two competing camps in UK Government over building stuff. One camp was the more traditional led approach of “outsource” everything. The second camp was the “agile” brigade of GDS (Government Digital Services). The question for James was what should he use?
In figure 1, I’ve provided a systems diagram for the virtual world of HS2 to which I’ve applied the traditional approach (popular in Government at that time) of “outsource it all”. I’ve also added two other methods in the legend :-
- a more agile approach as per lightweight XP — eXtreme programming — in the original Kent Beck style.
- a Lean approach i.e. more SCRUM with the use of MVP — minimal viable product — and other artefacts.
I’d like you to spend a bit of time thinking about where you might apply those alternative approaches in the systems diagram. Don’t spend too long, as there are about 300 million permutations of that question in this simple diagram alone.
Figure 1 — Virtual World Systems Diagram
Whatever you choose — you might have gone with the “outsource it all” approach or decided to add a bit of XP here or Lean there — the next thing you need to do is break up the system into contracts or lots.
So, that’s what I’ve done using fairly typically groupings around common themes giving “lots” of user experience, engineering, back office and infrastructure. Each lot we will put out to tender as a contract. This is shown in figure 2.
Figure 2 — Virtual World Contract Structure.
This is a fairly simple example but it should be obvious that such a contract structure would be an utter disaster. I however, want you to explain why it would be a disaster.
To help :-
- put the contracts in order of which would be high risk (almost certain to cause a massive change control cost overrun) to which is most likely to be successfully delivered.
- have a go at re-organising the contracts and methods into something that is likely to work rather than something that is guaranteed to fail.
Give yourself ten minutes.
… (ten minutes later)
Ok, this was a fairly obvious example and so the contracts in most flawed order are :-
- Lot 1 (Engineering) — top of the pile, almost certainly guaranteed to fail with huge cost overruns compared to contract price.
- Lot 3 (Back Office) & Lot 2 (User experience) — both with flaws of which the Back Office lot is the more serious.
- Lot 4 (Infrastructure) which is the one contract which is likely to work
It is therefore obvious from the systems diagram that by re-organsing the contracts and applying appropriate methods then we can make something which is vastly more likely to work, to deliver on time and within budget. This is what I’ve done in figure 3.
Figure 3 — A better contract structure
Easy, isn’t it?
No?
It is therefore obvious that?
Ok, I lied. Like all great maths textbooks I’ve taken one set of equations, added the line “It is therefore obvious that” and jumped to an end result leaving the reader floundering with the question “How did we go from here to there?”
The answer is — it’s not obvious that. It takes a few minutes work if you know what you’re doing but most people haven’t got a clue when it comes to contracts. So, I better break this down for you.
The first problem we have is that we’re trying to work on a systems diagram. These are hopeless for contracts. You need to turn the systems diagram into a map (which is what James did back in 2012). I’ve provided a map of the systems diagram (shown above) in figure 4. If you don’t know how to map or what a map is, there’s an entire free book to help you get started.
Figure 4 — Virtual World Map.
Now, one of the things you learn with maps is that one size fits all methods don’t work. For example, an Agile (as in lightweight XP like approach) works best in one area of the map whereas Six Sigma works best in another. This is shown in figure 5 and applied this basic pattern to our Virtual World Map in figure 6.
Figure 5 — Where methods work
Figure 6 — Virtual World Map with Methods
Do you remember I said there was 300 million permutations of the methods in the system diagram? Well, in a map you can seriously cut that number down. Some permutations just won’t work i.e. trying to six sigma the creation of the novel and new. Ok, we might argue over whether one component should use a specific method or not but using a map we can quickly come to a common understanding. This is not so easy to achieve in the world of stories where every disagreement is a fight with the storyteller and becomes highly political.
At this point, someone normally says “We can use Agile everywhere”. Well, not you can’t and you never could except in glossy Management Consultant hokum and vendor brochures. Each method (Agile, Lean, Six Sigma) is and has evolved to be really good in managing one area of the map. As the thing (whatever we’re looking) at evolves then you’ll need to use a different approach — see figure 7.
Figure 7 — Evolving methods have a space.
To explain the issue we need to turn to a bit of social practice theory (Elizabeth Shove). The complication is the “evolving thing” has a common meaning i.e. computer, risk management or teleportation but it also has three different material instances of the same. For example, the early days of custom built compute which evolved to compute as a product (servers) and eventually compute as a utility. The material instances are not the same despite the common meaning.
The methods also have a common meaning i.e. project management but three different competencies. Each competency works well for one material instance — see figure 8.
Figure 8 — One competency, one instance
This, of course, doesn’t stop people trying and failing to make the all singing, all dancing magic WAGILESIGMALEAN method which works everywhere but doesn’t. Looking at you SAFe … muppets.
Ok, so let us take our proposed contract structure from figure 2 and put it into mapping form. I’ve done this in figure 9. Now, look at Lot 1. You’ve got a single contract spanning multiple domains of evolution where different methods should be applied and you’re using a one size fits all? It doesn’t get much worse that that.
Figure 9 — Systems diagram contract converted to map.
In that one contract, because we’re going to try and specify stuff that needs to change, I can guarantee you will have massive cost overruns due to change control. I can even tell you what will happen as the vendor gets to blame you for constantly changing your mind and not knowing what you wanted whist pointing to examples of where the contract worked because you “specified it correctly” — see figure 10.
Figure 10 — What will happen in Lot 1.
Beyond the disaster of optimising process flow (another post, for another day) then totally barfed contract structure is one of the most common causes of failure I see. Oh, and that flawed construct structure can be determined before the project has even started. Most projects set off on a course of failure which is totally avoidable.
So, how did we get to the “obvious” systems diagram that corrected the problem? That’s simply a matter of grouping together common elements in mapping form — see figure 11 -and then translating back to the systems diagram — see figure 12 (the same as the above).
Figure 11 — A better contract structure in maps
Figure 12 — The better contract map converted to systems diagram form.
Now, without the map, then you have no hope of getting this right or probably even getting close to right without a serious amount of luck. Failure should be expected.
Outsourcing Failures
Generally, when it comes to outsourcing then I get exposed to an endless parade of pathetic excuses :-
- “lack of business alignment” is a common excuse in environments which don’t even know their user needs
- “poor specification” another favourite of those oblivious to evolution and how you can’t specify certain components
- “big projects always fail” is a stalwart of those who don’t understand maps, don’t understand evolution, don’t understand how to apply multiple methods and have a history of constant failure.
Oh, the list goes on. There is, of course, no reason why your project should set off on a voyage of the damned. It’s trivial to fix and this is fifteen year old stuff — focus on user needs, understand the components involved, map it, apply multiple methods to the map and then break down into small contracts.
So, what happened to HS2 and the virtual world? Well, James eventually ended up being praised by a public accounts committee for delivery ahead of schedule and under budget. Unfortunately, a few new Chief Execs later and James has moved on (to doing great stuff with RNLI et al) and the skill has probably been lost in HS2. So, expect lots of failure and falling back to type of trying to outsource stuff you shouldn’t.
Which brings us to …
China
So, we shouldn’t outsource it all to China?
First of all, the maps above are very trivial examples of understanding contract structure and methods — something that any decent executive should be able to do in their sleep. That many can’t is a big issue especially as we’re now going to need to go up a gear and talk nation state. Let me re-emphasise this point because many who can’t even do the most basic of basic things want to dive into national gameplay where they can add their “glorious” strategy through the power of stories. It’s a farce.
I’ve long been a watcher of China, in particular I’ve been mapping out numerous industrial value chains and comparing how China plays the game to the rest of the world. The level of strategic play by China Government is both exceptional and consistent. If you take something like the automotive value chain, map it forward in time (mapping is used in forecasting) and apply China’s gameplay to it — see figure 12 — then it has a ruthlessly efficient process of industrialising spaces by creating special economic zones with small starts-up playing a game of last man standing before being pushed to an international stage. China constantly climbs the value chain on the industrialised side of the map.
Figure 12 — China, Gameplay and Automotive
The Chinese Government acts as the world’s largest Venture Capital firm and there’s only one Western organisation that I’m aware of which is in its league of play and that’s Amazon — something which the US and EU are desperately trying to find reasons to break up. It’s not a question of whether we should outsource this or that, it’s more a question of China Gov plays Chess whilst most Western organisations are still struggling with Snap …. oooh, they’ve got a bit of AI maybe we should have some AI too … SNAP!
China is a real headache for many in the political space who want to push either their laissez faire or centrally planned style agendas. China has learned to use both approaches which have their context — blame Deng Xiaoping. It’s no different from project methods, a common meaning of “economic system” but multiple competencies i.e. it’s the same one competency, one instance and the answer is not laissez faire versus centrally planned but the use of both — see figure 13.
Figure 13 — Applying multiple economic methods to a landscape.
This many method approach has numerous impacts not least of which is in the commercial world as it undermines the ability of companies to rent extract and forces progress. Ever wondered why China storms ahead in networks whilst UK lags with copper wire? Unfortunately, if you’re in the US then this sort of conversation will make little sense to economists as there seems to be a severely distorted view on economic models. It’s a far easier conversation in Europe.
Figure 14 — Economists and Economic thought
Bringing it all together
There are few legitimate reasons why a project such as HS2 should suffer massive cost overruns. Unfortunately the mechanisms we use to manage such projects almost certainly guarantee this will happen. In the West we tend to lack the executive skill to effectively manage complex and complicated environments from project to a policy level. The same does not hold true of China and the rise of China is through its Governments deliberate understanding and exploitation of the landscape to its favour.
Should we undertake HS2? Yes. There are many reasons from the development of capabilities to capacity issues that would encourage us to do so. However, we almost certainly lack the skills in the West to effectively do this. Which is why we should work with China National Rail and more importantly — to learn from them.
Should we work with China? Of course. Our executives need to learn from China. Despite the often racist rhetoric that it’s all down to cheap labour — the reality is China just plays a far better game. Our executives are generally not up to this level of play as Cummings pointed out in his Odyssean Education. We have plenty of core skills (and a fairly solid but unequal education system) but our weakness is in our executive layer. That we need to fix quickly.
What about the US? Well, the UK is going to have a torrid time from the US (and also from the EU) over its own industry in these spaces. The European Commission in particular is having one of those senior moments — its new grand plan is AI. Previously the grand plan was on Cloud (failed), before that was Search (failed), before that … you get the picture. But wait, isn’t China using such grand plans? Yes, but China Gov has a history of targeting the right spaces with methods that work. The methodology used by the EC seems to be re-active and lobbyist driven rather than targeted.
Boris (or maybe its Cummings) focus on the UK as more of a global trading partner positioned between the US and China seems to be about the right place. I would also suggest a strengthening of relations with Iran but that’s another post, another day.
On Politics and Bias
I’m old Labour — more red than red, more blue than blue — which is basically a hair breadth away from One Nation Tory. When it comes to Boris, I’m yet undecided. There’s a history of being questionable with the truth (i.e. is this just rhetoric) but there has been some interesting action — nationalisation of Northern rail, focus on building relationships with China, a lot of emphasis on One Nation and a more “global” outlook. Where will it go? We shall have to wait and see. I’m certainly not discouraged but then I’m not enthusiastic either.
The only thing I would suggest is learn from China, take that road of the Government as a Venture Capitalist, up your game play (i.e start to learn about your landscape) and remember — One Nation is about the entire nation and that means everyone. To quote Disraeli
There is no subject in which I have taken a deeper interest than the condition of the working classes. Long before what is called the ‘condition of the people question’ was discussed in the House of Commons, I had employed my pen on the subject. I had long been aware that there was something rotten in the core of our social system. I had seen that while immense fortunes were accumulating, while wealth was increasing to a superabundance, and while Great Britain was cited throughout Europe as the most prosperous nation in the world, the working classes, the creators of wealth, were steeped in the most abject poverty and gradually sinking into the deepest degradation.
Oh, and before anyone asks which candidate I will be voting for in the Labour Leadership elections — well, Rebecca Long-Bailey. But, then again, Lisa Nandy. Oh, I haven’t quite decided as both are very strong.
