Getting Stuff Done - An Example

I often talk about the abstract because I'm actively involved in playing games between companies. However, some people have asked for a bit more help with the getting stuff done post.

So, this is a simplified example from a TV company that I wrote many many years ago. I'm using an early draft which took about two hours to develop including the strategic play from a base understanding of nothing about the TV industry. I'm choosing this example because whilst it explains the process, it has nothing of commercial value left in it. 

Step 1 - Needs

Critical to mapping is to first focus on the user need (i.e. not your need to make profit but what the user actually needs). In this case, the need was about entertainment during their leisure time. There were two routes to satisfying that need either through "aggregator" services (think NetFlix / Amazon where the output from many studios is combined) and through an own branded service.

Step 2 - Value Chain

Knowing the high level needs is the first step, you now need to flesh this out with the components required to meet those needs. You do this by creating a chain of needs. I call this a value chain as the focus should always be that value can be created by meeting the needs of others.

At the top of the value chain is the visible user need. Below this are the increasingly invisible  (to the user) components that are necessary to meet those needs.

Those components have granularity i.e. you can divide them into many multiple components. For example, a smart phone can be treated as one node or it can be equally broken down into its constituents.  Hence think about the scope of what you're doing. There's little point in immediately diving into the twenty odd sub components of a smart phone if you're examining a railway company.

When we get onto mapping, you can always create sub maps for individual components and explore that part of the value chain. Do remember, all maps are imperfect representations of reality and so don't try creating the perfect value chain ... your map will change and be refined.

Step 3 - Map it.

Value chains on their own are practically useless for strategic play because they lack any form of context on how the environment is changing.  The biggest problem with context is that evolution can't be measured over time i.e. no amount of time based fiddling (diffusion curves, hype cycles etc) is going to help you here.  As uncomfortable as it is, you have to simply accept that you don't have a crystal ball and hence you have to embrace uncertainty. 

The good news is that whilst evolution can't be measured over time, it can be measured over certainty. So, this is exactly what you need to do. Take you value chain and map it with an evolution axis.

Now, all the components in the above map are evolving from left to right due to supply and demand competition. As they evolve their characteristics change from the uncharted (the uncertain, rare and constantly changing) becoming more industrialised (the known, the common, the stable) etc. There are tricks you can use to determine the rate at which things are evolving (this is known as weak signal analysis) but that's beyond the scope of this.

Once you have a map, examine it. In the above, the content of the TV company has a quite interesting distinction between creation and distribution i.e. there is a pipeline of content creation from commissioned shows to acquired formats along with separate distribution mechanisms such as traditional media and internet broadcast.  To make this distinction more visible, you can add a pipeline to the map.

You now have something which you can start to discuss the environment in which a TV company operates.

Step 4) Challenge!

Three of the biggest issues with any organisation are bias, communication and duplication. Invariably when someone in a company tells me they want to build a rules engine, if doesn't take long to discover at least half a dozen other projects building rules engines in the same company. Duplication is rife in most organisations because they usually have no means of communicating within groups what is being done in a consistent form.  Even if you do find the six different groups, they all tend to believe that their rules engine is somehow unique and different from everyone else's. 

One of the beauty of maps is that you can start to build up a portfolio of maps from different parts of the organisation and start to challenge this duplication and bias by sharing. Maps give you the communication mechanism to do this. When you start getting good at this, you can challenge your own maps against the outside market and other competitors.

Assuming you're collecting multiple maps then normally you can find a good chunk of what is being considered is in fact far more industrialised than people realise. This brings up to the next step.

Step 5 - Adjust!

Once you've challenged the map, you should adjust it with the people involved. I've marked this on the map below in red circles. All these components are far more industrialised than the original maps suggests.

Maps are also great for identifying what can be built as common services in an organisation and what can be re-used from elsewhere. Hence use your maps to make agreements between groups i.e. this group will build the rules engine for all the other six groups etc.

To give you an idea of the impact, savings in the order of 90% of the original project / line of business cost are not unheard of. Duplication and bias are horrendously expensive problems which are rife in most organisations but in order to deal with this then you need to identify & challenge the suspect components and then adjust. You can't do this without a communication mechanism such as mapping. Relying on people to simply talk to each in a large organisation is how most companies get into a mess of duplication.

Step 6) Think!

By this stage you should have a reasonable map of the environment, removed much of the duplication and bias and have a clear way of communicating the context to others. This is the stage in which we add a bit of strategy to the conversation. Please try to abolish the word strategy from your lexicon until you get here because strategy without an understanding of the context (i.e. without situational awareness) is pretty much worthless.

The key first step in strategy is to determine WHERE to attack. WHY is a relative statement i.e. why here over there. This is critical to understand because many companies try to determine WHY with no understanding of context, and yes some dive into the HOW, WHAT and WHEN without any understanding of WHY or the more important WHERE. 

Try and discard any images in your mind of chess players in the board room and master strategists running most companies. For the vast majority of competitors that you'll face then strategy is more akin to alchemy, story telling, copying others (backward causality) and gut feel. You should not fear the size of the company and any advantages they might appear to have ... these are often extremely easy to turn.

