Whilst I use mapping for strategic play, to remove duplication and bias, for communication (removing business vs IT alignment issues), for finding common services, for organisational learning, for risk management (especially contracts), for ensuring correct methods are applied, for combating inertia ... there's a lot ... I also use mapping for some pretty simple operational stuff.
tl;dr If you've been following my posts or talks on the subject over the last decade, you've heard this umpteen times before, so switch off now. This is really for those relatively new to the topic (where have you been) and simply says - one size doesn't fit all.
I thought for simplicity I'd break this down into sections, using an old map - part of the IT structure behind HS2 (high speed rail).
A Wardley Map - the basics.
Pretty simple stuff, starting from user needs, breaking down into components (the value chain or chain of needs) and mapping across evolution. See figure 1 and for more details go read the post on Wardley mapping.
Figure 1 - HS2
NB this map is many years old and it was a draft (prior to challenging for any bias etc). Hence many of the components are far more evolved than shown in the map above.
As we all know, everything on the map is evolving (from left to right) due to supply and demand competition. As it evolves it moves from the uncharted to the industrialised. The properties of these two domains are very different, so a single act evolves from the uncertain to the well understood (see figure 2). You can even map practices, data, activities and even knowledge.
Figure 2 - Basics of a map
There's an awful lot you can do with maps from learning basic economic principles such as how the evolution of one act to an industrialised commodity enables the development of higher order systems to economic patterns such as peace, war and wonder or how organisations evolve to gameplay to ecosystem models like ILC to the finer points of organisational flow. You can find posts on these topics scattered throughout this blog. In figure 3, I've provided a simple way of aggregating multiple maps to remove duplication and bias in any organisation.
Figure 3 - Comparison across maps
A Wardley Map - Operation
So, now given the basics, let us talk about operations. We have a map and though it will evolve and change due to competition, we shall look at the state 'as is'. A number of basic tools can help.
FIST
When organising a map, I break it into small teams by applying the principles of FIST (Fast, Inexpensive, Simple and Tiny). Small teams make things easier. I tend to use a cell based structure based upon Amazon's Two Pizza rule (i.e. no team bigger than can be fed with two pizzas) and use Kanban as a the scheduling tool between teams (see figure 4). Because of the issue of aptitude and attitude, I also tend to overlay a pioneer, settler and town planner structure.
Figure 4 - Breaking a Map into teams.
Project Methods
As the map contains multiple evolving components, I tend to use multiple project methods because each class of method is suited to a particularly space. The division of methods is shown in figure 5 and an example of use is provided in figure 6.
Figure 5 - Appropriateness of Methods
Figure 6 - Methods and HS2
You might ask 'Why is web site a commodity but built with agile' which is a perfectly valid comment. In reality the web site node on the map is itself a map of components, some of which are highly industrialised (and suitable for outsourcing, utility approaches, six sigma) whilst a few aspects are relatively novel. Maps have granularity and a high level map (such as the one above) loses some detail (in the same way that an atlas loses details on streets). By having a map then you can break down these discussion and challenge these points. In the map above, I'd personally separate off the novel content as a separate component from the website and mark the website for utility provision (i.e. cloud). There's also numerous points I'd challenge the map on. However, this is not my map but HS2's.
Purchasing
There are many different purchasing methods and as with project methods then for any complex problem I tend to use multiple. Figure 7 shows what methods are most appropriate at each stage of evolution.
Figure 7 - purchasing methods
Cloud / APIs
Cloud is about the shift from product to utility. If you're looking to consume or provide cloud services or even build an API based ecosystem then know the difference of when to build on top of and when to build - see figure 8.
Do remember, this map is many years old and it was a draft (prior to challenging for any bias etc). Hence many of the components are far more evolved than shown in the map and a lot more are suitable for provision or consumption as cloud services today.
Figure 8 - Build or Build on top of?
Open Source and Open Standards
Open source is an accelerator to evolution, it helps shift activities towards a more industrialised form (there are means also to de-accelerate the process e.g. constraints, patents, FUD and removing competition). Open approaches are an extremely use part of gameplay.
Open Standards are important as something becomes more industrialised. They're an essential part of creating a competitive market. Often you'll combine the two with open source providing the reference model for the open standards of a market. Figure 9 tries to capture this difference. There's lots of finer points here but it's worth exploring the subject of semantic vs syntactic interoperability.
Open Standards are important as something becomes more industrialised. They're an essential part of creating a competitive market. Often you'll combine the two with open source providing the reference model for the open standards of a market. Figure 9 tries to capture this difference. There's lots of finer points here but it's worth exploring the subject of semantic vs syntactic interoperability.
Figure 9 - Open source and Open Standards.
If you're new to the field of Wardley Mapping, this will give you enough to think about. If you're an old hat then why are you still reading? I did warn you it was basics.
