Aspiring for more Fiasco … again

The Times today screamed one of those eye catching headlines - "Whitehall IT Fiasco" - with a fairly detailed dissection of the HMRC Aspire contract. The relished shout of "failure" was only surpassed by the monumental fallacy of "the solutions". I think it's worth exploring why.

Lets start by simply taking the Times and its "experts" views that Aspire is a project that has 'spun out of control' with 'spiralling costs' and is beset by 'previous disasters'. I won't argue whether this is true or not but simply ask the question - why?

IT failure is not an unusual story in both the public and private sector. There is however a common factor at the heart of many of these problematic systems which is best illustrated with a map. Mapping, for those who don't know, is a process of comparing value chain against evolution. In figure 1 I've provided a map from current government system (I've removed the terms describing each component because it isn't relevant). The map is derived from three user needs (components A, B & C).

Figure 1 - A 'Wardley' map

The key thing about mapping a complex environment is it teaches you that ANY complex system contains multiple components at different stages of evolution. For example, in the above map there are 24 different components, some of which are in the 'uncharted' space (3 components - D, E & F) and some are highly 'industrialised' (G to M).

Now, each of those stages of evolution have different characteristics and require different methods to manage. For example, the uncharted space is best suited to in-house development with agile techniques because it's uncertain and it requires experimentation as the requirements are unknown. However the industrialised is best suited to outsourcing to a market with highly structured methods (e.g. six sigma). The industrialised is known, it's defined.

Now, key to mapping is to realise that there is no magic one size fits all method to management. Of course, when it comes to dealing with a complex system then you could decide to apply a one size fits all approach (e.g. agile everywhere or outsource everything) rather than apply appropriate methods to each component.  However, this 'one size fits all' choice normally occurs because no-one has a map and so they don't realise that multiple methods are needed.

Now, a 'one size' can be fairly problematic. For example, suppose we decided to outsource the entire of the system described in figure 1. We are likely to want to implement a contract which describes in detail what we're getting for our money - that sounds perfectly reasonable. The supplier however is likely to implement some process for managing any changes. All very sensible. However, here's the problem. 

If you look at the map, then components D, E and F are all in the uncharted space. This means we don't actually know what we want, those components will change rapidly. But if we've implemented a one size fits all contract across the entire system based upon an idea that we do know what we want, then we're going to get stung with the expensive change control processes for components D, E and F.

To be honest, most vendors seem to know this. The beauty of this approach for them is they profit handsomely from change control and they certainly (as the article points out) have "little incentive to keep fees low for changes". Even better than this, when the customer complains then the vendor gets to blame us for not knowing what we wanted and can get to point to other more industrialised components (those that didn't change such as G to M) as having been efficiently delivered.

It's all our fault! But we couldn't know what we want! We could only know what we wanted with the more evolved, the more industrialised components.  The fault is of course with the process. We should have never outsourced these uncharted components but instead we should have used agile, in-house techniques. By all means, we should outsource the industrialised.

A better way to treat this project is described in figure 2. 

Figure 2 - using multiple methods

However, vendors tend to dislike this concept because they make a fortune on change control processes. In some cases, the effective treatment of a system as components has led to cost reductions of individual components in the order of 99.3% - 99.7%. The sums of money (or profits) involved can be significant.

So, now let us turn to Aspire or what is described as the "country's biggest IT contract … heading for disaster". I can assume (as with most private company projects) that HMRC in the past didn't have a map, which is a pity. I can only guess at that the number of components involved in a complex system like this. So let us say it is 100 - it maybe more, it maybe less. 

Now with no map, I can't tell what components are evolved and what are not. So let's take figure 2 as a benchmark and generalise it for all projects. We know from figure 2, that there are 24 components. In the legend, I've quickly summed up how many of each type exist. About 12% are uncharted and around 42% are highly industrialised with the rest in between. So let's assume this "benchmark" is also true with Aspire … it's not much to go on.

So our guess gives us around 12 uncharted components and 42 industrialised components in our 100 component system. The 12 uncharted components are more in the experimentation phase, more suitable  for in-house, agile development techniques whereas the 42 industrialised components will be suitable for outsourcing to utility providers. The remaining are suitable for products ideally with minimal change. It's worth noting that you can also map data, practices and knowledge along with activities. 

Now, at the moment we can't say (without a proper map) if those figures are even roughly right but we can be pretty certain that Aspire isn't all uncharted and it isn't all industrialised. If you decide to outsource this entire project then you're going to be hit with excessive change control costs because those 12 uncharted components will evolve, they won't stand still and we don't really know what we want. No amount of specification will solve this. We have to (and literally are forced to) experiment. 

Of course, you don't want to run the entire project in an agile manner because at least 42 industrialised components are suitable for high volume, low cost, tightly defined utility like services. 

So lets go back to the Aspire article and look at some points in detail.

1) "it's heading for disaster", "it a fail" … well as the article seem to emphasise it has been a disaster for 20 odd years. There's nothing new here other than practices around how to manage complex projects have significantly changed during that time.

