Thread by @swardley

Capita wins £1bn NHS contract to oversee administration - ft.com/content/408bcd… ... if we're talking about outsourcing back office services which should be highly standardised across the NHS and industry, this is not necessarily a bad thing. Devil is in the detail.

So, don't just go "outsourcing is bad" ... it depends upon what is being outsourced (i.e. whether it's suitable for being outsourced). If you break an entire system up with a map, this should help you identify what to outsource and what not.

The only "alarming" thing about this tweet -

https://twitter.com/NHSvBrexit/status/1078567744784732160

- is people assume outsourcing per se is bad. It isn't but it can be. I will also ignore that the original FT article is from 2015.

... unless, of course, people want to link this to brexit in which case I will kindly point out that the referenced article comes from before the referendum.

X : But since the contract was in 2015, can't we just learn whether outsourcing works or not?
Me : Without a map?
X : I don't get why a map is important.
Me : Hmmm, ok. Let us try this ...

... let us start with that map (from HS2) where we broke into components and used different methods ...

... it "works" because we learned the following pattern from mapping (through trial and error) that "one size doesn't fit all". Their suitability varies with evolution and hence the context of what you're doing.
X : I still don't see how this helps.

Me : Ok, let's take something which lacks context e.g. a systems diagram and try to answer a question / learn from a scenario. Then let us repeat the exercise with a map and see what happens.
X : Hmmm. I'm still not sure.

Me : Let us pretend we're both working on a self driving car. Now, you're in finance and I'm in engineering. Alas, engineering is a bit "elvish" to people outside of the field (i.e. poorly understood, needs translation) but I want to co-operate with you ...

... so, it's 2015 (same year as the FT article) and I provide you with a systems diagram (has no context) which is all in Elvish. Now I want us to co-operate, work together and so I'll ask a question ...

... should we outsource A and/or B?
X : How am I supposed to answer that.
Me : People get asked to answer things they don't really understand all the time. Have a go.
X : Outsource it all. I'm finance!

Me : Ok, let us suppose we outsource it all. What will happen with those components?
X : Outsourcing fails, it always does.

Me : Well in this case it does. So what have you learned?
X : Outsourcing always fails.
Me : Ok, but you outsource to cloud, outsource power ... it doesn't fail everywhere. Let's roll the clock forward more.

Me : Let us suppose we ask the same question again but it's 2020. Do you outsource?
X : No, outsourcing fails. It failed last time, it'll fail this time.
Me : So, you've just learn outsourcing fails.
X : All the time!
Me : Shall, we try that again ...

... in this repeat of the exercise, I want you to remember that pattern of where methods works well ...

... so now, I'm going to give you a map of the system. Should we outsource A and / or B?
X : Neither!
Me : Why?
X : Because it failed last time.
Me : It's 2015, you don't know that. From the map.
X : You don't outsource genesis / custom built. I get that.

Me : What if a new project manager comes along and says we should outsource it all?
X : Well, I can see some bits you would, others you wouldn't. I get it.
Me : Really? Let's check.

Me : Let us say we outsource it all and A & B fail. What have we learned.
X : That you don't outsource genesis / custom built. That you apply the right methods. I understand.
Me : But wait ...

Me : Let us roll the clock forward to 2020. Should we outsource A and / or B.
X : Well, we should outsource A.
Me : Ah ha. So outsourcing has its place then? If used in the right context?
X : Hmmm.

Me : I'll go back to HS2 example. Outsourcing is valid if used in the right places i.e. industrialised components. The disasters occur (due to excessive change control cost overruns) when you try to use it in inappropriate places, normally because people don't understand context.

... the problems with any outsource arrangement for back office services from the NHS to Capita will likely occur when this includes components that are not industrialised and need changing. Outsourcing without understanding context is a quick way to get fleeced.

X : How many organisations actually break up systems into components with a map and use this to determine what to outsource?
Me : In 13 years of doing this, I'd say .. very few. Which is why epic outsource failures through massive cost overruns are commonplace ...

... mapping a system exposes assumptions, allows others to challenge what is done, forces people to think about context. It's riskier on a personal level and more difficult to manage.

"Outsource the lot" might guarantee failure but on a personal level you can blame the vendor.

... that's what most people fail to understand about outsourcing. It's rarely about trying to do the most effective and inefficient thing. It's more commonly about a manager having "one throat to choke" if things go wrong and that throat not being the manager.

X : I don't understand why genesis / custom built can't be outsourced. It's a matter of getting the specification right.
Me : That's the problem. You can't. Components in that uncharted space will change. You have to learn what you need and you can't specify them ...

... the most cited "learning" from failed outsourcing projects is also the single thing that will guarantee future failure in outsourced project - "next time we need to specify it better".

... what you need to learn is to use appropriate methods. In the uncharted space, you can't write the specification you'll need for an outsourcing arrangement. You need to use methods designed to cope with change ...

... in the industrialised space you can write the specification in incredible detail and know it won't change. This is suited to outsourcing arrangement. Don't mix the uncharted and industrialised in a single contract.

X : If you've been doing this for 13 years, why doesn't everyone?
Me : Most people don't know how to map a business, they don't even know what a map is. These things take time to spread. Don't rush it.
X : Surely vendors would know?
Me : Hmmm ...

... as a vendor, then it might be in my commercial interest to get you to outsource an entire system (from uncharted to industrialised) because I know I'm guaranteed of ...
1) Excess change control costs (i.e. revenue) from changes in specification in the uncharted space
AND ...

2) When it comes to conflict then I can always point to how some components (the industrialised) were delivered well (i.e. we did our job) and the cost overruns are all associated with specification changes (i.e. the uncharted components) and therefore it's the client's fault.

... so despite the client's attempt to avoid risk, I can be pretty much guarantee to make a killing on change control costs and explain to the client how this all occurred due to their choice. If I'm evil, I can even get them chanting "next time we need to specify it better".

X : What about using outcome based models?
Me : Map out the system, break into small components (group them by stages i.e. don't mix uncharted with industrialised) and then learn to apply multiple purchasing methods

X : Outcome based approaches will work everywhere.
Me : Hmmm ... go mix in some Scaled Agile and Spotify with your one size fits all memes that you barely understand. Add in some AI and blockchain for good luck. Come back when you've got burned and are willing to learn.