Now, there is a lot to strategy from anticipation, to competitors, to inertia, to tactical plays, to manipulation of market, to patterns of economic change, to constraints, to ecosystems etc. Maps help you learn what works and what doesn't over time through practice. As with military campaigns, maps are an incredible tool for organisational learning.

The key to their use is to think about the environment (the board), to attempt to manipulate the environment (move pieces) and to practice. Don't worry about being perfect, you'll get better and remember you're normally fighting companies that have little to no idea about the environment. These companies often survive through a mixture of luck and because their own competitors suck. A little bit of situational awareness can do an awful lot of damage in a market.

So, back to our TV company example. There are numerous WHERE's that you could attack. I'm not going to list them all but instead give an example known as Fool's mate. The problem here, is that the TV company has to commission shows from creative studios. There is a limited number of these (a constraint) and hence programs tend to be expensive. What we want to do is drive the creative studios to more of a commodity. Alas, the creative studios will resist this and hence have inertia to such a change (marked as black bar).

Fortunately, creative studios themselves have constraints in terms of production talent and production systems. By driving production systems to more of a commodity (ideally through an open approach) then you can reduce these constraints and encourage more creative studios to form (hence driving creative studios to more of a commodity). The beauty of this approach is that creative studios are likely to support you in your efforts because production systems will be seen as a cost to the business rather than a barrier protecting the business. I say 'likely' because if the creative studios had good situational awareness then they'd see this obvious play coming from a mile off. Chances are they won't, they'll actively support it.

So, in the above you have TWO WHEREs and the WHY now becomes easy to identify. You attack the production systems with an open source effort because this will ultimately commoditise creative studios hence further reducing your programme costs for commissioning and the creative studios are likely to support your effort rather than resist it. This is WHY you attack production system over attacking directly the creative studios.

Now, in the above map there's actually a whole slew of potential points of attacks and some sublime strategic games that can be played. However, it's enough for the moment to simply understand the basics of WHERE and WHY.

Do remember, I've been mapping and playing games based on this for a decade. Pick your targets wisely and as tip, try to go for areas where competitors are likely to show little or no situational awareness. There are certain characteristics I look for including a reliance on specific analyst groups, a tendency to copy others, properties of traditional organisational structures etc. You have nothing to fear and the chances are your competitors will leave you free to manipulate the map in anyway you see fit. 

Do remember the map is an imperfect representation and will evolve itself over time. So, iterate it accordingly and keep track of competitors - they might hit a lucky break. Do also use competitors own inertia against them, there's a delightful beauty in watching a competitor self implode on a trap you've put down for them years before. Misdirection for fun and profit is one of my favourite games.

Step 7) Methods!

Once you have the map and the initial strategic play then you can start to examine how you're going to do this. You'll need multiple methods for any complex business. Remember, as things evolve then their characteristics change and the techniques you need to use will evolve as well.

You could at this point create a map to represent your target operating model (TOM). I've done this below but I wouldn't bother because your map will change with time and competitor moves. TOMs tend to be more wishful thinking and I prefer to keep it adaptive. I've added this graphic to show that you could create a TOM but as far as I'm concerned it's bad practice. Much better to keep it as above with dotted lines showing a direction of travel.

Step 8) Simple!

At this point you can break the map into teams. Do remember FIST (Fast, Inexpensive, Simple and Tiny) principles and use small, self organising teams (ideally less than 12 people) along with small, focused contracts. When it comes to organising then cell based structures are pretty good. I tend to overlay with a Pioneer, Settler and Town Planner structure to cope with changing attitudes (i.e. engineering in the uncharted space is not the same as engineering in the industrialised). 

More recently, I've heard talk about 'new' bimodal structures and two speed IT. I don't have anything kind to say on this topic because these are basically decade old concepts dressed up as new and they create a whole raft of unnecessary problems. In the worst cases they are little more than 'lipstick on a pig'. 

[Optional] Step 9 - Evaluate

At this point, you can go and create any SWOT, Business Model Canvases (BMC), Stories or other evaluation artefacts that you feel are necessary. I happen to like BMC as a quick exercise to cover the play as it helps me usually refine a few more details. This really should be super quick by now, you'll have almost all the information you need. I often skip this or keep it minimal.


Step 10) JFDI

Use Kanban (an excellent scheduling tool) and get on with it. Iterate, this is going to happen a lot in those uncharted spaces as you'll be discovering. Update your maps, often you'll find someone else kicks off a project / line of business you can use or provide services too (assuming you are communicating). Keep those teams small, think starfish model (e.g. Amazon two pizza) and be ready to break down components. Let the team self organise, create their own more detailed maps and use mapping as more of a guide through the entire landscape. Let everyone see the maps, these help give everyone an understanding of what the whole gameplay is and where their part fits into this. Have fun.

The above gives an example of how to go through the process of mapping. Don't spend too much time on this - as I said, the above took less than two hours. A key part of mapping is the sharing of maps with others (part of the whole challenge process) and this usually helps expose the tough questions. Aim to get to that stage as fast as possible. 


Q). How Applicable is mapping?

