A good enough map

I’m often asked whether we can add a new axis onto a Wardley map or some new legend; to be blunt, I prefer not to.

When you create a Wardley map, you first start by identifying users and their needs. For example, a Tea Shop has users like the business that wants to sell cups of tea to members of the public who will hopefully drink it. The Public and the Business are connected through a cup of tea.

Figure 1 - Users and their need for a cup of tea

Once you have users and needs, you expand it by considering what capability and components are needed to make a cup of tea. This creates a graph, a chain of what is required.

Figure 2 - A chain of the cup of tea

But it’s not any old graph; we order it by placing the users at the top and then the components according to how visible we think they are. For example, a cup of tea needs at least three components — tea, hot water and a cup. Now, what is the most visible element? How often do you ask for “a cup of Earl Grey” or an “English breakfast, please”? Is this more frequent than you talk about the type of cup? Is that more often than you enquire about the hot water used?

Once we have ordered the chain, we go through the entire chain asking “how evolved” each component is and placing the components according to an evolution axis from the genesis of something entirely new and never done before to more of a commodity. This creates the Wardley map.

Figure 3 - The map of a cup of tea

Finally, we tidy this up by adding a line of evolution at the bottom and an indicator for the value chain. NB. There can be many value chains on a single map; there is, in practice, no y-axis because that is contained within the chains themselves; it’s more of a directional indicator, i.e. the further you go down the chain then, the less visible the components become to things higher up the chain.

Figure 4 - A Wardley Map

Using this map, we can now:-

Challenge what we are doing — “Why are we custom building kettles?” or “Why is the cup more visible than the tea”?

Add missing components — “Have we thought about staff to make the tea?” or “What about milk?”

Add missing users — “What about regulators?” or “What about staff? Don’t they have needs?”

Add missing needs — “What about a nice place to sit?” or “wifi?” or “A payment method?” or “How about some biscuits!”

We can use the map to discuss how to manage and measure the system, how and where the landscape is changing, where we should focus on improving operations, and where to differentiate. There is an awful lot to be discussed with this simple but imperfect map.

However, that discussion does require thought, communication and challenge. As simple as it is, the map provides massive information compression compared to text. To compensate, it also delivers a constraining framework (a strong opinion in both the view of value chains and evolution), which enables discussion despite the vast amount of information. Even with this, I have found in research meetings that two hours per day is the maximum time people can work on maps without becoming mentally exhausted. Mapping may be simple, but it is also mentally challenging.

Adding another axis will increase the effort required and the potential for confusion. That alone would make them less valuable. So, yes, you could add more axes, colours, symbols, or more of everything in our attempt to build the perfect, all-encompassing, 15-dimensional, AI-driven supermap of the future. However, adding these features doesn’t make the maps more understandable or useful. Instead, stripping stuff away might be the better path.

Figure 5 - The super map of the future, courtesy of ChatGPT.

The maps are good enough for me until something better and simpler comes along. I follow the path of Less is often More.

If you’re coming here for the latest and greatest in project management techniques, then I’ll stop you there. In this article, I will go through some basic principles that are well over fifteen years old and have been used from heavy engineering to low earth orbit. There will be no new-fangled concepts or terms, just basics that have been tried and tested.

Nor will I spend my time waffling on about the sorry state of many technology projects or outsourcing efforts. Failure rates above 70% have been consistent since the 1990s. They are almost as common as the excuses:- communication issues, mismatched expectations, lack of clarity on purpose, difficulties in managing remote teams and cultural differences.

I will use an example from 2012: the building of HS2 (high-speed rail) in a virtual world. I like examples, and this project, run by James Findlay, was delivered on schedule and under budget. I’m picking it because it’s old, and HS2 doesn’t have a good record in the public eye.

However, before we go through the tips, I want to use that same example to show you what was typical in government in 2010–2014 (when I was more active in the UK government). I don’t know the current situation; you must ask them, not me.

How things used to be done.

The image below is the graph of the system for building HS2 in a virtual world; it’s the sort of diagram you’d often find on whiteboards in engineering departments. It contains multiple connected components with many acronyms, such as PIMS for Project Information Management System or CRM for Customer Relationship Management system.

A systems graph

Now, to “ensure” value for money, it was common in 2010 for organisations (both commercial and governmental) to outsource most of the project. This was often done by breaking the project into smaller groups of components (in this case, I’ve called them LOTs) with components that sounded similar to each group grouped together, e.g. a LOT for infrastructure or a LOT for engineering.

