Showing posts with label Mapping. Show all posts
Showing posts with label Mapping. Show all posts

Saturday, August 15, 2015

The Analysis

Ok, this post provides a quick analysis of the Scenario. As a guide, this sort of analysis should take about 30 minutes. To get the most out of this exercise, read the scenario post, write your plan and then read this analysis. In a final post, we will go through gameplay.

The Analysis

First, lets start by creating a basic map. Our users are data centre operators, they have a need for a mechanism of improving Data Centre efficiency in electricity consumption, we have our software product which is based upon best practice use of an expensive sensor that we purchase and a custom set of data. This is shown in figure 1.

Figure 1 - Initial Map



In this exercise, I'm going to slowly build up the map. Normally, I would just dive into the end state and start the discussion but that'll be like one of those "it's therefore obvious that" exercises in maths which often confounds others.  

First of all, I'm going to add some bits I know e.g. we anticipate an opportunity to sell into Brazil (I'll mark as a red dotted line) and we have a US software house in our market selling a more commodity version as a utility service (I'll mark as a solid red line as it's something that is definitely happening). From the discussion with the head of sales (who was rather dismissive of the US effort) and the strategy, I already know we're going to have inertia to any change, so I may as well add that in (a black bar).

Figure 2 - Brazil and US.


However, we also know that the US version provides a public API and has a development community building on top of it. The US company is also harvesting this, probably through an ILC like model. The consequence of this, is the US company will start to exhibit higher rates of apparent innovation, customer focus and efficiency with proportion to the size of their ecosystem. Those companies building on top of their API act as a constant source of differential for them. I've added that in the figure below.

Figure 3 - ILC play.


Given the US company growth last year and that a shift from product to utility is often associated with a punctuated equilibrium, I can now take the figures and put together a P&L based upon some reasonable assumptions. Of course, we're missing a lot of data here in particular the development cost of the software etc. However, we'll lump that into SG&A.

Figure 4 - P&L and Market.


Ok, so what I now know is that we seem to be a high gross margin company (i.e. a juicy target) and a good chunk of our revenue is repeating software licenses. If this is a punctuated equilibrium (which seems likely) then I expect to see a crunch time in 2020 between us and our US company as we will both have around 50% MaSH. Unfortunately, when that happens then they're likely to have higher rates of efficiency, apparent innovation and customer focus due to their ecosystem play. Furthermore I'm going to have inertia to any change probably due to existing practices, business and salespeople compensation.

If I do make a utility play then I'm going to need to gain the capability to do this, raise the capital needed to build a utility and launch fast. Let us suppose this takes two years. Then I'll be entering a market where my competitor has 8 years of experience with a large & growing ecosystem and 100% MaSh of the utility business (worth £30M to £60M). I'll have no ecosystem, no MaSh and a salesforce probably fighting me and pointing out how our existing business is worth £144M to £173M. In the worst case, if I haven't explained the play properly then they could even be spreading FUD about my own utility service and trying to get customers to stick with the product.

Even my own board could well push against this move and the talk will be of cannibalisation or past success.  Alas, I know our existing business is a dead man walking. Post 2020 things are going to be grim and by that I mean grim for us. Despite the competitor only being 3% of the market, I've already left it late to play this game. I've got some explaining to do to get people on board.

Unfortunately there is more bad news. Let us look at that the other changes in the market, such as the shift of sensors.

Figure 5 - Change of sensors.


Now, we've already seen signs of inertia in our organisation to using these sensors. As the product manager says they're not as good as the old. However, we also know that as an act becomes a commodity then practices co-evolve and new methods of working emerge. Hence the future systems probably won't have one sensor in the data centre but dozens of cheap ones scattered around. Unfortunately, our software encodes best practice around the expensive product based sensor and if the practice evolves then our software is basically legacy. I've added this to the diagram below, however rather than using a solid red line (something we know is happening) then in this case I've added a dotted line (something we anticipate or an opportunity).

Figure 6 - Co-evolution


So, our business is being driven to a utility and we don't have much time. Even if we get started now then by the time we launch we'll be up against an established player with a growing ecosystem. Our own people will fight this change but even worse our entire system will become legacy as commodity sensors lead to co-evolved practice and new software systems designed around this. So along with my head of sales and marketing fighting me, I'm pretty sure I can add the product manager and a good chunk of an engineering team that has built skills around the old best practice. 

Now, if you're used to mapping then you'll have spotted both the punctuated equilibrium and the danger of co-evolution. As a rule of thumb, these forms of co-evolution can take 10-15 years to really bite (unless some company is deliberately accelerating the process). Hence, even if we somehow survive our current fight in the next five years, we're going to be walking smack bang into another one five years later.

Of course, at this point I need to start to consider the other players on the board e.g. the US competitor. They're already providing a utility play, so we can assume that they have some engineering talent in this space. This sort of capability means they're likely to be pre-disposed to building and using more commodity components. The chances are, they're already thinking about the commodity sensors and building a system to exploit this. That could be a real headache. I could spend a couple of years getting ready to launch a cloud based service based upon the expensive product sensors and suddenly find I'm not only behind the game but the competitor has pulled the rug under me by launching a service based upon commodity sensors. I'll be in no man's land.

The other thing I need to look at is that conversion data issue. I know it's evolved to a product but it could easily be pushed to more of a commodity or provided through some API and play some form of open data ecosystem game on me. I've shown this in the following diagram.

Figure 7 - Data Ecosystem


I've now got a reasonable picture of the landscape and something I can discuss with others. Before I do, let us check the proposed "Growth and sustainability in the data centre business" strategy.

First up was expansion into Brazil. This will require investment and marketing but unfortunately we're not dealing with the issues in our existing market. At worst, we could spent a lot of cash on laying the groundwork for the US company to chew up Brazil after they've finished chewing us up. Still, we need to consider expanding but if we do so in our current form then we're likely to lose.

Second was building a digital service including a cloud based provision for our software system that enable aggregated reporting and continued the licensing model. Ok, one of the killer components of the US system is the API and the ecosystem it has built around this. We could easily invest a significant sum and a few years building a cloud based service, enter the market and be outstripped by the encumbent (the US company) because of their ecosystem and even worse find our entire model is now legacy (because of co-evolved practice). I know it's got the word "digital" and "cloud" in the strategy but as it currently stands then this seems to be a surefire way to lose.

