Thread by @swardley

Almost everything that could be wrong is wrong ( scale, appetite for risk, culture, skills and ICT starting point) with this Socitm view on Outsourcing - blog.socitm.net/2018/07/06/out… (H/T @abesford for spot) ... let me fix this, one final last time, with a decade+ old solution -

Let me start by introducing James (@GoAgileGov) who is a good friend and the former CIO of HS2 (high speed rail). He had a problem, what to do with a particular system for designing railways ...

Should James outsource it all?

Or maybe build with off the shelf products?

Or build in-house with agile techniques?

Or maybe, use all three? Can't be that difficult? There's only 387 million possible permutations ... but which ones are right or close to being right?

Fortunately, James (aka @goagilegov) ... who happens to be a good friend ... knew how to map. So, that's what he did. He mapped the problem ...

... starting with the users (his first maps were paper versions but they didn't take long), James went down the chain of needs mapping over evolution ... this took apparently a quiet few hours in the garden ...

"So what!" I hear you cry. Well, we know that methods are context specific i.e. there is no magic size fits all like "outsourcing"

So, you can now apply your context specific methods to your map ... which is what James did. Now you know where to outsource (the industrialised stuff on the right), where to use agile etc.

You can even turn this back into a systems diagram (ps, they're not maps) if you want ... and voila ... as if by magic the problem is solved. You know which bits to outsource.

But, I hear you cry ... "How do you know those methods are right?" ... well, let us say we outsourced everything ...

Which in mapping terms looks like this ... (single size method used everywhere) ...

... what you will discover is the bits on the right work, the bits on the left fail and incur excessive change control costs ...

... that's because the bits on the left are constantly changing, they are in the uncharted space. Over time (and it can be a long time) they will evolve and move to the right and the more industrialised space ...

... but for now, you can't specify the bits in the uncharted space, you have to experiment which is why you
a) Never use one size fits all ...

... and ...
b) You firmly beat with a feather duster any fool who suggests that the solution is to "specify it better" ... you can't, you never could ...

... but the real beauty of maps, is they are not only a tool to communicate and challenge but also to learn. It's by going back and looking at past maps you learn which methods work where

... and if you really want to scare people with powers of voodoo, you can use your maps to work out what bits will fail due to your one size fits all approach and even convert it to a system diagram ... before they've even started the project.

... of course, using appropriate methods is just one of forty odd basic forms of doctrine that you should know ...

... and doctrine is just one small part of the entire strategy cycle -

You can learn all of this (it's all creative commons) and other magic tricks like ... how to organise yourself, how not to be a silly billy when it comes to strategy etc at medium.com/wardleymaps ... just add your effort.

... or you can continue to repeat the same old howlers, year after year and pay oodles of cash to expensive strategy consultants to teach you nothing useful at all.

This broadcast was brought to you courtesy of 2005. The actual HS2 example was courtesy of 2012 (or thereabouts, ask @GoAgileGov ... I never remember).

As a general rule of thumb, please don't use big words like agile, outsource, strategy, organisation, ecosystem or in fact ... business and anything related to it ... in my presence without a map and some trivial understanding of context and situational awareness ...

... if you do, I will just mock you for being a numpty.