A detailed contract with mountains of specifications was then written for each LOT. People had learned that projects often massively ran over cost because of poor or faulty specifications; hence, a lot of effort went into this. Once the contract was written, these LOTs were put out for tender.

Breaking the project into LOTs

80% of the time, as a rule of thumb, these LOTs would then massively overrun in both time and cost because of poor or faulty specifications despite our best efforts. When you specify what you want in a contract, if you change your mind, that will incur costs. The process for this is known as change control.
People would moan about the specifications as the cost spiralled, often doubling, tripling or more. Those people would then commit to never making the same mistakes again, and next time, the specification would be better.

It wouldn’t.

The same cycle would repeat.

This has been going on for decades.

I was stunned when I first encountered this problem (in a commercial organisation in 2007). It’s a straightforward thing to fix. Since then, I’ve watched billions being wasted unnecessarily.

How to fix things

The first thing you do with any project is to focus on the project users by asking the questions:-

1) “Who are the users?”
and
2) “What are the users’ needs?”

For the above graph, I’ll assume that a good job was done identifying users and their needs, and hence, I’ll create an image with that information extracted.

Users and their needs.

In practice, it’d be a great month if 30% of the organisations I meet did this. You will be stunned at how many multi-million pound projects are undertaken with no clear idea of the actual users or their needs.

Once you’ve identified the users and what they need, you need to ask another two questions.

3) “What capabilities do we need to meet those needs?”
and
4) “What components do those capabilities need?”

Capabilities, users, needs and components are all subtly different forms of … components. The key is understanding the relationship, i.e. this component needs that component. In other words, a USER needs this USER NEED, which needs this CAPABILITY, which needs these COMPONENTS, and on and on. I’ve taken our example from above and expanded the components we are looking at.

A chain of needs

Unsurprisingly, we call this a chain of needs. You should never forget that those relationships can come in multiple forms: A needs B or A needs an absence B, or … there are many.

However, let us keep it simple and stick with A needs B.

This chain of needs is a graph, and whilst it is a significant first step, it doesn’t quite get us where we need to be to fix these contract problems. The next step we need to take is to turn this graph into a map, and we do that by simply asking the following question:-

5) “How evolved are these components?”

That component might be knowledge, data, practice, a value or an activity. We use different labels to describe the evolution of each component type. I’ve provided a table of those labels and highlighted the labels I will use.

Labels for different stages of evolution

Using those labels (the x-axis on the map), going through each component and asking, “How evolved is this?” I’ve turned our graph into a map. This was the high-level map that I created with James Findlay in 2012.

A map of building HS2 in a virtual world, 2012

While creating the map, you’ll often find yourself adjusting the chain of needs — that’s perfectly normal. It is perfectly normal to adjust the map because it is always an imperfect landscape representation. We are not trying to create the perfect map. We are attempting to put our assumptions about a project onto the map so that others can challenge it or tell us what we’re missing or where we are going wrong.

In practice, we’ve been challenging it all along. Go back and look at the questions:-
1) “Who are the users?”
2) “What are the users’ needs?”
3) “What capabilities do we need to meet those needs?”
4) “What components do those capabilities need?”
5) “How evolved are these components?”

That last question is always fascinating. More often than not, I come across corporations custom-building stuff, a commodity. But why? Alas, most organisations tend to run on stories, and the problem with stories is we associate good leaders with good storytellers. When you challenge someone’s story, you say, “You’re not a good leader”. This never ends well.

With a map, I’m saying the map is wrong, not the person. Challenging the assumptions in a map is much easier than challenging the assumptions in a story.

Suppose we do that and end up with a good enough map that has been challenged many times. How does that help fix our contract problem? Using maps, we have learned many technological, economic, social, and political patterns. Few to discuss in a post. However, I will discuss one pattern: “There is no such thing as one size fits all”.

When we look at the map through the lens of project management methods, it turns out that some methods are more robust in different places of the map, i.e. agile / XP works best in the more genesis/custom built phase because it reduces the cost of change and change is the norm. On the other hand, Six Sigma works best in the more industrialised/late product/commodity space because it reduces deviation, and you don’t want deviation with a commodity. In between Lean / SCRUM / MVP work best because we’re still learning about the space. I’ve summarised this in the following image.