I've used mapping from the small to moderate (tens of millions of users), from systems to line of business. Bar the absolute trivial, I've yet to find an example where spending a day mapping out an environment before proceeding isn't worth it. On the other hand I've spent weeks writing specifications (wasn't worth it) and started projects without any understanding of the landscape (subsequently discovering half the things we built had been built by others). I've also in the past lived and run one size fits all shops (e.g. six sigma or agile) and learned my lesson.

To give you an example of how ridiculous things can become without mapping :-

I know of one company with at least two different asset management systems with two different groups arguing that their system is essential.

I know of one company which is building an internal enterprise application store. I also happen to know that within that company, they have four different groups building an enterprise application store. I know that one group is working with a SaaS vendor, another is using a proprietary system in production, another is customising an open source system and another has started building from first principles (i.e. coding it from scratch) using an Agile approach. This is one company. The user needs are identical. They have four different implementations of the same thing - all incompatible. What the company does for a living is far removed from the technology industry.

I know of one organisation that has 20 different case management systems. I know they are currently spending in excess of $100M building a new case management system. They will soon have 21 case management systems.

I know of one C Level who has discovered his organisation has over 120 different implementations of the same thing.

I know of one C Level who believes they don't have much duplication in their organisation. I know they have no mechanism of measuring this. They don't even know what they have or what certain things do and why they exist.

Never underestimate the willingness of people to rebuild, re-implement and duplicate the same things over and over again.

Oh, please stop ...

A simple test.

1) Can you describe your user needs for all your lines of business, processes or systems?

2) Can you describe the components that make up those needs and the connections between the components?

3) Do you have some form of mechanism for visualising and communicating this (e.g. a map)?

4) Do you have a means of comparing maps together to remove duplication in the organisation, to challenge bias that exists within group, to help find unmet needs, to combat inertia and to compare with competitors?

5) Do you treat your components individually and understand that one size fits all methods don't work? Do you apply multiple methods? 

6) Do you understand that the components are evolving due to competition and what works today will not be the same tomorrow? Do you understand any map is dynamic and an imperfect representation of reality? Do you understand the very basics of change - componentisation, creative destruction, punctuated equilibrium etc.

7) Do you attempt to alter your map (e.g. use of constraints, opening a field, blocking competition, etc) and observe the impact of what happens?

8) Do you understand what situational awareness is and why it matters?

UNLESS, the answer to all the above is an emphatic YES then please don't waste your time by sending me emails wanting to discuss disruption, ecosystem, platforms, competitive advantage and STRATEGY. These mean different things to you and me.

Instead, if you need help writing your strategy then I've put in considerable effort and prepared you an individual bespoke strategy already in advance.  Just for you - just click this link - and I'll send you on your merry way. Bon Voyage.

PS. If you don't like the strategy, click the link again and it'll magically create you another at no extra charge.

PPS. I have enough to deal with particularly on my latest research project - the clash of nations. There is no shortcut to mapping, you have to learn it and practice. 

Why is mapping more popular in Government than Commercial companies?

I was asked this question and thought I'd better explain some important aspects of mapping. 

First, mapping is about situational awareness and therefore it helps if people have had some military background or experience. Second, I tend to find mapping is more popular in smaller organisations (founder run) and Governments which both need to think about the longer term and strategic play more carefully.

Mapping does take a bit of work and thinking about. Yes, it can remove duplication, fundamentally change the way you play the game but it's not really suited to large commercial organisation. Why?

Well, if you consider that it can take a couple of years to get really good at mapping, collate all the maps needed to enhance your situational awareness and learn to play the game then despite its effectiveness, the timeframe is too long for many large commercial organisations. Execs don't tend to think long term (i.e. > 3 years) as they only expect to be in their position for a short time. I've met many that actively discourage longer term thinking. They often don't give two hoots about survivability of the organisation beyond their term and are instead focused almost exclusively on short term share price fluctuations. This is what they are motivated by and unlike a founder run organisation, there is no legacy or loyalty here. 

What I've often found is that execs are after a quick fix to boost share price which is why copying others / backward causality / cost cutting are so attractive. The last thing they generally want to do is rock the boat, think about the long term or make significant changes which others aren't doing. The market actually discourages people from doing this.

Mapping on the other hand is more about long term sustainability than short term quick fixes. It lacks the simplicity and speed of a SWOT requiring a more dedicated effort to understand user needs, the environment, evolution and how to improve situational awareness. It's therefore not suitable for all organisations.

Maps and the Target Operating Model

I was asked a question about my post on getting stuff done and then noticed a relevant but unrelated tweet by Tom Loosemore

The wonderful @mattedgar unpicks why the phrase 'Target Operating Model' sees me setting my delusion filter to 11 http://t.co/MXO6WP3hRq
— Tom Loosemore (@tomskitomski) January 24, 2015

.... so I thought I'd better answer. Does the map represent your target operating model? No, but not for the reason you might think.

My original post discussed more the process by which you get something started, a key part of which is creating the map to determine, communicate and then challenge what is to be done. One this has been done the map gives you an initial target (see figure 1)

Figure 1 - Initial Target

From the map you have a set of user needs, numerous components to meet those needs (a chain of needs or value chain), a necessity to use multiple methods (due to changing characteristics), a division into small teams, use of components from others, delivery of components to others and a set of strategic plays ... read the original post for details.

Now, a few things are worth noting.

1) The map is imperfect (all maps are). So other components and needs are going to emerge on route.

