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.
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.
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.
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.
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.