Different methods work best in other parts of the map.

Now, we can ask the question:-
6) “How are we managing these components?”

On the map, we can show how we think we should be managing it, i.e. where we should be outsourcing and where we should be building in-house with agile techniques.

Applying different methods to a map

This is precisely what James did, understanding the context and use of appropriate methods. It’s how he delivered the project on budget and on time. He is not the only one; there have been many projects before and since.

Of course, we can go further. We can start breaking the project down into smaller groups and continuing to apply appropriate methods to determine what parts we can turn into a LOT structure for outsourcing to a market through a detailed specification, what we need to build in-house on a time & material basis and where we need to focus on off the shelf products or partnership or maybe even a LOT contract but with a different focus such as outcome rather than specification.

As an example, I’ve done this in the following map. This is your starter for ten, a point of conversation on how we manage something:-

Breaking the project into appropriate contracts

Now that I’ve shown you how to do this let us return to our earlier example and demonstrate what usually goes wrong with projects.

Why do projects go so wrong?

We usually compound this mess with a fatally flawed contract, needing to understand users, their needs, the components involved, the methods required, and failing to challenge what is being planned. This is so common that I would not view 80% of projects failing as a problem but as the norm. Instead, I view the 20% succeeding as a remarkable feat of human achievement. Somehow, they succeed despite every action we take to cause them to fail. Heroic stuff.

To demonstrate the contract problem, let us take one of the LOTs from our original proposed contract structure. In this case, I will take LOT 1 — Engineering.

LOT 1 — ENGINEERING

Now, let us overlay that LOT onto the map we created.

LOT 1 overlaid on the map.

What we are trying to do is to specify in detail the entirety of LOT 1 before putting it out to tender. However, there should be an obvious problem. Part of LOT 1 (the more commodity elements) can be defined and specified, but many of the project components are towards the uncharted space, which means we are still learning. These parts can NEVER be specified precisely because they are changing; they are uncertain by nature.

By trying to create a specification around LOT 1, I have made a cast iron guarantee that there will be massive amounts of change and, hence, cost overruns. No amount of promising to specify future projects better will overcome the issue that you can’t precisely specify the uncertainty. The problem is the contract (see map).

LOT 1 guarantees massive change control costs.

Naturally, this almost guaranteed failure is only compounded by other faults within our purchasing systems. These include:-

1) A tendency to focus on costs alone. 

While it might seem prudent, it will drive vendors to use your projects as training grounds for their people, who are put into more lucrative projects. You can often spot this if you have access to the GitHub of your project by the rapid turnover of people.

2) An assumption of talent. 

For some bizarre reason, the idea often exists that a vendor will have done this thing many times before. That will certainly be true if you’re talking about a commodity component such as computing provided by a utility cloud like AWS. But if your project is a complicated structure spanning components from genesis to commodity, your assumption of talent and expertise can rapidly be faulty. They can easily be less capable than your own people.

3) Shifting the risk to others. 

Whilst using an “approved” contractor and an “approved” process will reduce the political risk for yourself by providing someone else to blame, this does not mean it reduces risk to the company. If you keep failing despite repeating the same process, question whether better specification is the answer.

Wrapping it up

This process I’ve outlined above has been successfully used on several projects for over 15 years. There is no magic here, no secret sauce, and nothing too taxing because those six simple questions are at its heart. Anyone managing a project should be able to provide a reasonable, though never perfect, answer.

These questions are my simple tips for managing any project.
1) “Who are the users?”
2) “What are the users’ needs?”
3) “What capabilities do we need to meet those needs?”
4) “What components do those capabilities need?”
5) “How evolved are these components?”
6) “How are we managing these components?”

Now, as I said, this is a fundamental article. There are many paths to failure, but if you get this lot wrong at the beginning and end up with a contract structure based upon specifying that which cannot be specified, you’re likely heading towards a costly mistake.

Additional notes — Graph versus Map

For those who don’t understand the difference between a graph and a map, the following images should help. The top three images are all graphs, and they are the same. They each contain three nodes connected by two relationships. You can rotate the components by any degree you wish and remain identical.

Graph versus Map

However, the bottom three images are all maps and completely different. If you rotate them, they also mean something else. The distinction between a map and a graph is that in the map, the space has meaning. This is why, with a map, you can’t just move a component (keeping the relationships the same) and expect the map to have the same meaning. It’s also why they are great tools for understanding territorial, economic, social, technological or political landscapes.