Thirdly, the strategy called for investment in sales and advertising. Well, we've plenty of cash but promoting a product model which as it stands is heading for the cliff and may become entirely irrelevant seems a great way of losing cash.

Lastly, we're to look into the use of the data conversion product. Ok, this one doesn't seem so bad but maybe we should drive that market to more of a commodity? Provide our own Data API? 

On top of all this, we have lots of inertia to deal with. Now that we understand the landscape a bit better then we can craft a strategy which might actually work. Of course, I'll cover that in another post. However, in the meantime I'd like you to go and look at the scenario, look at your original plan and work out how you might modify it.

Happy Hunting.

A scenario

A scenario for you to run through. Have a think, write down your answers and later on I'll add a post as to things you should have considered.

The Scenario

You’re the CEO of a UK based company serving the European Market. Your company produces a software system that monitors a data centre's consumption of power in order to determine whether power is being used effectively. The system involves a proprietary software system which runs analytics across a data from a sensor that is attached into the data centre. The sensor is a highly expensive piece of kit which monitors both the electricity input into the building, the temperature of the building & airflows. The analytics software is based upon best practice for use of this sensor. The sensor itself consumes conversion data that your company creates.

You’re profitable with a revenue in excess of £100M p.a., a net margin of 15% and an annual growth rate of 20%.  You have a healthy cash flow and reserves of around £25M.  The process of setting up a new client involves installing a sensor, setting up the equipment and a two year license fee for the software. Around 40% of your revenue comes from re-occurring license fees and 85% of the initial 1st year costs for a client is related to the purchase of the sensor.

Whilst you have some competitors in Europe, most of these are custom built solutions. You’re the only with a software product. There’s a more developed market in the US and even a software as a service offering which uses the same sensors but the software is sold on a utility basis rather than a license fee. The US solution also provides cross company reporting, industry analytics and a public API, something which your system does not. However, as your head of marketing points out, the US competitor (a much larger company) has been operating in Europe for almost 7 years and represent less than 3% of the market though their CEO claims they are growing rapidly and doubled in size last year. There are a number of other company products built on your competitor's APIs and a fairly active development community on this. However your head of sales chimes in that we rarely come across them in competitive tenders and in any case there have been some blog posts about your competitor 'eating up' the business model of some of those products by adding similar capability into their own system. The head of sales points to data showing that in the European market, your company has around 40% MaSh (which is holding steady) and the current market represents 70% of the total applicable market. Both the head of sales and the head of marketing agree we should focus on increasing our MaSh (market share) by focusing on sales and advertising.

Your head of operations points out that there is a range of new, more commodity like sensors that has been launched in China by an extremely large and well respected manufacturer. They’re far simpler, vastly cheaper (about 1/100th of the price) and highly standardised. However, they are also basic and lack the sensitivity of the sensor we use. The product manager points out that we have attempted replacing the expensive sensor with one of these cheaper versions but the performance and analysis was severely degraded. The product, operations and sales manager all agree that these cheaper sensors aren't upto the job. In the conversation, the product manager points however to another opportunity. One of the significant costs in the system is in the conversion data which requires extensive testing and modelling of various bits of kit within the data centre.  Whilst this is done in-house, there is now a product available on the market which offers this conversion data. It’s not as good as our data at the moment but the product is vastly cheaper than our in-house operations and we could therefore reduce costs here.  Your head of marketing supports the idea as there is some recent evidence that despite the benefit (in terms of energy savings through efficiency) that the system allows, there is some concern over the high cost of the software in the market. The product manager believes we should investigate though this was faced with some resistance from both the head of operations and the head of IT. You do not feel you have a deep enough technical understanding to answer this.

On the revenue side, the head of sales points out there is a growing market of data centres in Brazil which currently no-one is providing a solution for. They consider this to be a highly attractive future market and would like to investigate. Your head of strategy also agrees. 

The new strategy which is focused on a vision of “Growth and sustainability in the data centre business” has highlighted a number of possibilities. First is expansion into overseas markets such as Brazil. Second is provision of a more digital service including a cloud based service for provision of the software (enabling aggregated reporting) but provided on a license basis in order not to create conflict with the existing model but also to counter any threat from the US system.  Thirdly, we should undertake a significant marketing campaign to promote our solution in the existing market. Lastly the report focuses on efficiencies in operation including investigating the use of the data conversion product that is available. 

What do you do?

Add your 'answers' in the comments below.

Once you're done, then you can move onto The Analysis

Wednesday, August 12, 2015

On the future.

I often talk about the importance of situational awareness. The technique I use for this, is known as Wardley mapping and you can read about it on CIO magazine. If you're new to this then the rest of the post won't make sense and so I'd advise you to save some time. Tl;DR it's complex.

Once you have a map, it becomes fairly easy to see how a market will evolve. There are numerous common economic patterns from componentisation to co-evolution to inertia along with various forms of competitive gameplay that can be used to manipulate this change and create an advantage. With a map (which provides position and movement) of an economic space you can examine the line of the present and work out points to attack. From here, working out strategic play (i.e. why attack here over there) is fairly easy. I've summarised this in figure 1.

Figure 1 - Determining future from now.


With reasonable situational awareness you can anticipate certain changes and prepare for them through scenario planning. You can avoid getting caught out unnecessarily. This is more than enough (along with operational efficiencies through removing duplication and bias) to compete against most companies. However, there are some more advanced techniques. 

When we look at a map, certain aspects of change are more predictable than others. I've provided a list in figure 2.

Figure 2 - Predictability of Change.


For example, existing trends (i.e. stuff that is happening) are fairly obvious in terms of what (i.e. the trend) and when (i.e. now). There's little advantage in this stuff despite it filling up endless management journals. At the same time there's the unknowable e.g. genesis of a new act or impending product to product substitution. The best you can do here is scan the environment, notice it's happening (i.e. it's become an existing trend) and react accordingly. You can't anticipate this stuff i.e. Blackberry couldn't anticipate the iPhone would appear and disrupt it.

However, the knowable stuff is the most interesting because here you can create an advantage and you can anticipate what is going to happen (but not when) or vice versa. In certain special cases you can do a reasonable job of both through the use of weak signals but I'll get onto that.