2) The map is not static. All components evolve due to competition (supply and demand) and hence their characteristics, how you might treat them will change.

3) Others will develop systems which impact your map i.e. provide opportunities for either re-use of their components or supply of your components to them.

The map is a guide not a target operating model because the map is not static. It will change and you will have to adapt as it changes. Maps of a competitive environment are fluid - evolution doesn't stop because you're building a big project. This actually can be extremely useful because you can use timing to assist you. In very long projects, you can de-prioritise selected components for as long as possible to give them the maximum time to evolve to more industrialised (e.g. commodity) forms.

I'm not a fan of the target operating model concept because it implies that a static, steady state can be achieved. That's a rare exception in my view and whenever I have been able to reach it, I've generally found that life has moved on and I need to change again.

How to refer to mapping?

I often get asked what IP exists around the mapping technique that I talk about? Well, it is IP protected under Creative Commons 3.0 Share Alike. This means you are free to use it, free to modify it and free to distribute it as long as you use the same license. I'm not in the business of trying to extract rent from people for drawing maps, I'm in the business of helping others run their organisations more effectively.

This does leave a question of attribution. There are numerous forms that I'm happy with. As long as its similar to this in spirit then I don't grumble.

1) Wardley Mapping

If you call the technique "Wardley Mapping" then this is fine and there's no need to attribute further in presentations and talks. I happen to quite like this term these days to avoid confusion with other 'value chain / stream' mapping techniques that are not equivalent. 

If you want to add a more explicit attribution line (e.g. you're writing an article) then "courtesy of Simon Wardley, CC3.0 by SA" or "courtesy of Simon Wardley (LEF) CC3.0 by SA"  or even a simple "courtesy of Simon Wardley" is appreciated. 

2) Wardley - Duncan Mapping
If you call the technique "Wardley - Duncan Mapping" then this is fine as it pays homage to James A. Duncan who was instrumental in the early stages of mapping. If you want to add a more explicit attribution line then any of the above are fine.

3) Value Chain Mapping 

This is an alternative name of the technique and if you're going to call it this, then ADD an attribution line. Since the LEF does provide me time to promote and teach others how to map, I have a preference for the attribution "courtesy of Simon Wardley (LEF) CC3.0 by SA".

The only thing that will actually annoy me is seeing the technique without any reference to my name. Since, I've put the hard work in over the last decade then I'd be grateful if you could at least mention me when using it.

David Cameron in 'cloud cuckoo land' over plans to deify security services

The prime minister’s pledge to give security services omnipotence is ‘crazy’, experts say. Religious and security specialists have told our gallant reporters that David Cameron is “living in cloud cuckoo land” when he suggests a new Tory government would ascend ordinary intelligence agents to a new pantheon of Gods. 

Independent expert Ive Noclue said: “It’s crazy. Cameron is living in cloud cuckoo land if he thinks that this is a sensible idea, and no it wouldn’t be possible to implement properly. You can't just go around turning ordinary intelligence officers into divine beings and creating a new omnipotent pantheon. This is obviously what the Tories are planning to do and it's not sensible."

Other security experts echo Noclue, describing the approach as “idiocy” and saying Cameron’s plans are “ill-thought out and scary”. The UK’s data watchdog has also spoken out against “knee-jerk reactions”. One expert privately voiced concerns that "Many of today's problems occur from an already diverse pantheon of Gods. Adding more could exacerbate the problem. This Tory policy is just downright wrong. What happens if these new Gods start competing religions? What happens if one of these new Gods decides they're going to change reality or has a bad day and starts lobbing lightning bolts around? The consequences of this should have been thought through".

Meanwhile a start-up has warned on the possible effect on Britain’s nascent technology sector of Cameron’s plans. BurnYourCash has said it is already making plans to leave the UK if the Conservative party is re-elected with this policy of creating new Gods in its programme. 

On Monday, Cameron made a speech in which he decried the ability of ordinary people to have conversations on which the security services were unable to eavesdrop.“In extremis, it has been possible to read someone’s letter, to listen to someone’s call, to mobile communications,” Cameron said. “The question remains: are we going to allow a means of communications where it simply is not possible to do that? My answer to that question is: no, we must not.”

Noclue said "It is obvious from Cameron's statement that he plans to turn ordinary intelligence officers into divine beings giving them omnipotence and impacting the whole religious, social and economic order of the world."

Other experts have thrown cold water on the plans, “Yes you can pass laws in Westminster until you’re blue in the face but it's not practical” said Renta Os, another expert in the field. “Citizens, businesses, and nation states need to protect themselves but creating a whole new pantheon of Gods is just not the answer. Cameron’s plans appear dangerous, ill-thought out and scary."

This new debate has political implications with alternative parties claiming "We will not be making any new Gods as part of our policy programme. That's our pledge to the public. Your Gods are safe in our hands". Our reporters were unable to get a response from the Conservatives, providing further clear evidence of the nefarious plans.

Off the record, one political commentator did state "I don't think Cameron said he was going to create new Gods, did you check the text? I think you're extrapolating wildly. It's about as daft as saying he intends to ban encryption. He didn't say that either."

For more on this breaking story ...

The use of SWOTs in strategy

Two simple graphics ...