Almost everything you’ve ever seen in business that calls itself a map is instead a graph:- mind maps are mind graphs, business process maps are business process graphs, etc. What gives space meaning is the anchor (i.e. the compass or, in our maps, the user) combined with the position of pieces (i.e. this is west or east of this, or in our maps that this is higher up the value chain than that) and consistency of movement (i.e. north is north or in our maps, this is more evolved than that).

I am occasionally asked how to combine Wardley Maps with Cynefin. They are complementary tools, not a replacement for each other nor something that can be mashed into a "holistic" view (except in the mind of DALL-E which kindly created the image which makes no sense whatsoever). They explore a problem space from different viewpoints and both are useful in their own right and should be used together. To explain I'll use an example.

The following is a very simple map, built with onlinewardleymaps that has a user expressing some thing that they need which is fufilled by some capability to meet the thing the user needs. That capability is represented as a pipeline because, in this case, there are multiple choices to fulfil that need. The choices are products from Competitor 1, Competitor 2 and Competitor 3 (see figure 1).

Figure 1 - A basic map of user with needs and multiple solutions to that need

There are few things to note with the map. 

1) Maps represent a chain of relationships. Normally we describe this as needs as in This needs That. Needs are just a form of relationship and there is no reason why you can't use other language to describe that relationship such as expresses, fufilled or constrained by. If it helps explain the landscape you are looking at to others, don't be afraid to experiment.

2) Maps have logical ANDs. For example, if we explore down the chain of Competitor 3's solution then we find that it contains multiple components i.e. this capability from Competitor 3 needs thing AND needs another thing (see figure 2)

Figure 2 - Maps contain logical ANDs.

3) Maps have perspectives. That is true even within a map. Hence the user of this capability might not be concerned with the components that make up the capability, whereas the provider is. Often, we stop mapping a chain at the point we have no influence or control over. As a rule of thumb it's not a bad idea to explore both up and down the chain (outside of your normal areas of influence) because you will often find that what the user describes as their need is not their actual need, and understanding your supply chain and the risks within it can help mitigate against shocks. Just ask all those manufacturers who have ignored their supply chains and then hit Brexit, COVID and the Ukraine war.

4) Maps have logical ORs. The pipeline in the map above represents a choice. You can choose either the solution from Competitor 1 OR Competitor 2 OR Competitor 3. This is not necessarily an exclusive choice i.e. you could have a bit of Competitor 1 and a bit of Competitor 2. For example, if the pipeline is power then you might use a bit of nuclear and a bit of solar. Nuclear OR solar would be your choices.

5) The components in a pipeline are all independently evolving. The pipeline doesn't say that Competitor 1's solution evolves to become Competitor 2's solution but that the three competitive solutions are at different stages of evolution. Ideally, you would represent the entire pipeline (where the square box is) as the most evolved stage of the entire market. Sometimes you don't, but then you are conveying that the market is far less evolved than it should be, e.g. 100s of CIOs custom building ERP in identical ways, making consultants wealthy when, in reality, the entire space should be a commodity.

6) There may be distinct and shared components. If we explore down the chain of both Competitor 1 and Competitor 3's solutions (I'll provide the map here) then we might find common components as well as unique items. For example, our Competitor 1 solution requires expensive consultants. The reason why I highlight this is to point out that the solutions by the competitors to provide the same capability may be fundamentally different (see figure 3).

Figure 3 - Map of distinct and shared components

If we explore those solutions in more detail (these maps are purposefully trivial), we may find many components involved. Tudor Girba (who runs Feenk) spends his life trying to make systems explainable. To show the problem, I'll switch to a graph format to show one system which provides a set of capabilities. (see figure 4)

Figure 4 - A graph example of a system

In our map, we said we had multiple possible solutions to provide the capability. So, sticking within the graph format, this is an example of multiple systems providing the same capability (see figure 5).

Figure 5 - Graphs of multiple systems providing the same capability

Whilst each system is complicated (having many components operating in a defined and known manner), the "right" solution is still emerging. This means the problem space itself is complex. Within that one pipeline you can have multiple complicated solutions to a complex space which is still emerging. Those are terms from Cynefin, and if you want to know more about that subject then talk with Dave Snowden.

 