2) "plans to split into 100 parts" … seems to be cited as the problem. But hold on, this system probably contains a 100 different parts. So we want to pretend it doesn't?  Breaking complex systems into relevant components rather than pretending it is one thing doesn't seem a bad idea. We don't build cars by pretending they are one thing, in fact we often have complex supply chains meeting the needs of all the components. Now, we could simply break Aspire into the relevant components and offer one supplier (as we've done in the past) all the components to provide. Ideally you'd use a market but even with a limited choice then the advantage here is we can make sure appropriate methods, measurement and contracts are deployed based upon the component. It might make a little bit more work but we're talking about a project which already has a running cost at over £8 billion and is considered to be 'spiralling out of control'. From Amazon (see two pizza) to USAF (see FIST) to Manufacturing (see the entire industry) then organisations have learned how to manage effectively componentisation with supply chains and they certainly don't find it "too difficult to manage". Why not here? Why not Gov? Treating components appropriately seems to be the sensible thing to do.

3) "It will cause chaos" … cue the old "riots on the street" line.  Given construction, automotive and many other industries have no problem with componentisation and given a worst case of getting one supplier to build all the components with appropriate methods (which they're likely to outsource some of this anyway) then I can't see how we jump to this notion. We've continued to repeat the "one size fits all" approach which has led to countless cost overruns and failures. This seems to be scaremongering and I'm not sure what the objection here is to learning from other industries.

4) "hundreds of experimental startups" - ok, this one is becoming surreal. If you break a complex system into components then you're likely to give a large number of highly industrialised components to established utility providers (e.g. companies like Amazon for infrastructure) but you won't give them all the components because some are going to be experimental (they're uncharted). For these components then you're likely to do this in-house with agile techniques or use a specialist company focused on more agile processes. I'm not sure how the "experts" jump from componentisation (a sensible action) to giving it all to "hundreds of experimental startups". This wreaks of nonsense and a desire to keep the current status quo.

5) "interfaces" - this is where we use appropriate standards. Pretending a complex 100 component system with uncharted and industrialised components that have interfaces between them is in fact one system with a one size fits all method and non existent interfaces is fantasy. Those components are there, same as the interfaces. The complexity doesn't go away simply by "outsourcing". All you've done is try and pretend that the complex thing you're building is somehow simple because then it's easier to manage. It's barking on the delusional and it's extremely poor and dated management. It would be like BMW or Apple outsourcing their entire product lines to someone else and trying to have no involvement because it makes management simple. Whilst some have apparently said that HMRC "doesn't know what it's doing", it has obviously realised that doing the same failed process over and over again won't make things better. Good on HMRC.

6) "more expertise" - let us be clear, so far the "expertise" has managed to create "spiralling", "out of control" projects over a 20 year period. Yes, the project "spiralled out of control partly because of four major renegotiations" and yes, three of those negotiations happened between 2006 to 2009 with some absolute corkers like "granting exclusivity" and costs rising from £1bn to £8.1bn by 2009. It's worth noting that when this all happened was well before any apparent "imposed ban" on management consultants. By the way, the rate of cost growth seems to have dramatically slowed since the supposed ban. 