SWOT is a useful analysis tool for determining whether a particular or combination of attack / defence points have any potential. In order to understand where you can attack or defend you first need to map the environment, identify likely competitor moves and then determine your options. After this you can apply your SWOTs to evaluate options.

However, once you have determined your most favourable option then you still need to determine whether it is feasible i.e. you need to examine resource requirements, how you're going to achieve this etc.

When developing a business strategy, the order I use is ...

1) Map
2) Determine options (wheres)
3) SWOT each option
4) Determine preferred option (the why as in why here over there)
5) Business Model Canvas on preferred option (feasibility)

I don't see a great deal of point in use in tools like SWOT if you're not going to first map out the landscape.

Getting stuff done

You've been given some project / business line / whatever to examine and get going. How do you start?

The following steps are what I find useful. If you're working in a large organisation then based upon experience, I can confidently state that if you follow the steps you'll be able to reduce costs significantly in the organisation over time (i.e. as ridiculous as this sounds, 90% reductions are not unheard of). You'll more effectively capture markets against competitors, you'll reduce failure, improve communication and you'll increase your speed of delivery.  I don't expect you to believe me and I'm not going to waste my time trying to convince you. Talk it all with a pinch of salt but ... have a go.

This is more of a refinement for those who have already started mapping.

1) Needs!
Start with user needs. Identify what the real user needs are. DON'T start with what your needs (e.g. make profit, be successful) ... start with the end user.

2) Value Chain!
Now work out what components are needed to meet those needs and create a value chain.

3) Map!
Now map it by adding evolution. NB, I use the terms uncharted to industrialised to describe the different areas of the map (the old lingo was chaotic to linear). These different areas have polar opposite properties and everything evolves from one to the other.

4) Challenge!

Now compare your maps to other maps for other projects or lines of business in other departments. Look for the clusters i.e. in the following diagram, the everyone treating the activity in the same way - the red dots - with you standing out on a limb - the green dot. I collate my maps to find common activities in multiple maps and produce the distribution chart shown below. I find this very useful in tackling bias in a group e.g. the insistence that their ERP is a rare and poorly understood activity requiring a custom built system.

Don't skip this step - there's nothing more annoying in a large organisation than to start implementing something like a rules engine and then discover halfway through the process that the organisation has six other rules engines hidden away in different groups. This will help you find who is already building what you need.

Also try and compare your map to how competitors treat actions. If you're really lucky your organisation has some form of intelligence unit that keeps tabs on this and they can do it for you. If your organisation doesn't have multiple maps, well ... that's a pity. You can still challenge by asking questions such as how are we treating this, trying to find areas of efficiency etc. Suggest to your executives it might be a good idea for the company to learn about situational awareness.

5) Adjust!
Now adjust your map accordingly. Many of the things you were planning to build are already built by others (the red dots), so use them. Some of the things you were treating inefficiently, so change it. If you're lucky then some of the components you're going to build can also be provided to others e.g. a more commodity form of an existing act.

If unfortunately you don't have maps of other departments / groups or any intelligence function then you won't know what others are really doing other than by going around and asking people. This is incredibly tedious, so try and encourage them to map in future as it'll help find stuff.

6) Think!
Now add a bit of strategy. Since you can see the environment then you might as well take advantage of it e.g. commoditise some things, create ecosystems, exploit inertia or buyer / supplier relationships, anticipate others moves, try to differentiate, there might be unmet needs ... whatever. Lots and lots to choose from (the wheres).

Try and determine why this route over that. Ideally your organisation will have an overall map with the high level strategy defined. Use this. Look at competitors, what their likely moves are, how you can manipulate the market to your favour. Again, if you don't have an intelligence unit or maps then you're a bit stuck on this. Still, it's better to start somewhere.

Tools like SWOT are perfectly useful for examining an individual where however use the maps and all the different points of attack to determine your overall play.

Once you've worked it out, mark up the map accordingly. This intended strategy needs to be shared with all parts of the organisation as others will be able to take advantage of your moves i.e. your move to build a commodity service might enable another part of the organisation to now build something they need.

7) Methods!
Now you have an idea of where you can attack, why you're going to attack one route over another, what the user needs are, what components are involved, what you already have or already use in the organisation (avoiding duplication), likely competitor moves etc then we can get onto the how. Treat the system as small components, don't try and treat it as one thing by applying single size fits all methods. Remember the characteristics of activity (and practice, data and knowledge) change as they evolve and so multiple methods are needed.

8) Simple!
Now, use those FIST principles (Fast, Inexpensive, Simple and Tiny) to break up the system into small teams. Any time a team looks like it's going to get bigger than twelve people then break it down again.

9) Evaluate!
At this point, you've probably done a lot of work ... maybe as much as a whole day (unless you've had to go around different groups finding out what they're doing because no-one has maps). Give yourself some applause.

You'll understand the landscape, you'll know your user need, you've got an idea of where you can attack, some ideas of potential competitor moves, you've determined why one route (or multiple routes) over another, you've even got an idea of how to build the whole thing without duplicating etc. You're in pretty good shape but you're not done.

Now, you need to determine whether this is financially viable and whether we can play this game. Using the map, estimate some of the costs, determine your business model and fill out a business model canvas or something like it. Most of the information you'll need for this (e.g. key activities, partners, resources, value proposition, potential revenue streams etc) you should have already discovered on the journey to it but give yourself another half day.

