Bits or pieces? An introduction to Wardley (Value Chain) Mapping

Bits or pieces? An introduction to Wardley (Value Chain) Mapping

by Евгений Волков -
Number of replies: 0

Monday, February 02, 2015

An introduction to Wardley (Value Chain) Mapping



This post is about my journey, from a once newly minted yet confused CEO caught like a rabbit staring helpless into the oncoming headlights of change to being voted one of the most influential people in IT within the UK.  It took me a decade to first develop the techniques that I’m going to describe and a further decade to gain confidence with them through practice. I dearly wish I had known these techniques at the beginning but then such is the nature of exploration, someone has to first experience the unknown before you can learn and then you still need a way of learning.
So in the forlorn hope of helping the reader - I am mindful that the one thing we never learn from is the past especially when it belongs to others - I’ve written a short guide to those practices. If you are like I once was, a confused CEO struggling to cope with the change around them, then this might help you progress in your journey.
Every journey begins with a step, in our case there are several. I’ll use an example throughout and in this first foray I’m going to map a TV company. I'll be using an early draft, which took a few hours to develop, including the strategic play from a base understanding of nothing about the TV industry. The reason I’ve selected this example is because whilst it explains the process of mapping, anything of commercial value has long since left it and been exploited or discarded. So, I suppose we better start with those first steps.

Step 1. Needs!

Critical to mapping is to first focus on the user need. It’s important not to think of your needs i.e. your desire to make a profit or be successful. You need to think careful about what the user actually wants. There are various techniques for this from writing the press release to creating a user journey. In the case of the TV Company, the users wanted to be entertained during their leisure time. There were two routes to satisfying this need, either through a branded online service that delivered the company’s programs or through a content aggregator such as NetFlix or Amazon where the output from many TV companies is combined.  Figure 1 provides a simple needs diagram which shows the user need.

Figure 1 – User Needs

Step 2. Value Chain!

Once you’ve determined the high level needs then the next step is 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 by meeting the needs of others you hope to create value. If I had a need for a cup of tea, then by mixing the components of a kettle, cold water, cup, electricity and tea then you can meet my needs. That has value to me. At the top of any value chain should be the visible user need that you are trying to serve and below this are the increasingly invisible  (to the user) components that are necessary to serve those needs. Figure 2 provides a value chain for the TV Company.
Figure 2 – A Value Chain
In the above diagram then both branded and aggregator sites need content. That content needs a distribution mechanism (e.g. internet broadcast or traditional media) but it also has to be created which requires artistic direction. Naturally, artistic direction needs a creative studio to make the show but it also needs market analysis i.e. what sort of programs do people want to watch? And so the chain continues down to components such as compute and power.

Step 3. Map!