For example, when something new appears we can anticipate that if there is competition (supply and demand) then it'll evolve! We can even specify the stages of evolution (for activities, practices, data and knowledge) e.g. an act will evolve from genesis to custom built to product (+rental) to commodity (+utility). We can state how its properties will change (from the uncharted to industrialised) and how competition will drive this. I even know that on average it'll take 20 - 30 years to go from genesis to the point of industrialisation. We know an awful lot about the what

Unfortunately we can't predict when the state changes will occur with any detailed level of precision as this depends upon individual actors actions i.e. I know bio-printing will eventually become a product and then a commodity component but I don't know who will make this happen or precisely when each of these state changes will occur.

However, there are some special classes of change. For example, I know that any act will evolve from product to commodity (+utility). But, I also know that as it does so, past product companies (suffering from inertia built up during a time of relative peace between product vendors) will be disrupted by new entrants. It'll take about 10-15 years for the change to become obvious and the past vendors to be on their way out. There'll be an explosion of new activities built on top of this commodity (a time of wonder) and a change of practice related to the act (co-evolution). There's an awful lot I can say about the what of this product to commodity (+utility) state change, which we describe as a point of 'war' in the economy.

Fortunately, in this special case there's a very specific weak signal technique which I can use to narrow down the target range of when a 'war' is going to occur. I've provided some results from this technique in figure 3.

Figure 3 - Points of War


(P.S. Green is an unpredictable. Muddy brown is middling. Red are the points of war)

It's through an earlier version of the technique that I knew that compute was moving towards a utility before AWS. It's also how in Canonical in 2008, I knew we had to focus on the co-evolved practices (devops), as well as capturing the cloud market, any new activities building on top and how past vendors had far less time than they realised.

So, for example, I happen to know the 'war' in 'big data' systems is kicking off. I've actually known for quite sometime this was heading our way. This 'war' means we will see utility providers in this area (they already have launched). The 'big data' product vendors (who have inertia) will dismiss these players and declare that the new entrants are useful for development but when it comes to production you will want to talk to them. They'll probably even spread FUD.  However, in about 10-15 years the past vendors will be in serious trouble. I can even tell you that this type of change (known as a punctuated equilibrium) will catch those past vendors out i.e. in 5-10 years those vendors will be crowing about how the new entrants represent less 3-5% of the market but by 10-15 years those new entrants will be 30-50%. If you want (and I felt inclined), I could already give you a list of the dead.

This change will cause an explosion of new activities (i.e. genesis) based upon these standard components in a time of wonder around data. I know that a time of wonder will occur, I can say roughly when but of course I don't know what those new activities are (no-one does). Genesis is unpredictable but at least I can tell you to keep an eye out - new stuff will happen! There will also be new practices developing around the use of such utility services, we'll probably even give it a meme (hopefully not DataDev or DataOps or any other awful combo).

Now, if I understand my value chain then I can scenario plan around fairly predictable patterns and use weak signals to identify when it's likely to happen. I can't avoid the unpredictable (e.g. product to product substitution) any more than I can avoid the need to gamble and experiment in the uncharted space if I'm trying to create something new. But I can ruthlessly exploit the knowable against opponents who can't even see the board. If they could, they'd never be disrupted by anticipatable forms of change (e.g. cloud) because even with the inertia, you could overcome it.

For most companies however, they have little to no situational awareness which means everything bar the obvious existing trends appear to be unknowable and comes as a complete shock. These are my favourite companies to compete against and there's an awful lot to choose from out there.

Happy Hunting.

Thursday, July 09, 2015

The 100-day Corporate get fit plan

I was recently at a rather hellish event listening to a presentation on corporate strategy.  I’ll summarise it for you – “blah, blah, digital, blah, blah, agile, blah, blah, ecosystem, blah, blah innovation, blah, blah, disruption”. 

The folks around me were getting rather excited – “Did you hear that? Agile disruption!  It’s the future” - and I knew these ideas would be inflicted in an ever increasing number of internal PowerPoint meetings. Hell begets many smaller hells it seems.

The problem with words like ecosystem, disruption and innovation is they each refer to multiple things and though they have very precise meanings for specific contexts, relatively few seem to understand this or even the context their companies operate in. Instead we get meme copying, backward causality and the desire to copy others even when it’s not appropriate. “We should be like Uber” sounds exciting but I wouldn’t suggest surge pricing for funeral parlours as a way forward.

Understanding context is key to applying these ideas but such situational awareness is a rarity in corporates. The lack of it causes visible symptoms such as poor communication, misapplication of doctrine (e.g. agile everywhere or six sigma everywhere), massive cost overruns in contracts, silos, duplication, constant reinventing of the wheel and a long list of other undesirable effects.

I did want to write a post on the 61 different forms of strategic play and how to manipulate an economic environment but given the responses I’ve received from the Wardley mapping post, it seems something more basic is needed.

So, I’ve decided to write a hundred day corporate get fit plan for a newly appointed executive. This will help get you into a position from which you can start to learn and talk about strategy.  Obviously, different organisations are at different levels of fitness, so once you’ve completed day 1 then feel free to jump ahead to the appropriate level.


Day 1 – Let us be Honest

Are you a super lean fighting machine or do you just think you are? Let us find out. In table 1 is a simple checklist of things you should have. For reference, I’ve added how often companies seem to believe they have these things.

Table 1 – What you require


Let’s start with the first section, which is purpose. Ideally your company should have a scope i.e. the reason for your organisations existence, the moral imperative that others can rally around and hence the reason why people believe in you. This can often be found as ‘vision’ statements and they are quite common.

Of course, once you have a scope you need to examine how you interact with others and hence you need a list of transactions with others.  For reference, the UK Government has over 750 transactions from paying taxes to a license to bury a relative at sea. For reasons of prioritisation, it’s extremely useful to know what the volume and cost of each of these is. Obviously once you have a list, you can always think of other ways you’d like to interact with others but that’s future stuff. This is a get fit plan, so let us focus on the now and put those future transactions in a notebook for safekeeping. Surprisingly, it’s quite uncommon for a company to have a list of transaction with others.

I use the word transaction very deliberately here because you’re providing something to others that they value. Every transaction therefore has users. NB, there are times when YOU are the user to other companies transactions i.e. your suppliers. Don’t worry about these for the time being, your purpose in life isn’t to make your suppliers happy but rather their purpose should be meeting your needs. If they’re not then maybe you need new suppliers. 