At this point, I normally have a map of the environment (possible sub maps), a strategy based on the multiples wheres (with often some supporting SWOTs of individual wheres - many of which get rejected), a business model canvas for my plan of attack and a pretty decent idea of how to play the game. 

Now, if for whatever reason the current approach is not financially viable (e.g. some of the components are too expensive) then you can go back and look at the strategy i.e. maybe we should commoditise those components first or save the play for a later day. Do remember that eventually components will commoditise due to supply and demand competition, hence what is not viable today might become viable tomorrow. The map alone will be useful to other groups, so share it with the rest of the company.

Approval (i.e. any need to gamble investment) is hopefully a relatively quick process given it's easy to challenge a map and you have all the supporting information (e.g. BMC, SWOTs, comparison to competitors etc). Most of the time I've found the usual response to be "this is so obvious why is no-one else doing it?" which brings its own challenge. 

At worst, you should find that you're spending two days on this entire process but remember, those maps aren't wasted effort as others can use them. If you're spending more time than this on getting to an approval state then either :-

a) You lack experience in mapping out environments - that's ok, you'll get quicker. Don't try and create perfect maps, there's no such thing.

b) There's a lack of maps elsewhere i.e. you're spending too much time trying to find out what others are doing. This could add weeks to the process in a large organisation and it's highly inefficient. Try and encourage others to map, it'll help you find the duplicates. One of the worst examples I know is of one organisation with over 120 different implementations of the same thing in different groups / functions and departments. Though, for totality of duplication and uselessness, it is beaten by another that has managed now to reduce their application estate from over 8,000 applications to slightly under 700.  Yes, 87% of the estate was pointless. Of course that was obviously great for vendors and sucked for the company. As a rule of thumb, in any large organisation then I'd ask how many instances of this thing do you know of (e.g. the one you're  planning to build and maybe the one other you know about of the top of your head) and whatever you say, I'd multiply by 10 - there's always vastly more duplication than you realise. 

c) You've no intelligence function and so you're trying to learn basic economic lessons, competitor moves etc. Always a nuisance, this can add further weeks to the process and without maps then you have no way of recording what works and what doesn't. If necessary, set yourself up as the "intelligence" unit and get everyone else to send their maps to you. 

d) Determining strategy is hard - this is normal. Most people have no real experience of strategic play having been bought up in a business world which relies on copying others and little to no situational awareness.  It takes quite a bit of practice to get good at this and certainly if you're playing strategic games at a high level (i.e. overall company strategy on a national scale) then this can take a few days to a week (though that's a bit of overkill). I'm afraid it can take you years to get good but don't panic, you're playing usually against others who have little to know situational awareness hence even basic moves like "fool's mate" work. You've got to start practicing and so this is as good a time as any.

e) The approval process is slow. There's not much excuse for this, ask why?

The other line which comes up is it's complex or the line of business is complex. That's almost always complete gibberish and is more a signal that people don't want to think about it. Mapping tends to expose people to hard questions and that's not always popular.

10) JFDI!
Now, once you get approval then you've got everything you need to form your teams, fill them with the right sort of aptitude and attitudes. Get your teams to put up kanban charts and just get on with it. They should all now understand the landscape, what's available, the strategy, what methods are best suited etc etc.

11) Iterate!
Remember keep an eye on the map, watch for competitor moves, make sure teams are kept small etc etc.

--- tools

The mapping technique is Creative Commons 3.0 Share Alike. If you need a tool to help you map, well ...

a) The LEF (Leading Edge Forum) has a free mapping tool available online. It's not open source yet but that'll be announced soon enough.

b) The Wardley Maps Group has an open source tool available. I've no involvement with this group but I'm absolutely delighted they are they doing this and taking the spirit of Creative Commons to heart.

c) Lots of people just use pen and paper, Visio or equivalent.

--- books and variations

There's three books which refer to mapping. The excellent Digitizing Government by Alan Brown, Jerry Fishenden and Mark Thompson. Also Jez Humble includes it in Lean Enterprise which I've not read yet but I'm looking forward to it.

The WardleyMap crew have also stitched together a community book based upon many of my old blog posts on the subject and there's a community effort to make it better. 

There's also this blog which has mapping scattered throughout it.

There's also variations of the map concepts e.g. 18F has an interesting take in their post on 'How to Use More Open Source in Your Next Federal IT Acquisition'

--- notes

This post is an update on the "basics repeated again". I've added the comparison to other maps more explicitly (this is an incredibly useful first step) and simplified the management of the different methods into one single step.

The accidental consequences of connecting 100 billion+ dumb things together

Back at Ignite SF in 2007, I gave a talk covering commoditisation, evolution, 3D printing and the web of things. I finished the talk with a concern that I had repeated before and since. That concern I summarised in this image - the matrix will be built from a lot of basically dumb things.

I'm not a fan of the pantomisation of science and hence I'm uncomfortable with the recent open letter on AI research with celebrity endorsements. This is not how we should be funding investigation into science and the intent of the letter can only be seen as attempting to lobby and influence funding directions. I view it as misguided.