Value chains on their own are practically useless for understanding an environment because they lack any form of context on how it is changing.  If you think of a company like Nokia, it started as a paper mill became a plastics manufacturer and then eventually a telecommunications company.  During this time its value chains have radically altered. In order to understand an environment we therefore need to somehow capture this aspect of change and combine it with our value chain. The biggest problem with creating an understanding of the context in which something operates is that the process of change and how things evolve can't be measured over time. As uncomfortable as it is, you have to simply accept that you don't have a crystal ball and hence you have to embrace the uncertainty of future change. Fortunately, there’s a neat trick because whilst evolution can’t be measured over time, it can be measured over certainty. So, this is exactly what you need to do. Take your value chain and map it with an evolution axis.
Figure 3 – A Map
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 an uncharted domain (the uncertain, rare and constantly changing) becoming more industrialised (the known, the common, the stable). For example, power supply is something commonplace and well understood. We all know how to use a plug and switch on a socket. However, creative studios and the art of creating a TV show is less common and less well understood, it is more a source of wonder and amazement for many. It should be remembered that power supply was itself a source of wonder and amazement back in the 1890s.
Once you have a map, examine it. In the above, the content component 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 – see figure 4 below. 
Figure 4 – A Map with a pipeline
You now have something that 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 something such as a “rules engine” then it doesn't take long to discover at least half a dozen other projects building “rules engines” in the same company. 
Duplication is rampant in most organisations because there is usually no means of effective communication within groups. At best, you hope to bump into or discover another group working on the same problem. Of course, even if you do find another group then that’s no guarantee they’ll want to work together - they all tend to believe that their rules engine is somehow unique and different from everyone else's.  Everyone has bias.
One of the beautiful things about 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 even challenge your own maps against the outside market and other competitors. The way that I normally do this is to start by aggregating maps, an example of which is given in figure 5.
Figure 5 – An aggregated view
Now, when you look at your map then not every component will have a duplicate in the organisation but that said, many components would have multiple implementations. For example, if we take the above aggregated view as typical then there would be 13 different implementations of web site, 5 different implementations of recommendation engine and 18 different implementations of compute in the same organisation. These are all examples of duplication. The worst-case scenario that I’m currently aware of is over 120 different implementations of case management in a single organisation.
Even if you find duplication, then not every group will treat the same component in the same way. For example, the 14 different implementations of web server vary from one group believing it should be custom built to a larger group believing it’s more of a commodity. This is the issue of bias. The worst-case scenario of this that I know involved 100 commercial companies that had implemented Financial ERP (Enterprise Resource Planning).  Each company had heavily customized their Financial ERP system in identical ways and the net result was an annual aggregate spending of £8-£10 billion customizing the same system in identically the same way. Obviously the system should be more of a commodity but unfortunately it was in the vendor’s interest to persuade the companies that the identical customizations were somehow providing a unique advantage. This only worked because none of the customers were talking to each other.
By choosing clusters of points on an aggregated view (the red dots), you can determine roughly how something should be treated i.e. in our map (the blue dot) we have market analysis as something relatively novel and best implemented with an early stage product. However, the majority (the cluster shown as red dots) has market analysis as something common, well-defined and best implemented with a commodity or utility like service. The use of the aggregated view can therefore tell us that we’re not the only group doing market analysis in the organisation but also that other groups are treating it in a much more effective and commodity manner.

Step 5. Adjust!

Once you've challenged the map by removing duplication and bias, you need to adjust it with the people involved. Hence, you take your map, point out all the areas where we can use the work of other groups and also provide the evidence that we’re going about things in the wrong way. This is always a fraught time because people may well have inertia to change and hence will resist. It’s fair to say that if someone has spent considerable time building their own home grown customized version of electricity supply then they’re not going to be happy if you suggest ditching their work and using a standard electricity supply.  Ditto with computers, financial ERP, accounting and almost everything else you can think of including lines of business.
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 don’t forget to use your maps to make agreements between groups i.e. this group will build the rules engine for all the other six groups etc. You can't remove such duplication without a communication mechanism such as mapping. Relying on people to simply talk over the water cooler in a large organisation is how most companies get into a mess of duplication. [HINT ... if you're going to build a platform, then use that aggregated view to identify common components that are commodity like and are not currently provided by the market].
Let us however assume that you have persuaded (or forced) everyone on the adjustments necessary and made agreement to consume and supply components to other groups. I’ve provided an adjusted map in figure 6.
Figure 6 – Adjusted Map
From the map, we have already identified the user need (the “visible” elements at the top of the map), we know the components involved in creating those needs (the value chain), we’ve got some idea of the context and how evolved the components are and we’ve challenged the map by identifying any bias we might have in the treatment of components. We’ve worked out that other groups have built several components and these are things we should consume from them. We’ve also agreed with other groups that several components (streaming engine, recommendation engine) we could look to provide.  
We’ve not only got a good understanding of the landscape but we’ve removed potential duplication and bias. This entire process can be done in a few hours.
The next step is about putting some measurements in place and sharing the maps with others, however I thought I’d jump ahead to my next favourite step – strategic play.

Step 6. Think!