Now by understanding your scope, transactions and users we at least have an idea of your purpose i.e. who your company really is. “We’re the best tea shop in Burmarsh providing tea and scones to members of the public” etc.

Don’t worry if you’re failing already, this is not uncommon. Many companies have a hard time describing their purpose and this is something we will try and fix in the 100 days. To begin with it’s simply important to be honest as to where you are.

We now need to look at the second section covering situational awareness. For each transaction, your users will have needs i.e. a piping hot cup of tea in a friendly and pleasant environment. We simply call this user needs. They will also have wants but that’s future stuff (scribble those in your notebook). 

It really helps to also have the user journey describing the process by which they interact with us e.g. enters building, selects tea and cake, receives tea and cake, pays for items, sits down etc. This helps us in ensuring the journey is simple, meets with the user need and doesn’t have complex and wasteful steps.

Now, each of the user needs will probably require many components to satisfy it e.g. a piping hot cup of tea needs tea, a cup, hot water and someone or something to make it and so on. Of course, those components have their own needs such as hot water needs cold water and a kettle. A kettle of course needs power. So, you can create a chain of needs focused from the visible needs of your users to the invisible components (such as power) that are required to make it happen.  We will call this a value chain on the assumption that meeting the needs of others creates value.

You can now use this value chain to create a map, I won’t go through the details of this as it is covered in the earlier post on Wardley Mapping but these maps enable you to see what is involved (relative position of components) and how those components will evolve (movement). Whether it’s a chessboard or a physical map in a battlefield, position and movement are essential for understanding the context.  For reference, I’ve simply included the map from a TV company in figure 1. 

Figure 1 – A Map of a TV company.


STOP!

Have you read that post on Wardley Mapping? If not, you really need to do that. It won’t take too long and you’ll find it essential later on. There's no point starting a get fit plan if you're going to skip essential first steps like warming up etc. You'll just cause yourself an injury.

Now, if you have maps we can assume you have some understanding of your scope, your transactions, your users, their needs, the components involved and the context. This is actually very rare in corporations, so well done. If you don’t then don’t worry, we can fix that.

The third section is doctrine.  There are a number of discrete tactics you can use with maps to remove duplication, bias, inappropriate methods and a host of other operational inefficiencies. The scale of bias and duplication in many corporates is quite staggering. To date, the worst example I know of duplication is one large global company that has 380 customised versions of the same ERP system doing exactly the same process. In terms of bias, I’ve seen horrors of customised racks using customised servers in a customised data centre for a company that really doesn’t need to run its own compute. 

I’ll cover how to fix bias and duplication in a later part of this post. Once you have this all sorted (what I refer to as stopping self harm) then you’re in a position to start learning about common economic patterns of change and applying appropriate structure. This is the point at which you not only understand your context but you’re learning from and adapting to it. This is extremely rare in corporations.

Typical symptoms of failure to learn from or adapt to the environment includes bolt on structures (e.g. adding new Chief “something” Officers for every change), meme copying others (i.e. reliance on backward causality), outsourcing failures, lots of duplication including lack of awareness of, and one size fits all methods (e.g. tyranny of agile or six sigma or lean). If this is you then you have problems with your doctrine but this probably extends from little or no understanding of context. This is all quite normal in the corporate world.

The final section is where we start to get into leadership and strategic play. However, for our 100-day plan then I will take us up to the basics of doctrine. Until you get to this point then your only strategy should be “Understand what we do, who for and why and try to do it without breaking the bank”. Everything else is meme copying and could easily cause as much harm as good.

Regarding that table, most companies start failing at transactions, disappear off the cliff at user needs and then bounce back saying “But we have lots of strategy”. That’s surprisingly common.  Let us be honest, what they have are lots of aspirational things that they think are a good idea (probably because they read an article on them) but without any context. Surge pricing for Funeral Parlours, it's the next big thing - see Uber! I’m unlikely to get you to the stage of writing an effective strategy in 100 days, however we should get you closer. So, onto the get fit plan.


Day 2 to Day 20  - Map it!

Ok, the overwhelming chances are that you’re either missing large sections of table 1 or you’re deluding yourself. Don’t panic as you’re in good company.

Now, the first thing we’re going to do is collect information but we’re going to need to create a sense of urgency around this as a forcing function. There’s a reason for the 100 day time limit for the get fit plan because if you don’t get the ball rolling in this time then corporate antibodies will overwhelm you. Yes, the organisation hates change and will resist it even when it is good for itself.

So get your senior management together and point out that you’re lacking basic information and this needs to change quickly. Use table 1 as your guide – “we don’t know our transactions, our users, what’s involved but we’re still writing strategy!” etc. Be reassuring though, just make them aware that change needs to happen and spell out a temporary purpose (you will refine this over time). 

Now, you should add in some spice – sweet and sour. 

The sweet bit is you’re going to create a small team to start collecting this missing data i.e. first identifying what transactions you do, who the users are etc. This same team will also start describing the user journey and mapping the environment. You can also announce that there’s going to be NO CHANGES in terms of budget and existing strategy … we continue as are. Hurrah!

Whilst everyone is breathing a sigh of relief and you’ve diffused any arguments over “extra work” then you introduce the sour bit. Whilst there is no change in budgets you are going to introduce a spend control process for any project or spend over a set figure. Anywhere between £50K and a £1M will do but if you’re large then start with £250K.

Now, this will cause some ructions but you can simply say “Before spending a £250K on something, it just seems a sensible idea to know who the users are, what their needs and the journey is and what components are involved. All I’m asking for is a map. Do we really not know what we’re doing so badly that we can’t spend a few hours quickly mapping it out? It doesn’t have to be a perfect map, no maps are just something we can discuss!”

There’ll be some grumbling. You’ll have to be firm and reassure them that if they can’t map out what they’re doing, you’ll send someone to help them understand what they’re doing. NB, nobody ever takes you up on this offer. Now the spend control process needs to be run by your newly formed team. Their job is simply to collect the maps, help people map and start collecting all the missing data. Make it easy.

Let it run for several weeks and make your team know that you want the entire organisation mapped as fast as possible.


Day 21 to Day 40 – Analyse & challenge.

