Other tools I use with mapping

In this post I'm going to discuss some of the other tools I use with mapping. I'll start by expanding on the map I created in the Introduction to Wardley Maps post. This original map was used to determine user needs, strategic play, remove duplication and bias, enable collaboration between groups, communication and identify appropriate methods (whether project management or purchasing). See Figure 1

Figure 1 - Basic Map

Sub Maps

Sometimes maps can get very big and very complex. Hence I tend to use a high level map (as above) with several of the nodes representing a sub map. You lose granularity with high level maps in the same way that an atlas loses granularity of the street level. This is fine, the high level map is what you use to determine your overall play and the sub maps often contain quite tactical details. Hence you might use a high level map in the board but a project manager in one area of the business might use the high level map (to see how their part fits into the whole) and sub maps giving more details.

To create sub maps is trivial. Start with the component node as the new NEED i.e. if you select streaming service (in the above) then your users are Website and Internet broadcast and they both have a NEED for streaming service. See figure 2

Figure 2 Maps and Sub Maps

RISK

Critical Path / Fault Tree

I also use maps to help determine critical paths and fault trees i.e. if something happens to my recommendation engine where does that impact me? In the above scenario I can still commission shows and deliver a streaming service but it does impact the web site. If however I lose internal power then multiple systems can be impacted and no service is delivered. Hence I try to mitigate this with multiple sources of power or by pushing a higher order system (such as compute) into a more resilient environment. In this case because compute is a commodity, I'd tend to use a volume operations based service in which I distribute my risk across a wide geography (e.g. cloud services like AWS). I've shown an example of such analysis in figure 3.

Figure 3 - Fault Tree / Path analysis

Contract Analysis

One very useful technique is to overlay any existing contracts onto the map. Ideally, you want to have small contracts focused around each node rather than large all encompassing contracts with outside parties. The reason for this is that the methods you need to use vary with evolution (i.e. agile one side, six sigma the other) and if you have a large contract then what tends to happen is a single method (e.g. six sigma) is applied across the lot. More often than not, this is very costly in terms of change control with those uncharted activities. This is because they are going to change and a structured method will tend to punish change. You really should be using agile methods in that uncharted space.