By this stage you should have a reasonable map of the environment that has removed much of the duplication and bias and provides a clear way of communicating the context to others. This is the stage in which we add a bit of strategy to the conversation. I tend to abolish the word strategy from the lexicon until we’ve 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 straight into the HOW, WHAT and WHEN.
Try and discard any images in your mind of chess players 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 competitor nor any advantages they might appear to have as these are often extremely easy to turn.
Now, there is a lot to strategy from anticipation of change, to competitor moves, to inertia, to tactical plays, to manipulation of market, to misdirection, to weak signals, 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 then maps are an incredibly useful 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.  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 a simple example known as Fool’s mate. 
The problem is that the TV Company has to commission shows from creative studios. There are 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 in figure 7).
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. 
Of course, the vendors of production systems won’t be happy with your play (they’ll have inertia) but with the creative studios backing you up, this can be easily overcome.
Figure 7 – Gameplay
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. The benefit of attacking this space is that 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 exist a whole range 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 through the Fool’s mate example.

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 don’t tend to bother because your map will change with time and competitor moves. TOMs tend to be more wishful thinking and I have a preference to keep it adaptive. In figure 8, I’ve added method and used arrows to show a direction of intended travel (as opposed to a TOM).
Figure 8 – Methods
The above map gives me a view of the environment based upon user needs, the components involved, the context (how things are changing), the strategic plays, how I can reduce duplication (consume other services internally), what I can provide, a mechanism to overcome bias and the methods involved (from agile to lean to six sigma). 
This map is something that I can discuss at the board level right down to individual project managers. Hence I tend to have a strong preference for maps within an organisation.

Step 8. Simple!

At this point I normally break the map into teams. I tend to require a focus on FIST (Fast, Inexpensive, Simple and Tiny) principles and the use small, self – organizing, cell based teams (ideally less than 12 people) combined with small, focused contracts. I also tend to use a pioneer, settler and town planner structure. See figure 9 below.
Figure 9 – Organisation

Step 9. Evaluate!

Once completed, I might use a SWOT or Business Model Canvas (BMC) to refine a few more details. This really should be super quick by now as you'll have almost all the information you need. I often omit this step.
Once you become comfortable with the approach then the entire process of mapping out a line of business from user needs, removing duplication, removing bias, identifying strategic plays, break out into methods and teams shouldn’t take more than a day or two. Given the scale of most projects, it’s usually time well spent. 

Step 10. Act

At this point I’ll move onto getting stuff done (JFDI), often using Kanban as a scheduling tool and using the map as a guide. Obviously, maps evolve over time and there’s quite a bit to learn about mapping especially in the strategic play area – I’ve been doing this for over a decade so it has become second nature to me.  
Figure 10 - Kanban


I prefer not to make grand claims of how much it’s going to save you or how much it’ll improve your strategic play other than to say – a little bit of situational awareness seems to go a long way. The proof of the pudding is in the eating, so I’ll just suggest you try it for a few days and make up your own mind whether it’s useful to you or not.
If you need a simple way of remembering the steps then,
Step 1. Needs!
Step 2. Value Chain!
Step 3. Map!
The first part of mapping is to improve situational awareness i.e. it's useful to have some in the first place. When you've written a map that's not the end because maps are dynamic and will change over time.
Step 4. Challenge!
Step 5. Adjust!
The second part of mapping is to challenge what we think the situation is, remove duplication and bias. This involves sharing maps with others, refinement (including metrics where needed) and adding in aggregate perspectives (our own historical repository of how we treat things).
Step 6. Think!
Step 7. Methods!
Step 8. Simple!
Step 9. Evaluate!
The third part of mapping is to decide to do something, the strategic play, how we're going to do it, how we're going to organise it. The last bit - evaluate - is usually to create those evaluation artefacts (SWOTs, BMC) that others seem to sometimes require in order to bring them along. It can be useful but often I find that last step unnecessary, time consuming and often omit it.
Step 10. Act
The last bit of mapping is to get on with it, get started. This is not the end of the story though, you have to continuously iterate all the above.
Yes, this is John Boyd's OODA loop but then it's probably the only truly universal technique that I've found useful. To get started, plan to spend a couple of days at most to get to the ACT part. Yes, you'll need to iterate (update maps with new user needs, changes in the environment etc) and alter your strategic play but then this should be much faster than the first loop.

3563 words