By now, you should have a pretty clear idea of the transactions that your organisation undertakes and a good few maps. Your team should have started to collate maps together for several purposes. 

First, you ultimately want to create an overall high-level map of the business along with maps of the value chains and maps of components in the value chain where necessary.

Second, you want to generate a common lexicon within the business – a wiki is a useful tool here. You will quickly discover the same thing is described with different terms in different parts of the organisation.

Third, you want to start tackling the duplication and bias that is rife in most organisations. As a rule of thumb, in any decent sized organisation then whenever some group is doing something (e.g. building a marketing system for analysing customer behaviour) then you can normally find five other groups hidden elsewhere in the organisation that are doing the same thing.

NB, when you find lots of duplication then every group tends to have people that argue that their way of doing something is special, unique to them or what we call ‘a snowflake’. In fact, most groups tend to think that their thing is somehow different from the rest of the market i.e. they’re the only group who do mass mailing in this way and it’s what makes us unique! This is what we call bias and whilst in cases it has genuine merit, that is the rarity not the norm.

I tend to find producing an aggregated chart from the maps (see figure 2) to be a useful technique for highlighting duplication and bias. Simply take your maps, identify common points and plot them according to how people have mapped them.

Figure 2 – Aggregated View.


The aggregated view helps you determine the lexicon, the amount of duplication in maps, the level of bias (i.e. custom building that which others consume as a commodity) and how things should be treated i.e. the cluster of common points.

Now, this is the tricky part. You have to start to introduce some challenge to the process. Up until now the spend control process has been about collection but this needs to change. When someone turns up with a map, you need to point out where the components are much more commodity than they realise or where others are building the same thing. You really need to be asking whether this map is reasonable?

To begin with people don’t tend to like to be challenged. You’ll also get bluster such as “I don’t have time for this”, “We have to sign this contract now” etc. You will experience (as I have done) numerous times when someone will be arguing that you need to sign a contract today for £10 million or the world will end. Be prepared to say “no” and to explain that until they produce a map or talk to another group then the project will not proceed. Be prepared for other execs to play power games but stick to the line “If we can’t explain user needs or what we’re actually spending the money on or you can’t be bothered to not duplicate another group’s work then we’re not spending £10 million”. 

The more maps you collect, the more obvious the duplication and bias will become. This can account for huge sums of money. I’ve seen past projects go from £60M to £800K and £1.6M to £96K just by removing duplication and bias. Don’t be shocked to discover levels of waste that exceed 90%+. It’s not you’re making some sort of mistake; it’s just this level of waste exists and very few have gone looking for it in a systematic way. If you clear out the waste, it’ll give you lots of muscle when it comes to strategic gameplay but that’s why this 100 days is all about getting fit.

Also don’t underestimate inertia to change. When you say that someone’s pet custom-built system is best provided as a product or outsourced utility service then expect arguments. There are 16 different forms of inertia (shown in table 2), so be prepared. You’ll get used to them all and learn counter arguments over time. 

Table 2 – Forms of Inertia



Day 41 to Day 60 – Doctrine

In the first 40 days, you’ve been focused on improving situational awareness (i.e. maps) and stopping obvious self-harm (e.g. duplication and bias). You should be collecting more of those maps, building up a lexicon for the business and helping people communicate (maps are great for this) along with challenging what is done and helping overcome inertia. You should start to feel a bit fitter and in control but don’t get ahead of yourself. You’re not ready for strategy and gameplay yet.

What you now need to change is behaviour in the organisation and you do that through understanding. You’re going to start by explaining to the organisation why one size fits all management rarely works. You can do this by taking a map and showing how you need multiple management methods to effectively manage it. As an example, I’ve taken the media company and marked on how to use agile, lean and six-sigma (see figure 3). 

Figure 3 – Appropriate methods for a TV company


Certain parts of the map are suitable for outsourcing and other parts should probably be built in-house. Even the purchasing methods need to change. As a guide, figure 4 provides an idea of where different methods are most appropriate.

Figure 4 – A guide for when to use methods.


It’s important to realise that on the left of your map you want to be focused on reducing the cost of change. This is because components in this area will change as they are uncharted and unexplored. Hence the use of VC based approached, agile (e.g. XP and scrum) and building in-house is appropriate. Experimentation is the name of the game.

As the components evolve (which will happen if supply and demand competition exists) then your focus becomes more on reducing the cost of waste i.e. you have an idea of what is needed and you now need to effectively produce it. Techniques like Lean, MVP (minimal viable product), A/B testing and outcome based approaches are all appropriate. You might still use techniques like Scrum for development but the focus (and the artefacts) will be different. 

As the components evolve further then we’re into volume operations of good enough and our focus must become reducing deviation. Techniques like utility pricing and six-sigma will dominate. This is all about empires of scale, industrialisation and operational efficiency.

What you want to get away from is custom building a commodity in-house or outsourcing something novel and new (which will change because you’re exploring an unknown space) to a fixed price development contract with expensive penalties for change.  So start challenging those maps not only for duplication and bias but also the methods being used and expect some fierce resistance here. People tend to like one size fits all methods and hence there’s a regular outbreak of semi-religious wars over methods. Keep to the line that multiple methods are needed.

In the first days of your new regime, you've probably developed an idea of how much skill your company has and how dependent it is upon others. In many cases, companies lack the skill they need in order to challenge vendors because they’ve outsourced it all or become dependent upon analysts. The maps will also give you an idea what sort of capabilities you require. However, be careful here.

In all probability, you are going to find you’re lacking in one or possibly two skills areas and so you’ll have to bring people in. Don’t try to retrofit people you have unwillingly into these areas. If you’ve mainly got people who are good at ITIL, six sigma & strong contracts then you’re going to need these people for those industrialised components. They are really important to you in the long term and so declaring, “we need agile people” and bringing in outsiders can cause a lot of friction. What you want to avoid is creating a “them and us” situation. Be upfront and clear. Use the maps to show you need additional capabilities to bolster what you have. Explain that all parts of the map are equally important.

It is critically important to understand that you need at least three basic skill areas – those capable of exploring the uncharted space, those capable of turning a poorly worked concept into a viable product and those capable of turning a product into an industrialised component. These are not the same, and after the 100 days we will look to turn these three skill areas into a cell-based structure and start strategic gameplay. Make sure you have all these capabilities to some degree.