I do share concerns about the future of AI but then I take a different view from most on where it will come from. Neurons whilst complex components (receiving, transmitting and storing signals using a mix of electrical, sound and other transmitters, able to connect to other components, responding to the environment and changes in the environment) are essentially dumb. The "intelligence" is in the interconnections, the constantly adapting matrix of all the signals and signals processing.

My concern is not that we will create "AI" through some concerted effort (I view this as hubris) but instead that we will accidentally build "intelligence" through the simple act of connecting 100 billion+ complex but ultimately dumb components with the ability to receive, transmit, connect and store using a mix of mechanisms and sensors. 

Let me emphasise that point - we are already building the matrix, it's called the Internet of Things. We just don't know it yet. We're not deliberately doing so and when the "intelligence" is discovered then it certainly won't have been created through any planned effort of our own but will have emerged and evolved in the space between devices. It'll simply exist in the interconnectedness of billions upon billions of dumbs things. 

At that point we're going to have to work out how to communicate and reason with it whilst knowing our lives, supply chains and economic systems are all dependant upon the billions of dumbs things that enables it. We simply won't be able to switch it off, separate it or apply "rules" to it etc.

When will it happen? We don't know, it'll need to emerge and evolve first. We don't even know the starting conditions for this nor whether some constraint would prevent it from happening. It could be hundreds of years away.

Does evolution imply competition? Yes. In all likelihood if it does occur then there will need to exist multiple competing forms of simple intelligence in this space to drive its development to the point that we notice its existence.

Can we influence its development if this happens? We're unlikely to notice it until one form becomes advanced enough that we  can discover its influence. All we need to do is connect huge volumes of these dumb things together, write endless non related systems that interconnect them and wait.

Isn't this like monkeys writing Shakespeare? Nope, think more along the lines of swarm intelligence (e.g. from ant colonies to co-operative behaviour in populations of bacteria).

--- 17th Jan 2015

This all depends upon nodes, connectedness and the ability for multiple forms of intelligence to emerge and compete in an environment.

Remember :-
* life itself is fundamentally about maintaining and reducing entropy
* the cycle times between such populations (unlike in biological systems) could be exceedingly short (orders of milliseconds)
* competition will naturally drive to more stable components enabling higher order systems and therefore higher orders of intelligence to emerge
* life and the development of intelligence is itself simply a series of bugs, unforeseen circumstances and accidents interacting with competition.

Out of interest - Google's secretive Omega tech just like LIVING thing. Even a cockroach has a million nodes with a billion interconnections. Then of course, you have to multiply up to create competitive environments. Still, with a 100 billion devices and say a trillion different interconnections then you might find space for a few roundworm like intelligences to emerge. Don't expect to be having startling and witty conversations over dinner with it.

The real question for me is therefore will we create artificial intelligence before it emerges?

On services ...

When mapping a complex environment, the connections between components (whether activities, practices or data) are interfaces. Those interfaces maybe provided through programmatic means (e.g. APIs), user interfaces (i.e. a webpage) or other means (e.g. physical interfaces). 

However, those interfaces evolve as the component evolves. The interface starts as highly unstable (e.g. constantly changing) due to the chaotic and changing nature of the component. It's novel, it's new, we are operating in the uncharted space of the uncertain. Over time as the component becomes well understood then the interface becomes more stable, even giving an impression of order as the component becomes more of a commodity. For example, a plug and socket are well understood, well defined interfaces which mask the complexity of generating electricity from your average user.

So whenever you map out a complex system or business, you not only have evolving components but the interfaces have different levels of stability (see figure 1).

Figure 1 - Interfaces in a map.

When a component is consumed by others within a more complex systems (e.g. electricity consumed by a computer) then there is a cost associated with any change of the interface or the operation of the component. We experience this (in a trivial sense) when we visit a different country with a different regime of power supply / power standards and we need to take adaptors to cope with the change.

With a large volumes of users consuming an interface in a plethora of complex systems then the total cost of change can be significant. For example, try changing national power supply standards or currency (such as decimilisation in the UK) or the switch to digital TV. Users will tend to collectively resist such a change unless overwhelming reasons are given.

This resistance tends to stabilise the interface and discourage the provider from changing it. This is why your electricity provider can't decide to change the interfaces (e.g. frequency, voltage range) every week and if they attempted to there would be a huge public outcry. This is also why volume operations based services such as cloud services are really only suitable for when the activity has become a commodity and the interface can become relatively stable in a short period of time.

This doesn't mean that you can't provide your brand new "never invented before" concept through an external API to others. However given that the interface is going to change an awful lot in the beginning as we explore what the new concept is, this will limit the volume of users you can support i.e. for some brand new concept then we're talking very few consumers. If you don't believe me, then when you next invent some brand new (never invented by anyone else before) activity then try providing it as a utility service and start changing the interfaces weekly as you discover more about it. The one thing you're not going to build is a volume based service with a large volumes of users. It's simply not ready for it.

Volume based utility services provided through APIs are only suitable for well understood and well defined activities - things like provision of computing infrastructure, CRM, databases, platforms, specific widely used applications etc. These have all had decades to become widespread and well defined enough to be suitable.