The point I want to make is you can't simply transport Cynefin terms onto the evolutionary axis of a map, i.e. you can't substitute custom and product for terms like complex and complicated. It doesn't work like that. Also, when you are mapping, you should keep Cynefin in mind. It's a useful mental framework.

Every time you feel the urge to mash these frameworks into one all-encompassing ubermensch framework then just look at the DALL-E picture provided (from a prompt of mixing Wardley Maps and Cynefin) and stop. They are different but complementary. A diversity of viewpoints is not a bad thing.

Figure 6 - DALL-E's representation of a Wardley Map with Cynefin.

So, how do I know which of those competitor solutions to choose? Well, that's a topic for another post. It's enough to know that you can map multiple options.

Follow ons 

If you want to know about Cynefin, talk to Dave Snowden 

If you need help understanding what systems you have, talk to Tudor Girba

If you want a mapping tool try OnlineWardleyMaps and if you use it, then think about becoming a patron. It is a community tool.

If you want to learn more about mapping, why not join us at Map Camp.

How to organise yourself - the dangerous path to Explorer, Villager and Town Planners

Explorers, villagers and town planners (EVTP) is a system for organising a company that is having to deal with constant change due to an evolving environment. It's over 18 years old, it's a small part of the concept of mapping and it has been used successfully in several companies, BUT it is a difficult path to follow. I used to call this system - pioneers, settlers and town planners - unfortunately the colonialist overtone of those terms made it problematic for many and with good reason.

At the heart of EVTP is the idea that as things evolve then the characteristics of such things also changes e.g. the first ever computer is not the same as a highly industrialised cloud instance of a virtual server. Because of this, the manner in which we manage and deal with those things must also change as it evolves e.g. the techniques by which we manage computing infrastructure at a hyperscale today are not the same as the techniques we used in the past. To effectively cope with an evolving space, therefore, requires different aptitudes (as in skillsets such as engineering or finance) and different attitudes (as in mindsets). The three essential mindsets that we need are explorers, villagers and town planners and they can all be brilliant people.

Explorers are brilliant people. They are able to explore never-before-discovered concepts, the uncharted land. They show you wonder but they fail a lot. Half the time the thing doesn't work properly. You wouldn't trust what they build. They create 'crazy' ideas. Their type of innovation is what we call core research. They make future success possible. Most of the time we look at them and go "what?", "I don't understand?" and "is that magic?". In the past, we often burnt them at the stake. They built the first ever electric source (the Parthian Battery, 400AD) and the first ever digital computer (Z3, 1943).

Villagers are brilliant people. They can turn the half baked thing into something useful for a larger audience. They build trust. They build understanding. They make the possible future actually happen. They turn the prototype into a product, make it manufacturable, listen to customers and turn it profitable. Their innovation is what we tend to think of as applied research and differentiation. They built the first ever computer products (e.g. IBM 650 and onwards), the first generators (Hippolyte Pixii, Siemens Generators). 

Town Planners are brilliant people. They are able to take something and industrialise it taking advantage of economies of scale. This requires immense skill. You trust what they build. They find ways to make things faster, better, smaller, more efficient, more economic and good enough. They build the services that explorers build upon. Their type of innovation is industrial research. They take something that exists and turn it into a commodity or a utility (e.g. with Electricity, then Edison, Tesla and Westinghouse). They are the industrial giants we depend upon.

Now we have the basic idea: why should we implement this, and how do we do that? Well, the answer to the first question is - don't implement it. The process is not easy and you will fail if you don't follow every step. The only reason you would consider implementing the structure is if your organisation is so messed up with infighting, inertia, and inability to change that when compared to your competitors then you are seriously worrying about the organisation's future. In all other circumstances, keep whatever organisational structure you have "as is" because nobody enjoys a re-organisation except leaders who want to feel they are doing something and management consultants who get paid for it. Leave the org alone.

If you really must change the organisation, then these are the steps you have to take.

Step 1 - Principle
Take the following principles listed in the doctrine table (figure 1), gather a diverse group of people in your organisation and ask them, "How good are we at these?". Get them to vote on the table, add "red" or "green" or "blue" circles or squares or stars for things that you are good or poor at. Just make sure you create a label for what the symbols mean (see figure 2)

Figure 1 - The doctrine table.

Figure 2 - A hypothetical filled in table (I'm not sharing actual client's information).