It’s also a good idea to start looking into your contracts and have your team mark this up on your map. Ideally, you want small, relevant and focused contracts. It’s worth reading up on FIST principles (USAF, Lt Col Dan Ward) but as an example figure 5 provides a map with how the contract should have been broken up and figure 6 provides how it was.

Figure 5 – A more ideal contract structure.


Figure 6 – A less ideal contract structure.


This map comes from a Government system and the problem with figure 6 is the contract in the middle is too broad. You’ll end up incurring expensive penalties in change control because you’ll be applying a fixed contract to both industrialised components that you can specify in detail along with components that are novel, new and changing and hence can't be specified. Unfortunately, if you only have specification documents and normal box and wire diagrams (business process maps, IT diagrams) then you don’t have a cat’s hell in chance of spotting this problem. Poor contract structure appears to be rife in most organisations.

All this time, you still want to keep building that portfolio of maps, getting people to focus on user needs, improving your lexicon, removing duplication and bias but hopefully by now you should also start applying appropriate methods, balancing the capabilities you need, avoiding the outsource everything pitfall along with using appropriate contract structures. You should notice that your organisation is starting to become more efficient and effective, a bit more fit. Are those abs I can see?

Now, we turn the pressure up.


Day 61 to Day 80 – Flow

This is an important topic but first we need to explain some basic terms related to mapping. These are: -

Position: the position of components simply relates to how things are connected and how visible they are to the user need. The value chain itself is a chain of needs i.e. this needs that etc. At the top of the value chain these needs are exposed as meeting user needs (i.e. customers) and can often be expressed in terms of the customer journey. This doesn't mean the lower components aren't essential but a user who wants a cup of tea doesn't care about the power provider you use to boil the water. They only care about a piping hot cup of tea.

Flow: whenever you look at a value chain then there are often multiple paths within it. These we call flows and along these paths travel such things as information, risk, finance and materials. Sometimes one flow is more viable than another and financial models based upon flow can be developed. Sometimes a flow may be inefficient because it'll have bottlenecks and improvements can be made. There are all sorts of important things to be considered here from inventory to capacity to variability and time. 

Movement: Unfortunately value chains aren't static. They evolve. Fortunately the process of evolution is fairly well defined across activities, practices, data and knowledge and there are many common economic patterns, weak signals and gameplay that can be used to anticipate and manage this. There's however little point in understanding the value chain and managing the flow efficiently if you are treating most of the components as custom built when the market treats them as commodity. You have to accept that everything in your value chain will evolve (i.e. move across the map) and therefore you might be efficiently managing the flow in your value chain but at the same time being ineffective because you're treating components in the wrong way. 

Managing position, movement and flow are essential operational activities but unfortunately many people fail to understand them. Up until now, we’ve looked at position and movement (i.e. the value chain versus evolution) in the guise of a map. To improve we now need to examine flow in those maps.

In figure 7, I’ve taken the TV Company map and marked on two different financial flows (one in dark blue, the other in green). One is for the content provided by Internet broadcasting and the other for content provided by DVDs.

Figure 7 – Flows in the TV Company map.


Now for both of these flows, you can create a separate financial model and then examine the flows to determine whether one path is more profitable than another or whether there are bottlenecks in one or another or both. The same process can be used for fault tree analysis to determine risks (e.g. what is the impact if our web servers are lost?) and for the flow of information and materials.

An alternative way of viewing the flow above is the use of a message sequence diagram. In figure 8, I’ve provided such a diagram for the blue flow with some examples of what you might wish to consider in terms of financial metrics.

Figure 8 – Financial Flow (Blue)



There are alternative ways of viewing these flows e.g. value stream mapping. What’s important to remember is that you have three elements to your map – position, movement and flow. You should not only be making sure you’re effectively treating things (from removing bias and duplication to using the right methods) but also that your value chains are efficiently running. 


Day 81 to Day 100 – Keep it steady

By now you should be motoring in terms of understanding transactions, what users need, improving flow, doctrine and as a consequence you’ll find that mapping helps communication through a common language (Lexicon) and format (Map) across all groups. You’ve been removing bias and duplication. You should have started to balance out the capabilities the organisation needs and even resolved some horror contracts (there’s always a couple). Provide some time to let changes settle in, these are dramatic changes. Keep using those maps, providing challenges through spend control and allow the cycle to improve.

By around Day 100, you should also be able to clearly describe your purpose. You're now ready to start examining structure, mechanisms of learning and the principles of strategic play. You're well on your way to playing the competition game with some finesse. There are at least 61 different forms of gameplay and you’ll use multiple of these when attacking a market. The maps will also help you identify where to attack along with where to gamble. However, for most of you today that is still a long way of … you'll need these 100 days before you’re ready to play.

I do understand how people are tempted to dive into strategy, learning and structure but there is no point until you understand your context and have removed the flab. I know everyone is looking for the "get fit fast pill" for corporations e.g. "Agile Disruption!", "Be Digital!", "APIs ftw!", "SWOT will save the day!" etc but the pill doesn't exist. These are just memes and its potluck or more aptly potbelly luck if they work. You've got to put some effort in before you can be ready to play the games with confidence.

In the next post in the "Get fit" series, I'll cover learning and structure and bring you right to the cusp of strategic play. After that, I'll add a post on strategic play and get back to writing on the 61 different forms of gameplay.

Tuesday, June 23, 2015

Position, Flow and Movement

Given some of the comments on my last post on "Why Agile, Lean and Six Sigma must die" ... I thought I'd take some time to clear up another misunderstanding in the difference between position, flow and movement.

Let us assume you've examined a line of business, starting from the point of user needs and developed a value chain. I'll assume you've also mapped this over evolution. Beyond the obvious of breaking down a system into components and the interfaces between them then there are three things to consider.

Position : the position of components simply relates to how things are connected and how visible they are to the user need. The value chain itself is a chain of needs i.e. this needs that etc. At the top of the value chain these needs are exposed as meeting user needs (i.e. customers) and can often be expressed in terms of the customer journey. This doesn't mean the lower components aren't essential but a user who wants a cup of tea doesn't care about the power provider you use to boil the water. They only care about a piping hot cup of tea.