So, can I check that what we actually need  is more of "spiralling" and "out of control" costs because that's what the "experts" seem to bring or at least the data points to this. I certainly agree that the past vogue of outsourcing had weakened the government ability to negotiate but this is changing (see OCTO, see GDS etc). I can understand why we need to develop skills in contract management and supply chains which seems to be happening as this is a perfectly reasonable thing to do. Other companies have, why not UK Gov?  I'm not sure why we want to take a backward step here.

7) "500 people to manage 100 contracts" - ok, this seems to be one (and there are many) of the most exaggerated claims. I used to work in purchasing, I managed around 100+ different active contracts on a daily basis with over 100 different suppliers buying everything from stationery to missile components to jet fighters. I can sort of see the argument for a team of 25-50 (at a push) but 500. I'm guessing the "experts" would have us outsource that as well, probably employing them into the bargain. 

8) "Labour" - you could point out that such monolithic disasters using inappropriate mechanisms and excessive outsourcing occurred during Labour's reign and even make pointed remarks about Ed Milliband and Ed Balls involvement. Yes, the coalition has been carefully trying to unpick the mess that was created. However, it seems pointless to dwell on the past unless there's some belief that Labour is hell bent on recreating it. I don't believe that's the case, so this is just unhelpful point scoring by the Times. Not needed.

Overall, if the report is correct then yes we seem to have a mess of a project based upon outdated methods of thinking, The problem is that the "experts" then describe the same failed and outdated modes of thinking as some sort of future solution. The article doesn't stand up to scrutiny, you could drive a truck through the gaping holes in this one. 

Yes, some past disasters are bearing fruit and need to be fixed and no, that doesn't involve repeating the same mistakes which made those disasters. As Einstein pointed out, "insanity is doing the same thing over and over again and expecting different results". HMRC seems to be learning that.

But learning is not much of a headline or a doom laden story. Which then begs a question - why was this article really written? 

Well, as the article points out the changes have "created a backlash" and there's been "concerns over the merging of back office systems like HR and payroll". However, the civil servants I've met seem broadly supportive of the changes and understand the need to do so. Government isn't there to waste taxpayers money, it's there to ensure it is wisely spent on things we need.

So, who benefits from encouraging a move back to the past and creating fear, uncertainty and doubt over the current changes and practices? It's worth noting that these change have simplified Government websites, won design awards, led to significant cost savings (National Audit Office) and propelled UK Gov IT from a backwater to a model being copied by other Governments. 

The question you really have to ask is who stands to lose the most by the continued progress and wants to paint a picture of heading towards disaster. There are two fairly obvious candidates and this is the real question that we should be looking into. 

As for HMRC, well problems in IT are not new and it's good to see that changes are being made. Many of the problems of the past are almost certainly due to single size contracts and the "expert" opinion involved. Obviously you're ruffling feathers and that's a good thing. Keep it up.

As for the "experts" - bah humbug. Given the widespread use of componentisation concepts in multiple industries over the last decade then I'd be more inclined to haul these "experts" in front of the Public Accounts Committee and where necessary hunt down those involved in this mess and sue them into oblivion for negligence. As a taxpayer, I save my wraith for them and not HMRC. I fully understand the awful games and exploitation of change control for commercial gain that happens. My preference is to use real experts which Government is already developing in groups like GDS etc.

Good on HMRC, Good on UK Gov IT. Keep going.

---

P.S. For clarity on any bias I might have. Though I'm not an employee of UK Government (either full time or as a contractor), I do spend time at various Government departments teaching them how to map out complex environments along with observing impacts. UK Gov is a member of the private research organisation that I belong to (the LEF) and I'm given considerable freedom by the LEF and UK Gov to observe the changes. I also (many years ago) wrote the 'Better for Less' paper with Liam Maxwell et al. I'm also 'old Labour' and whilst I might strongly disagree with many coalition policies,  I'm highly supportive of the positive changes that I see being led by the Cabinet Office. You'll often hear me saying "Rock on, Francis Maude!" which gives you an idea of both my age and that I can't give two hoots about politics when it comes to having the right person in the right role.