Always break down those large contracts (unless you're a vendor in which case, take advantage and feast on the inevitable change control cost overruns caused by them). In figure 4 I've given an example of good and bad contract structure.

Figure 4 - Contract Structure and Maps

Methods

I've covered this many times before but I cannot emphasise enough the importance of using the right purchasing and project management methods within a large scale project. I use METHODS deliberately because there isn't a one size fits all method but instead you need to use many. Figure 5 provides a visualisation of where each method is appropriate.

Figure 5 - Project and Purchasing Methods

For heaven's sake, don't confuse those polar opposites of uncharted and industrialised with a need to create a bimodal structure. There is a huge gap between them. 

Anticipation

This is more a board level issue but worth noting. One of the huge advantages of mapping is organisational learning.  You quickly discover common economics patterns (from componentisation effects to creative destruction to the peace / war and wonder cycle) along with methods of manipulating the environment to your favour (open approaches, constraints, FUD etc). There's lots of games you can play and get good at.

When it comes to anticipation then weak signals are critical (there are numerous you can use). One of my favourite long term signals is publishing type (i.e. how the activity is described in common publications). Do remember that you can map activities, practices, data and knowledge and the weak signals apply across all.

With the peace, war and wonder cycle then the part which can be most anticipated is the 'war' phase. This phase can be highly disruptive but since you can anticipate it, then you can also prepare for the change. It's worth noting that are two forms of disruption - the more predictable product to utility substitution which creates the 'war' and the unpredictable product to product substitution. Don't confuse them.

Hence, I'll often look for 'predictable' points of change by identifying the wars (see figure 6) and then examining my map (see figure 7) to see where I will be affected.

Figure 6 - Points of Change and likely future 'Wars'

Point 7 - Points of War in your value chain.

So from the above I know that compute is undergoing drastic changes towards a utility (in fact we knew this was imminent in 2004). I know that traditional media (DVDs) is being impacted along with aspects like CRM that are on the verge of change. Recommendation Engines and Streaming services haven't industrialised yet (but remember this map is several years old). They will.

As with other changes of this type then I already know the impact (disruption of the past stuck behind inertia barriers, new forms of un-modelled data, co-evolution of practice, rapid explosion of higher order systems that use the component etc) before it has happened. I know that I'll also have inertia to the change but by being prepared and knowing where it will hit means that I can do something about it.

Business 

When is comes to business, then there are two aspects of mapping I use. The flow of money through the map and competitor analysis. These are quite detailed topics but I'll summarise.

Competitor / Market Analysis

I often use maps to look at competitors. This can be either by examining their value chains to identify any inertia they might have to predictable forms of change or I might look for any differentials that they have with us. I'll also use maps to look at different markets. This sort of analysis can give me an idea of where I need to protect, against whom, how I can exploit the situation to my advantage, and which region future competitors may come from. When I'm looking at different markets, I examine whether that market is more evolved or more emerging, whether the activity is price elastic or not, what constraints exist and what games (e.g. an open play) are being used in the wider market.

I've given an example of such a scenario planning exercise from a different industry in figure 8 and I'll often run games around these to tease out impacts and edge cases.

Figure 8 - Scenario Planning

Business Flow

I like numbers particularly when those numbers represent cash in a profitable way. When we think of business, I tend to think in terms of flows of revenue and cost. I hence use the map to create different flows through the system, identify cost and revenue and create business flow diagrams (see figure 9).

Figure 9 - Business Flow Diagram

Sometimes I'll find one business flow is more profitable than another. Sometimes an act will evolve and a particular flow will become unprofitable or another will become profitable or a further will become possible or most likely a combination of all the above will happen. These diagrams can be a bit tedious hence it's a good idea to like making money. However, the upside is that you can often find entirely new ways of making revenue during the process and it certainly helps you to focus on this.

Opportunity

I'll use maps to look for opportunity i.e. points which we can attack. An example is being the first mover to create an industrialised component and then building an ecosystem on top.  I might also look for areas where we might wish to gamble and experiment building an uncertain need. 

My preferred approach is not to gamble but to be the first mover to industrialise and the fast follower to any new activities built on those industrialised components. This is a technique known as Innovate, Leverage and Commoditise. You commoditise an act, get everyone else to Innovate on top of it and then mine (i.e. Leverage) the consumption data of your ecosystem to spot future successful innovations that are evolving.  You can then Commoditise those activities (or data) and rinse & repeat. See figure 10.

Figure 10 - ILC play.

Operation

Team Structure

Operations is one of my favourite topics (along with strategy) but in this case, it's all about getting stuff done. Its the execution side and that means people (but not in a Wolf Hall sense). I first start by using a map to break out the team structures that I'll need - see figure 12.

Figure 12 - Team structure

Now, I almost always break the map into small autonomous and self organising teams (i.e. two pizza model, no team bigger than 12 people). However, I cheat a bit by overlaying attitude (a technique known as pioneer, settler and town planner) to make sure I've got the right sort of attitude and aptitude in each team. I encourage everyone to work on FIST principles (Fast, Inexpensive, Simple and Tiny).

Now, if you're successful then the size of the system will grow. Hence, as this happens I tend to break down larger components into smaller components in order to keep the teams small (think Starfish model). It's worth noting that the lines between these the nodes on the map are interfaces of communication. I'll use these to create fitness functions for each team, so everyone knows what each team is supposed to be doing i.e. what needs they are meeting, their metrics against those needs, business flows etc. The maps help glue it all together to give a picture of what we're doing and where we're attacking.

Before you ask about the all important "Why?" of strategy. Do remember "Why?" is a relative statement as in "Why here over there?". Maps help you find the many wheres and hence determine the why. Strategy however is another discussion which I've touched upon in many previous posts.

Scheduling

For scheduling between teams, I use Kanban. I don't see the point of using anything else.

Evolutionary Flow

In some circumstance I'll create a profile for a system when it's a company or a line of business (LOB). This profile is useful in understanding the type of people I'll need to recruit and the balance of the organisation. These topics are beyond the scope of this post but such a diagram can be simply created by counting the frequency of components in each stage of your map - see figure 13

Figure 13 - A profile

Validation

Finally, it's worth mentioning that I use a couple of tools to help validate the maps. Despite my teasing of SWOT diagrams, I do find them useful in some circumstances. However the grand-daddy of them all is business model canvas (BMC) and my natural preferred choice.

Once I have a map from which I've removed bias, worked out strategic play, created the business flows and built an operational structure then I have everything I need to fill in a BMC. For me these are exercises in checking that I didn't miss anything obvious. I never start with a BMC but I do tend to use them in finishing stages my first draft of a map.

Why first draft? Well, maps are dynamic. The environment will change because everything evolves through competition. You can't stop it, just get used to it. Hence once I've validated my first draft then I tend to live of it and rarely will go through another validation exercise. We're in the game now and I know my maps will improve the more I play.