Flow : whenever you look at a map (an example is provided in figures 1 & 2) then there are multiple flows within the value chain. These flow can cover things such as information, risk, finance and materials. Sometimes one flow is more viable than another and financial models based upon flow can be developed (see figure 3). Sometimes a flow may be inefficient because it'll have bottlenecks and improvements can be made. There's all sorts of important things to be consider from inventory to capacity to variability and time.

Figure 1 - A flow within a value chain (a TV company)


Figure 2 - Another flow within a value chain (a TV company)



Figure 3 - Analysis of a flow.


Movement : Understanding position and flow is a good start but unfortunately value chains aren't static, they evolve. Fortunately the process of evolution is fairly well defined across activities, practices, data and knowledge and there are many common economic patterns, weak signals and gameplay which can be used to anticipate and manage this. There's however little point in understanding the value chain and managing the flow efficiently if you are treating most of the components as custom built when the market treats them as commodity. You have to accept that everything in your value chain will evolve (i.e. move across the map) and therefore you might be efficiently managing the flow in your value chain but at the same time being ineffective because you're treating components in the wrong way.  

Understanding position and flow is critical for efficient provision of an in-situ situation however understanding movement and position is critical for strategic gameplay, anticipation and effectiveness. 

To give an example of this, I'll use the box and wire diagram from the previous post (figure 4). Do remember that box and wire diagrams (IT systems diagrams, Business Process Maps, Value Stream Maps etc) all have their purpose but they only show you connectedness of components (not necessarily even position relative to the user) and can only be used to analyse flow.

Figure 4 - A typical box and wire


Looking at the box and wire above. The questions you need to ask are :-

a) I outsourced B and it was a disaster. Why was it a disaster?
b) Should I outsource A?
c) What components are most directly visible to its consumer?
d) What methods (i.e. doctrine) should I use for each component? Agile, Six Sigma or Lean?

Now, whilst I can't answer these question, I can examine different flows in the box and wire (e.g. the one I've highlighted in blue is C, F, D, A). I can look at it for bottlenecks and mechanisms to improve efficiency and certainly if I have multiple box and wire diagrams then I can look for duplication. But of course, I don't know whether one of those components is representing the visible user need and hence I don't know the travel of flow towards the user unless I add arrows. I also don't know how evolved those components are i.e. if the duplicated components are suitable for provision as platform components?

Exactly the same diagram is provided in figure 5 below but in this case I've added movement represented by an evolution axis. I can now not only examine the flow but answer all the above questions.  I can even anticipate how things will change (I've added some lines for competition effects but in reality all components are likely to be moving).

Figure 5 - A map of the same process


With multiple maps I can remove bias in treatment (people custom building what is a commodity) and find not only duplication but identify those components suitable for provision as a platform.

Furthermore using the above map I can identify where we will have inertia, potential threats from disruption that can be anticipated, co-evolution of practice and even repeatable mechanisms for how I can manipulate the market (i.e. organisational learning). I can determine the appropriate methods both project management and purchasing and even determine appropriate structure. See the previous post for help on some basics or this post for a general introduction to the technique.

Hence with the above map, I can anticipate a future state (figure 6).

Figure 6 - Future State


Hopefully I won't have done the daft thing of outsourcing B but instead I will have moved from using an Agile approach to using Lean to build it (assuming I'm the one building). As for component C, then I'd probably be looking to build that as a utility service for others (ideally with a six sigma style approach) or use some sort of cloud service. With component F then I'd be anticipating to outsource it along with the hopefully already outsourced A.

I still have the same flow C, F, D, A (along with the other flows in the diagram) but the characteristics and the manner in which this flow is provided has evolved. If I'm stuck making the flow efficient using C, F, D all as products (as it used to be) then as efficient as I am, I'm likely to be outcompeted by the market. I can also see from the map that I don't really have anything differentiating me from others, so I'll probably be taking a few gambles to create components that meet others needs built on the components that I already have.

Gamble? Did I say gamble? Yes ... alas with a map, there are some things you can plan but a lot of spaces in which you have to experiment. Remember that evolution axis is determined from ubiquity vs certainty and the uncharted spaces are not only rare ... wait for it ... they're uncertain (see figure 7). Of course, that doesn't mean we can't mark on a map that we suspect something is over there in the uncharted space (a gut feel, an intuition etc). We might even give it a name, we just don't know what it really is yet or even if it'll be successful. Of course, if it is then over time it'll become more defined, it'll become more certain ... you get the picture.

Figure 7 - Plan vs Experiment.


Anyway, the point of this post is rather simple. Position and Flow can only get you so far - even if I've build a customer journey between high level needs. If you really want to learn strategic play and to become efficient and effective then you're going to need to understand Movement (i.e. how things evolve).

Remember ALL maps are imperfect and they are simply communication tools used to describe an environment. They enable collaboration, communication and gameplay but you still have to apply thought. These maps are by no means the ideal way of visualising, they are more like Babylonian clay tablets as opposed to ordinance survey. Mapping business is a field in its infancy but even these are better than no maps.

However, trying to describe an environment based upon position and flow and not allowing for movement prevents you from determining direction and applying any concept of strategic manoeuvring for both yourself and opponents. Unfortunately these box and wire concepts are exactly what most company strategy is built upon normally mixed in with SWOTS, meme copying and other story telling devices.

I cannot emphasise enough how fsck'd your company is if you come up against a player that knows what they're doing when you're trying to use old approaches. I've seen examples of vendors who've taken a beating with Government in the recent past and still haven't clocked why. This is only going to get worse for those companies if they don't adapt, focus on user needs, sell components appropriately and don't try the old "outsource everything" game. I know many departments that are getting better at situational awareness and gameplay. The days of Government being a soft touch are slowly (very slowly) disappearing.

Saturday, June 20, 2015

Why Agile, Lean and Six Sigma must die ...

Every large system (whether a line of business or specific IT project) contains multiple components. Those components have a relationship with each other (known as position) but they're also evolving. 

Every components start as something novel and poorly understood - the uncharted space of the new e.g. the first telephone - and over time through demand and supply competition becomes widespread and well defined or in other words industrialised. The properties of these two extremes are polar opposites. As Salaman & Storey said in 2002, any structure needs to manage both of these polar opposites. Before you shout "Bimodal" or "Two Speed" or "Dual Operating System", there's also the issue of the transition between the two but we've covered that in previous posts.