Now, when you look at an interface, it simply provides a mechanism of meeting the need for a higher order component (remember these Wardley maps are based upon a chain of needs vs evolution). Hence, from figure 2, the user need is met by component A. However component A needs both component B & C and so forth.

Figure 2 - User Needs and Interfaces

Remember sometimes those interfaces can be provided by APIs, sometimes they are physical interface (e.g. plug in socket), sometimes a user interface etc. Now, in the above diagram, let us consider three user needs - represented by components A, B and D - that we wish to provide as external APIs to others. 

Component D represents a highly evolved commodity-like activity suitable for volume operations where the interface should be relatively stable (an example would be infrastructure such as EC2). These can be provided as utility services and will normally end up over time having multiple providers or ways of implementing.

Component B represents an activity which is in the product phase of competition (i.e. it's still evolving). Hence there will be lots of competition between alternatives on feature differentiation and as a result change. It could be provided through an external API and is more likely to be a very "product" specific rental service rather than generic utility service.  There is usually only one provider for each product type, little duplication of interfaces and no guarantee that your product vendor will end up being the long term utility provider. You can usually see this difference in the language people use, naming specific providers rather than the generic activity. Hence rather than talking about a generic activity such as collaboration, people will often talk exclusively about the specific instance such as Microsoft Sharepoint. This doesn't mean Sharepoint can't be provided as a service, it can and is. However, it represents more of a rental service (often more suited to a subscription basis) as opposed to a utility service.

I know people call both Amazon EC2 & Microsoft Sharepoint both "cloud" services but then that's the awfulness of that dreaded word cloud. Amazon EC2 is far more of a utility service than Microsoft Sharepoint which is still more of a rental service for a product provided over the internet. Collaboration software isn't quite there yet.

You get quite a lot of this "cloudification" of things (for want of a better word). For example, if I take MySQL and run it on EC2 have I created a MySQL Cloud? No, I've stuck a product on a utility service. The process of trying to provide this to a large numbers of users and billing as a utility will certainly end up converting this to a more utility service (databases are evolved enough to be suitable) but whilst the interface to MySQL might remain the same, the system will be very different.

I try to avoid the word "cloud" and instead break down systems into their components. Some are utility whilst others are more products. The two are not the same.

Component A represents an activity which is relatively new (i.e. not widespread and well defined). Though it can be provided through APIs to others, the interface will change very frequently. It really isn't suitable for attempts to provide it on a volume basis through a rental / utility service to others but that won't stop people from trying. This is more suitable for discrete provision to a single or few clients whilst the activity evolves.

I suppose what I want to emphasise here is that the interfaces also evolve as the component evolves. That's a fairly obvious point but one to emphasise. Also when we talk about a services based organisation, then in the technology sense we're mainly talking about building an organisation where many of these interfaces are provided through APIs. However, just because you provide APIs doesn't mean all APIs are the same - some are inherently more stable than others due to how evolved the activity is. You need to factor this in.

The best guidance to building a services based organisation was apparently written in a memo by Jeff Bezos in 2002. I've not seen better since, so I thought I'd copy the spirit of that memo here.

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn't do this will be fired.

This was 13 years ago. I just thought I'd emphasise that point because I hear people talking about building a services organisation (e.g. use of micro services) as though this is some radically new idea. I'm not against this, it's a good idea but just be aware - it's not new and this is more about keeping up with the pack rather than gaining an advantage.

Basic Rules on Conference Speaking Requests ...

I (like everyone else) submits talks via CfPs to conferences that I'm particularly interested in - sometimes I'm lucky, sometimes I'm not. I also get invited to speak at many conferences around the world and whilst it is pleasing to be invited, the majority of these I turn down. There are some basic reasons why I turn down conferences. So, I thought I'd put together a checklist for conference speaking requests. This, of course, excludes LEF & LEF member events, O'Reilly Media, London Cloud Camp and requests from friends which are dealt with differently.

The basic rules are ...

Q1) Is this a specific request or a vague enquiry? If "vague" then I'm busy - even if you haven't told me when your mystery event is.

Q2) Are you paying my expenses? If "no" then I'm busy. I wasn't planning on being at your event, I expect you to compensate any costs.

Q3) Am I travelling business class for any long haul travel? If "no" then I'm busy. If I didn't submit via CfP then I certainly don't want to add discomfort to an event I wasn't planning on attending.

Q4) Are you paying my expenses including flights and hotels directly or do you expect me to pay and then claim them back? If "pay and claim back" then I'm busy. By asking me to pay and then submit a claim, you're asking me to either personally loan you the money or invoke internal company expense and travel policies as the company will need to invoice.  Both circumstances are a quick route to "I'm busy". Make my life easy or I won't attend.

Q5) Is this relevant to my research on competition? If "no" then I'm busy. I'm not going to put the work into speaking if I don't see any value in attending.

Q6) Do I need to fill in lots of forms? If "yes" then I'm busy. Make my life easy.

Please note, the following things don't count as alternatives to direct payment of business expenses and avoidance of form filling …

1) A prestigious event  [please note, everyone claims this]

2) A great opportunity [ditto above]

3) A large number of CxOs attending [ditto above]

4) Potential for marketing [ditto above]

If you pass this list AND if I'm free then I'm happy to consider speaking. However, save yourself the time of asking me if you don't.