The purpose of filling out the table is just to give you an idea of what state you are in and where you need to focus. In practice, 30-40 people spending 30 minutes filling out the table is enough to give you an idea. It's also worth spending an hour discussing the results with the group. The conversation is usually the most enlightening part. However that means you could have wasted as a group a total of 60 hours work on doing this, which is a lot but it's better to do this first and decide that you're ok and don't need to go further rather than pursuing the rest of the steps.
 
Step 2 - Improving Awareness.
This is the most time-consuming part. It's where we start at the bottom of the doctrine table, fixing every principle and working your way up. Let us assume that you're hopeless at every one of those principles which is quite common with organisations today. One fast track method of introducing principles is to use Wardley Maps.

Whenever you build a Wardley map, the first thing you need to do is identify the users. This is good for the map and it's also one of our basic principles. The users - whether it's public or the business or government regulators or all three or something else need to be marked on the map (see figure 3) as they are the anchor around which the map is built. Rather unimaginatively, I've added one user to our map called users.

Figure 3 - Know your users.

Now you have your users, you need to work out what their needs are. These you add to the map (figure 4) and fortunately, that's another principle ticked off. I know I'm a bit blase about this and actually getting to understand your user needs involves tasks like talking to them (you'd be gobsmacked at the number of companies who fail at this). I know it takes work.

Figure 4 - Understand your user needs

Of course, meeting those needs requires many components, i.e., an entire supply chain (of physical, technological, data and practice components) is necessary to make it happen. Since those components are all evolving we need to do several things. We need to understand what the components are, the relationships between components, how this connects to use needs, and how evolved those components are. How you manage, purchase, finance and build a totally novel and new concept that has never been done before is radically different from how you manage, purchase, finance and build a highly industrialised commodity. If someone says to you that "we should use agile everywhere" or "we should use six sigma everywhere" then they are either inexperienced or a management consultant trying to flog you their latest fad. Either train them or show them the door.

To recap, we need to understand the details and what is being considered (how evolved this). I've added that to figure 5. This is a Wardley Map.

Figure 5 - Understand the details and know what is being considered.

 

 

All maps are imperfect representations of a space but they enable people to expose their assumptions in a manner which allows others to safely challenge. I say safely because most organisations run on stories whilst telling everyone that great leaders are great story tellers. When you challenge someone's story, you're actually telling them that they are "not a great leader". People tend to get defensive at this. By putting the story into an imperfect map, I can challenge the map without challenging the person. I can say, I think this map is wrong. It might be missing a component, missing a relationship or having a component which is considered less evolved than it really is.

In figure 6, I'm challenging where we've placed app certification. You probably won't believe this, but in 2023, we still have organisations custom-building their own private clouds in a world where finally, most people have accepted that the public cloud is a utility.

Figure 6 - Challenge assumptions

When it comes to challenge, the cheat sheet for mapping can be helpful. Simply look down the list of properties, marking off each one for the component and that should give you an idea of how evolved it is (see figure 7)

Figure 7 - Cheat Sheet

Building a map is relatively simple process that gets easier with experience - understand the users, their needs, the components involved (SBOMs of Software Bill of Materials will help), how evolved the components are and then challenge the map. You can even get ChatGPT4v to help.

However, with any large enterprise then you're going to have a lot of maps and those maps are dynamic because they exist in a constantly changing and evolving landscape. If you try to map out the entire landscape before you do anything else - you will fail. It's like painting the Forth Bridge, a never-ending task. Which means we need to take an iterative approach to mapping.

The best way to do this is to create an Intelligence Function (or what I called Spend Control in UK Gov - bad name, my fault, don't repeat that). Let us start by asking a question. If you can map a system in a few hours, then what scale of project do you think it's worth spending those few hours understanding the users, their needs, the components involved, how evolved the components are before starting on the project? Pick a figure - a £1M project, a £100K project, a £10K project or every project? I suggest starting at £100K to begin with, you can change it later. Whatever figure you decide is your limit.

You now need a bit of policy. What you're going to do is create an Intelligence Function in your organisation and introduce the policy that any project over your limit must be mapped by the group building it and that map must be taken to the Intelligence Function for challenging before building of the project starts. People will complain. They will ask why do they need to do this. You just simply need to say "If you're spending £100K on a project, I just would like us to understand who the users are, what their needs are, what components are involved and have someone challenge it before we begin. It's worth the few hours". Many will still grumble. Be firm.

I will warn you now that a lot of politics will be involved. People will try to find exemptions; they don't want to be challenged in any way, and they certainly don't want to expose that they are spending £100M on a project that they have no idea what their users or user needs are. To help reduce the political pressure, make it clear that this is only for new projects, new re-compete, and new upgrades and doesn't affect the existing pipeline. Eventually all that stuff will come through your Intelligence Function but let time work its magic.

The second problem is your Intelligence Function is going to be overwhelmed. That's okay; let them challenge what they can and allow other projects to pass through with a "no comment". Over time, you'll need to staff it up appropriately.

Lastly, it's an Intelligence Function. It will give advice on the project by challenging the map. The group building the project should have the autonomy to ignore the advice if it wishes. But make it clear that this is pre-mortem challenge and all projects will go through a post-mortem learning. If the project fails because the advice was ignored, questions will be asked.

Getting this up and running is not a simple task. Give yourself a year before it is smoothly running. All the time, you'll be improving the situational awareness within the organisation of the landscape you are operating in.

Step 3 - Advice
As more maps are created, and there is less fighting over mapping and the challenge introduced, then you can extend what the Intelligence Function does. With many maps, you can start to identify duplication in projects - don't underestimate how much large organisations duplicate the same thing or the same process, often custom-building it in different ways. The record, to date, is one financial institution that has managed to rebuild risk management over a thousand times in the organisation. We don't quite know how many times because we stopped counting. Duplication of effort on the order of a hundred times or more is quite common. Be prepared to be shocked, that's the horror of looking.

With many maps, you should be able to start to spot duplication. Often you'll find the same component doing the same thing (which can be spotted by relationships being the same on different maps) but called a different name. We love our acronyms and technobabble. Finance tends to be the worst for this btw. A bit of duplication is not a bad thing (for reasons of avoiding systemic failure) but it should a conscious choice. Anyway, the Intelligence Function should be able to start not only challenging on the map itself but also suggesting that one group goes to talk to another group because they are building similar components (see figure 8).

Figure 8 - Spotting duplication.

With enough maps, you can even start to build profile diagrams and spot candidates for common services as opposed to the old-fashioned way of some executive sticking their finger up in the air and declaring we need this as a common service. The maps become both a common language and a source of data for identifying opportunities. That also happens to be two principles but for now, you can leave those until a bit later.

The other quick win you can introduce refers to methods such as project management and contracts. Since all components are evolving and we can actually visualise the components then we can apply appropriate methods to map (see figure 9 and 10). 

Figure 9 - Different Methods works in different contexts

Figure 10  - Applying appropriate methods to a map

This should stop all the management consultant led "lets agile everything" or "lets six sigma everything" or "lets [add some term] everything" fads that they love to create. If you haven't already fired all the management consultants by now, this will be a good time. If anyone grumbles just say use ChatGPT because its cheaper than ChatPPT which is what these management consultants mostly are.

This principle of appropriate methods doesn't solely apply to project management; you'll find you also need different methods for purchasing, finance, operations and even marketing.

The other low-hanging fruit is contract structure. Big outsourcing projects tend to fail because we try to cover an entire project with a single contract structure whilst that project contains multiple components at different stages of evolution. The problem is you can define the industrialised components well and hence use a very structured / rigid form of contract for those components. Unfortunately, the components in the uncharted space (e.g. the genesis of the novel and new to the custom-built) can't be defined. If you attempt to, you will inevitably incur massive change control costs. This is NOT a fault of lack of specification but instead trying to specify what is still evolving and changing. If you look at figure 10, by mapping it and applying appropriate methods, you've already neatly broken it into ten different contracts with defined interfaces for which appropriate contract structures can be applied.

Give yourself another year to get the advice aspects of the Intelligence Function up and running. OK, you might be thinking - "hang on, that's two years" - well, it is. But two years to go from a lack of understanding of users, user needs, components involved, lack of challenge combined with inappropriate methods, massive duplication and flawed contract structures to something which is reasonably sane or at least is on the path to being sane is very fast for a large organisation. Especially one that is used to executives pondering for a year or so on what to do before publishing a fairly meaningless "strategy" with the help of management consultants based on no situational awareness whatsoever.

At this point, you should already have seen visible improvements in the organisation. Just to check, it's worth re-running that doctrine table test (step 1). Given you also now have some level of visibility on the landscape and hence you can observe the environment, it's now worth talking about measurements. There are many measurements you can add such as price per transaction or delivery times or success rates. You might already be using some. Don't overload them, pick a handful and start using that to monitor progress from now on.

Step 4 - Improvement.
Two years in, you should now be pretty good at all the phase I principles in the doctrine table and have at least caught up with those lucky few organisations (and there are few) who were good at this in the first place. The bottom of the table should be looking rosy. Now, you've got the long climb up the table (figure 11),

Figure 11 - Climbing the Doctrine Table

You want to start introducing all these principles into the organisation. You want to recruit against them, reward behaviour that demonstrates them and build up slowly. Complete phase I first (if not already) and then move into phase II and then up.

During Phase II, you'll hit one principle which is Think small teams. At this point, you want to start introducing the concept of small teams built around the maps (see figure 12). 

Figure 12 - Think Small Teams

There's already a lot of good work out there on how to do this including Amazon's Two Pizza model. As a general rule of thumb, teams in the uncharted space of genesis / custom built should be 3 to 5 people but by the time the project becomes more industrialised (i.e. late product, more commodity) then Two Pizza (12 people) or slightly larger is fine. If the team is too large, use the maps to help break it down into smaller components. Use the relationships in the map (lines between nodes) to determine the fitness function (i.e. service delivery, dependencies and metrics) of each team. Do remember, that all the components are evolving. 

After about a year, you should start floating the idea of their being different attitudes (i.e mindsets) and not just aptitudes needed in each team. Don't however, do anything yet.


Step 5 - Explorers, Villagers and Town Planners.
You should be three years in, those bad old days of unknown duplication, no-one focusing on user needs, regular out-sourcing failures, management consultant fads that never worked out and the general all round strife should be past memories. Even issues like tech debt should be slowly clearing out of the organisation. When you run that doctrine test, most principles should look positive and you should be feeling pretty happy about things. If you're not, keep going with Step 4, you're not ready yet.

At this point, we will take the most dangerous and experimental step. We will re-organise the entire organisation to cope with constant evolution and change. Before you do this, consider stopping. If the organisation is doing well against competitors then take a break. Don't inflict any more change.

If you take the path, this means two things.

1) When we populate teams, we not only include the right aptitudes (engineering, finance, marketing, operations etc) but also the right attitudes (i.e. explorers, villagers, town planners)

2) We introduce a mechanism of theft.