If you start with user needs, you can map this landscape out in the form of a Wardley Map - named after me! Well, I've been doing this for over a decade now and I did invent the technique, so fair enough. What's interesting with maps is that they not only give you position (the relationship between things) and movement (how things are evolving) which is essential for any form of strategic play but you also find that different techniques and methods (i.e. doctrine) whether it's project management or purchasing are stronger at different parts of the map. None of this is new.

In figure 1, I've provided a map showing the position and movement and how maps can enable you to determine where to attack. In figure 2, I've shown how different methods (including insourcing and outsourcing) can be applied to areas of the map. In figure 3, I've provided a map with different methods applied.

Figure 1 - A Map


Figure 2 - Techniques and Changing Properties


Figure 3 - A map with techniques applied. High Speed Rail


Maps are mainly communication vehicles but they're also useful for organisational learning. However, when it comes to doctrine (e.g. techniques & methods) in IT, let us emphasise the following.

In one part of the map you'll tend you use an Agile approach (right back to the core principles, possibly with a technique like XP or SCRUM) focused on exploring the uncharted and reducing the cost of change. As Michael O. Church points out, agile is best in situations when "dealing with finicky clients who don’t know what they want" i.e. when exploring the uncharted space where no-one knows what is wanted.

Of course, as an act is explored and becomes more widespread and well defined (i.e. we start to understand it) then the focus changes. We start aiming to build a product, sometime in era of custom built examples. Whilst we may continue to use underlying techniques such as XP or SCRUM, our focus is on reducing waste, learning and creating a minimal viable product and improving measurements. Lean rules the waves here.

Of course, as the act continues to evolve becoming more widespread and defined then we're now into the world of volume operations. It's increasingly heading towards commodity and our focus is mass production of good enough which means reducing deviation. At this point, Six Sigma (along with frameworks like ITIL) rules the waves.

However, any significant project (as show in figure 3) has components in all these stages. Those components aren't static but evolving and as they become more commodity like they enable rapid development of new higher order systems. But, at any one moment in time, you'll have components at all stages and you will need to use a mix of agile, lean and six sigma throughout the project.

Of course, most companies have no map of their environment and so are forced to plummet for a one size fits all method e.g. all agile, all lean, all six sigma. All of these methods will have their devotees and so regular arguments of agile vs lean, lean vs six sigma, agile vs six sigma break out along with various attempts to create new magic one size fits all methods which combine different stages e.g. lean six sigma or agile lean or prince agile etc. 

This has been going on in one guise or another for a decade now. Suck it up. There's no one size fits all method. [Cue endless rants from agile, lean or six sigma devotees].

You need to use the appropriate methods according to how evolved the component is. Since most companies have no form of maps (i.e. no understanding of position AND movement) or confuse box and wire diagrams (e.g. IT systems diagram, Value Stream maps, Business process maps, Kaplan Strategy Maps - which all have uses) with maps then generally there is no hope of this happening. If you're going to insist on acting blindly and picking a one size fits all method then choose Lean. It's far from ideal but better than focusing on the other extremes.

Personally, I'd learn to map and use all the methods. Personally, I think the idea of being ALL agile, ALL lean or ALL six sigma should die.

I know it won't. A decade of using maps, speaking and writing articles in various publications that point out the need for multiple methods has taught me one thing. In a decade from now, I'll still be hearing people arguing over whether agile, lean, six sigma or some equivalent method is better everywhere. It isn't. It'll never be. Alas, there are two solutions to Ashby's Law of Requisite Variety in management - you either accept the complexity and manage it or you pretend that what is being managed is simple and apply single methods or simple KPIs. The latter tends to rule because the former is hard.

Before I go, some quick notes on the question of strategic thought and mapping. The two most basic properties of a map are position and movement. It doesn't matter whether this is a physical map or a chessboard, they show you where things are and how they can move. More complex maps can include other details. For example in a Wardley map, along with position and movement then you can look at the flow of information, risk and finance in an existing value chain (NB. Value Stream maps also do this but they only show flow within the value chain and not movement i.e. how components will evolve). Without position and movement though, strategic play is guess work.

Hence, look at table 1, print it out and tick off each area that your business knows well or undertakes.

Table 1 - Understanding of the Purpose, Climate, Landscape and Doctrine.


If you haven't ticked off ALL of the first seven steps then any strategy you have is most likely meme copying others. You're running blind and you don't have a hope of understanding where to attack and hence determining why here over there. I strongly suggest you throw away your strategy and replace it with the following ...

Our strategy is to try and understand what we do, for whom, why we do it, what they need and what's involved as efficiently and as effectively as possible without breaking the bank.

... or at worst, don't pay consultants for any future strategy - just click the link here. It'll auto generate you a strategy based upon the common memes around. It's useless but it's free rather than being useless and costing a fortune.

Until you can do the most basic stuff of understanding purpose, landscape (map) and doctrine (methods, techniques etc), there is no point in talking strategy. Anything you'll do is just simply shooting in the dark.

Oh, and to really rub it in, I'm going to emphasise the point about the importance of movement. I've taken a simple process diagram, replaced the terms with letters and provided this glorious BOX and WIRE diagram in figure 4.

Figure 4 - Box and Wire

Now, in the above you can clearly see the relationship between things but I've got four simple questions for you to think about.

a) I outsourced B and it was a disaster. Why was it a disaster?
b) Should I outsource A?
c) What components are most directly visible to its consumer?
d) What methods (i.e. doctrine) should I use for each component? Agile, Six Sigma or Lean?

Can you answer these? I can't. For your interest, in corporations around the world people are trying to manage stuff and answer these questions with diagrams just like the above.

Ok, I've now provided exactly the same diagram in mapping form in figure 5. No additional information was added other than position and movement.

Figure 5 - Map


Now, try answering those questions. If you need help, look at figure 2 above again. It should be trivial.

If you want to know how to organise around this. Start here.
If you're entirely new to mapping then this set of posts should help.

If you're thinking ... "is this mapping the answer!" Let me emphasise that we're roughly at the Babylonian clay tablet stage and not the ordinance survey stage of business mapping. This technique will give you a better map than no map.

Finally ... the only people who can map a business are those that operate in that business i.e. no consultants. The technique is all creative commons share alike, so you've got everything you need to get started.