Why Map?

Mapping is all about situational awareness and understanding the context of a complex system whether an organisation, a line of business or a technical system. Without good situational awareness then it's extremely difficult to identify where to attack and hence strategic why (since 'why' is a relative statement - why here over there). It's even difficult to know how to manage something.

Without this, you might as well write a strategy which starts with general platitudes :- 

"We're going to be innovative, be efficient, be agile, focus on core, create a strong culture, create shareholder value, and establish ourselves in [XYZ]"

Where [XYZ] is fundamentally what everyone else is doing - cloud, social media, big data, digital first, 3D printing - i.e. replace with whatever is popular amongst competitors at the time in hand and hence currently reported in the popular management press - HBR, Economist etc.

From my own work, the problem with situational awareness stems from how we view the landscape. In figure 1 is a typical box and wire diagram for a large complex system (this could be an IT architecture diagram, a business process map, a user flow diagram etc). I've removed the terms of the components so we can focus on the diagram.

Figure 1 - A typical box and wire diagram.

It's a great wiring diagram from the point of view of plugging boxes together whether those boxes are technology systems or business processes but it's less than ideal for strategic planning.  The diagram tells us nothing about how to manage the environment, where there might be opportunities to attack, how to play the game and how things might change.

So, in figure 2 here's an alternative mapping view from @crankypotato and his post on mapping. Now I know nothing about what value chain this represents because they've not given me the terms (it's a blank diagram) but there's an awful lot I can say about game play from this diagram.

Figure 2 - An unknown value chain

First of all, from the above I can immediately identify what should be representing the visible need of the user.  From this I can determine a few potential differentials. At the same time, I can see what are the hidden components and where potential opportunities for efficiency might exist (targets). I'll also note that two of the more hidden components appear to either be operational advantages or potential constraints. I've summarised this in figure 3.

Figure 3 - Needs, Differentials and Efficiencies.

I can also now look at focus and parts of the map clearly need an experimental focus e.g. minimal viable, willingness to experiment and fail etc. Others need an approach of feature differentiation and tight feedback loops whilst the more hidden components I should be looking to drive towards more commodity, standardising with open approaches and the use of competitive markets where possible. I've summarised this in figure 4.

Figure 4 - focus

Now, I can start to look at how I can manage things. Obviously in practice I'd challenge the map and question whether some of the activities are really as they have been described. It's quite common for people to describe something which is ubiquitous and well defined as needing a custom built solution when in reality it doesn't.  However, assuming the map is roughly right and there's no glaring errors (like treating a CRM system as bespoke) then it's fairly easy to identify what should be built in-house with agile techniques, what should be a modified project, where we should be using out of the box and areas where we should be looking at more utility or cloud services. See figure 5.

Figure 5 - How to manage?

Ok, now at this point I have an idea of where I can find differentials, areas of efficiency, the focus I need and how to manage but I've got a question of how to measure?  The mechanism of measurement will vary again with context, so I can take a stab at what I should be using. This I've added in figure 6.

Figure 6 - How to measure?

Now, I have a basic understanding of the landscape, what to focus on, how to measure, how to manage etc.  I can now take a look at where to attack. Remember that disruption can occur in the product space with substitution (i.e hydraulic to cable excavators) but that's difficult to predict. Evolution from product to utility is again disruptive (combination of inertia with a punctuated equilibrium) but its far easier to predict. So, I can look at the activities (or practices or data) and identify those which are suitable for utility provision, where inertia barriers exist and where I can build ecosystem (exploiting an ILC like model).  I've summarised this in figure 7.

Figure 7 - Possible "where's" to attack

Once I've identified the where, I can look for why this route over that (i.e. type of competitors, probability of exploiting inertia) and ask questions of how I do this? Can I use an open approach to drive commoditisation and create a competing market, can I alter buyer / supplier relationships, can I undermine barriers to entry in a competitor's space, can I build a tower and moat play ... a long list. 

I can enhance this further by looking at competitors maps, anticipating likely changes and potential competitor constraints. The more details I have (i.e. what the dots in the diagram actually mean) then I can dig further and write some form of sensible strategic play. With more maps, I can build ways of identifying common service and I can even look into how to organise a company avoiding the usual business alignment issue (an artefact of structure). 

However, that's not the point of this post. What I wish to demonstrate is that mapping is a far more useful tool for strategic planning than the box and wire diagram. Certainly box and wire can't be beaten for implementation but for strategic planning ... they're lousy.

Without good situational awareness then any strategy is likely to become full of how, what and when (i.e. implementation, operational, tactical and purchasing details) with little or vague "why" which where it exists will be one of those common platitudes.

Whilst I have no idea of what value chain @Crankypotato is talking about (i.e. I don't have the details), I can already ask some reasonable questions and if we ever sit down to discuss it then we can have reasonable debate on what the map means and how to manipulate the landscape.

This is why mapping is a useful tool.