You've been given some project / business line / whatever to examine and get going. How do you start?
The following steps are what I find useful. If you're working in a large organisation then based upon experience, I can confidently state that if you follow the steps you'll be able to reduce costs significantly in the organisation over time (i.e. as ridiculous as this sounds, 90% reductions are not unheard of). You'll more effectively capture markets against competitors, you'll reduce failure, improve communication and you'll increase your speed of delivery. I don't expect you to believe me and I'm not going to waste my time trying to convince you. Talk it all with a pinch of salt but ... have a go.
This is more of a refinement for those who have already started mapping.
This is more of a refinement for those who have already started mapping.
Start with user needs. Identify what the real user needs are. DON'T start with what your needs (e.g. make profit, be successful) ... start with the end user.
2) Value Chain!
Now work out what components are needed to meet those needs and create a value chain.
3) Map!
Now map it by adding evolution. NB, I use the terms uncharted to industrialised to describe the different areas of the map (the old lingo was chaotic to linear). These different areas have polar opposite properties and everything evolves from one to the other.
4) Challenge!
Now compare your maps to other maps for other projects or lines of business in other departments. Look for the clusters i.e. in the following diagram, the everyone treating the activity in the same way - the red dots - with you standing out on a limb - the green dot. I collate my maps to find common activities in multiple maps and produce the distribution chart shown below. I find this very useful in tackling bias in a group e.g. the insistence that their ERP is a rare and poorly understood activity requiring a custom built system.
Don't skip this step - there's nothing more annoying in a large organisation than to start implementing something like a rules engine and then discover halfway through the process that the organisation has six other rules engines hidden away in different groups. This will help you find who is already building what you need.
Also try and compare your map to how competitors treat actions. If you're really lucky your organisation has some form of intelligence unit that keeps tabs on this and they can do it for you. If your organisation doesn't have multiple maps, well ... that's a pity. You can still challenge by asking questions such as how are we treating this, trying to find areas of efficiency etc. Suggest to your executives it might be a good idea for the company to learn about situational awareness.
Don't skip this step - there's nothing more annoying in a large organisation than to start implementing something like a rules engine and then discover halfway through the process that the organisation has six other rules engines hidden away in different groups. This will help you find who is already building what you need.
Also try and compare your map to how competitors treat actions. If you're really lucky your organisation has some form of intelligence unit that keeps tabs on this and they can do it for you. If your organisation doesn't have multiple maps, well ... that's a pity. You can still challenge by asking questions such as how are we treating this, trying to find areas of efficiency etc. Suggest to your executives it might be a good idea for the company to learn about situational awareness.
5) Adjust!
Now adjust your map accordingly. Many of the things you were planning to build are already built by others (the red dots), so use them. Some of the things you were treating inefficiently, so change it. If you're lucky then some of the components you're going to build can also be provided to others e.g. a more commodity form of an existing act.
If unfortunately you don't have maps of other departments / groups or any intelligence function then you won't know what others are really doing other than by going around and asking people. This is incredibly tedious, so try and encourage them to map in future as it'll help find stuff.
6) Think!
Now add a bit of strategy. Since you can see the environment then you might as well take advantage of it e.g. commoditise some things, create ecosystems, exploit inertia or buyer / supplier relationships, anticipate others moves, try to differentiate, there might be unmet needs ... whatever. Lots and lots to choose from (the wheres).
Try and determine why this route over that. Ideally your organisation will have an overall map with the high level strategy defined. Use this. Look at competitors, what their likely moves are, how you can manipulate the market to your favour. Again, if you don't have an intelligence unit or maps then you're a bit stuck on this. Still, it's better to start somewhere.
Tools like SWOT are perfectly useful for examining an individual where however use the maps and all the different points of attack to determine your overall play.
Once you've worked it out, mark up the map accordingly. This intended strategy needs to be shared with all parts of the organisation as others will be able to take advantage of your moves i.e. your move to build a commodity service might enable another part of the organisation to now build something they need.
7) Methods!
Now you have an idea of where you can attack, why you're going to attack one route over another, what the user needs are, what components are involved, what you already have or already use in the organisation (avoiding duplication), likely competitor moves etc then we can get onto the how. Treat the system as small components, don't try and treat it as one thing by applying single size fits all methods. Remember the characteristics of activity (and practice, data and knowledge) change as they evolve and so multiple methods are needed.
8) Simple!
Now, use those FIST principles (Fast, Inexpensive, Simple and Tiny) to break up the system into small teams. Any time a team looks like it's going to get bigger than twelve people then break it down again.
9) Evaluate!
At this point, you've probably done a lot of work ... maybe as much as a whole day (unless you've had to go around different groups finding out what they're doing because no-one has maps). Give yourself some applause.
You'll understand the landscape, you'll know your user need, you've got an idea of where you can attack, some ideas of potential competitor moves, you've determined why one route (or multiple routes) over another, you've even got an idea of how to build the whole thing without duplicating etc. You're in pretty good shape but you're not done.
Now, you need to determine whether this is financially viable and whether we can play this game. Using the map, estimate some of the costs, determine your business model and fill out a business model canvas or something like it. Most of the information you'll need for this (e.g. key activities, partners, resources, value proposition, potential revenue streams etc) you should have already discovered on the journey to it but give yourself another half day.
At this point, I normally have a map of the environment (possible sub maps), a strategy based on the multiples wheres (with often some supporting SWOTs of individual wheres - many of which get rejected), a business model canvas for my plan of attack and a pretty decent idea of how to play the game.
Now, if for whatever reason the current approach is not financially viable (e.g. some of the components are too expensive) then you can go back and look at the strategy i.e. maybe we should commoditise those components first or save the play for a later day. Do remember that eventually components will commoditise due to supply and demand competition, hence what is not viable today might become viable tomorrow. The map alone will be useful to other groups, so share it with the rest of the company.
Approval (i.e. any need to gamble investment) is hopefully a relatively quick process given it's easy to challenge a map and you have all the supporting information (e.g. BMC, SWOTs, comparison to competitors etc). Most of the time I've found the usual response to be "this is so obvious why is no-one else doing it?" which brings its own challenge.
At worst, you should find that you're spending two days on this entire process but remember, those maps aren't wasted effort as others can use them. If you're spending more time than this on getting to an approval state then either :-
a) You lack experience in mapping out environments - that's ok, you'll get quicker. Don't try and create perfect maps, there's no such thing.
b) There's a lack of maps elsewhere i.e. you're spending too much time trying to find out what others are doing. This could add weeks to the process in a large organisation and it's highly inefficient. Try and encourage others to map, it'll help you find the duplicates. One of the worst examples I know is of one organisation with over 120 different implementations of the same thing in different groups / functions and departments. Though, for totality of duplication and uselessness, it is beaten by another that has managed now to reduce their application estate from over 8,000 applications to slightly under 700. Yes, 87% of the estate was pointless. Of course that was obviously great for vendors and sucked for the company. As a rule of thumb, in any large organisation then I'd ask how many instances of this thing do you know of (e.g. the one you're planning to build and maybe the one other you know about of the top of your head) and whatever you say, I'd multiply by 10 - there's always vastly more duplication than you realise.
c) You've no intelligence function and so you're trying to learn basic economic lessons, competitor moves etc. Always a nuisance, this can add further weeks to the process and without maps then you have no way of recording what works and what doesn't. If necessary, set yourself up as the "intelligence" unit and get everyone else to send their maps to you.
d) Determining strategy is hard - this is normal. Most people have no real experience of strategic play having been bought up in a business world which relies on copying others and little to no situational awareness. It takes quite a bit of practice to get good at this and certainly if you're playing strategic games at a high level (i.e. overall company strategy on a national scale) then this can take a few days to a week (though that's a bit of overkill). I'm afraid it can take you years to get good but don't panic, you're playing usually against others who have little to know situational awareness hence even basic moves like "fool's mate" work. You've got to start practicing and so this is as good a time as any.
e) The approval process is slow. There's not much excuse for this, ask why?
The other line which comes up is it's complex or the line of business is complex. That's almost always complete gibberish and is more a signal that people don't want to think about it. Mapping tends to expose people to hard questions and that's not always popular.
Now, once you get approval then you've got everything you need to form your teams, fill them with the right sort of aptitude and attitudes. Get your teams to put up kanban charts and just get on with it. They should all now understand the landscape, what's available, the strategy, what methods are best suited etc etc.
11) Iterate!
Remember keep an eye on the map, watch for competitor moves, make sure teams are kept small etc etc.
--- tools
The mapping technique is Creative Commons 3.0 Share Alike. If you need a tool to help you map, well ...
a) The LEF (Leading Edge Forum) has a free mapping tool available online. It's not open source yet but that'll be announced soon enough.
b) The Wardley Maps Group has an open source tool available. I've no involvement with this group but I'm absolutely delighted they are they doing this and taking the spirit of Creative Commons to heart.
c) Lots of people just use pen and paper, Visio or equivalent.
--- books and variations
There's three books which refer to mapping. The excellent Digitizing Government by Alan Brown, Jerry Fishenden and Mark Thompson. Also Jez Humble includes it in Lean Enterprise which I've not read yet but I'm looking forward to it.
The WardleyMap crew have also stitched together a community book based upon many of my old blog posts on the subject and there's a community effort to make it better.
The WardleyMap crew have also stitched together a community book based upon many of my old blog posts on the subject and there's a community effort to make it better.
There's also this blog which has mapping scattered throughout it.
There's also variations of the map concepts e.g. 18F has an interesting take in their post on 'How to Use More Open Source in Your Next Federal IT Acquisition'
--- notes
This post is an update on the "basics repeated again". I've added the comparison to other maps more explicitly (this is an incredibly useful first step) and simplified the management of the different methods into one single step.