The basic characteristics of explorers, villagers and town planners are outlined in figure 13

Figure 13 - Explorers, Villagers and Town Planners (EVTP)

The way it works is as follows. You create a parallel structure to the company which consists of pools of explorers, villagers and town planners. You allow people to select their own attitude and to change if they wish to. Then, when new projects appear, you populate the cells with not only the right aptitude but also attitude (all explorers together or all town planners together, etc). Let that bed down for a little time.

Then you introduce a system of theft. You allow teams of villagers to declare they are taking over some project run by explorers in order to turn it into a better product. You allow teams of town planners to declare they are taking over some product run by villagers in order to turn it into a utility-like service. As this starts to grow, you dismantle the rest of the organisational structure into the pools and introduce guilds across all the pools, i.e. guilds of engineers and guilds of finance (See Figure 14).

Figures 14 - Pools and cells.

There will be a period of readjustment and chaos as you re-organise. This is not for the faint hearted, and if you have any doubts, keep focusing on step 4.  This leap into step 5 should never be done unless you have almost all the principles in place and operating well. If you don't have those principles in place, I can guarantee you will fail.

What you're aiming for can be seen on the map. It's a constant process of team stealing from team, which replicates the evolution that occurs outside the organisation (see figure 15).

Figure 15 - Dealing with constant evolution.
 

 

Of the few who have gone down this path, the results have been remarkable and as one exec told me "the organisation found itself naturally falling into the structure". I cannot emphasise enough that there are too few examples to be confident of the structure and there is a litany of failure of those who have tried without principles in place. One of those failures was an organisation that got suckered into Gartner's bimodal nonsense and thought they could get themselves out of the mess by adding another bit. I did warn them. Don't do this. Fix those principles first.

This structure was right on the edge of what was possible in 2005 (when it was first used) and remains at the edge today.

Step 6
There's bound to be something beyond this. I don't know what it is. I've never been beyond EVTP. You will have to experiment to find it, and most of those interesting experiments are occurring in Chinese organisations. So keep an eye on organisations like Haier.