Saturday, September 13, 2014

Three of my favourite taunts of business - adoption, egosystem and SWOT.

Every now and then, I find something in business so ridiculous that it tweaks my sarcasm gene into overload. I normally respond with a graphic on the subject. I have many of these little gems scattered in my blog but my three favourite are ...

1) The Enterprise Adoption Cycle

A comment on the state of inertia within organisations.


2) Ecosystem vs Egosystem

A comment on strategic play exhibited by some companies in the cloud space




3) Thermistocles' SWOT

comment on the artefacts we often call strategy in business.


Friday, September 12, 2014

Thermistocles' SWOT

The battle of Thermopylae (the tale of the three hundred) and the clash between the Greeks and the mighty army of Xerxes has echoed throughout history as a lesson in the force multiplier effect of landscape. Thermistocles devised a strategy where the narrow pass of Thermopylae would be used to hold back the Persians whilst the Athenian navy would block the straits of Artemisium.

The tale is a lesson on why understanding the environment (situational awareness) and exploiting it is critical in combat and why maps of the environment are powerful military tools.

Alas, it turns out that this tale is wrong. Recently discovered archaeological evidence has shown that rather than using awareness of the environment, Thermistocles had no situational awareness at all. Instead, the troops were roused not through cunning strategy but the use of a SWOT (strengths, weakness, opportunity and threat) diagram which was presented to the troops in 28 pt Arial on parchment. The original Greek document has now been translated and is provided below.

Thermistocles' SWOT


Please note, the next time someone turns up with a strategy document which has no map of the landscape but instead either a business model canvas or SWOT diagram masquerading as strategy - I will laugh mercilessly at you until you go away.

Both Business Model Canvas and SWOT diagrams are perfectly useful communication artefacts of the process of scenario planning but they are post event. Without a map, even an imperfect map then you have no strategy. Well, certainly not anything I'm going to take seriously.

Monday, September 08, 2014

On Co-Creation ...

Co-creation is an extremely useful technique but it should be remembered that it's not suitable across the board. When I examine a map of the landscape then I tend to advocate its use in particular circumstances.

However when creating the novel and new (i.e. the genesis of an activity), it's actually better to get everyone else to create it for you and to exploit their creations to identify success. This is more You CREATE and I EXPLOIT and there is little collaboration to it.

An example of this is the ILC (innovate-leverage-commoditise) model which I've talked about extensively in the past. The model starts with a company first creating the industrialised services that you build upon (what is often called a platform) and then growing an ecosystem of companies consuming those services. 

The technique is incredibly powerful (it's a force multiplier in competition). If correctly used then my apparent :-

1) rate of innovation i.e. how much YOU are creating for me to EXPLOIT
2) rate of customer focus i.e. how much I'm EXPLOITING creations YOU made to give to others
3) rate of efficiency i.e. how much I take advantage of economies of scale by all YOUR use.
4) stability of revenue i.e. volume of predictable industrialised services I'm providing to all of YOU.
5) ability to maximise opportunity i.e. how much I am able to spot future success from YOUR experiments.

... all increase, simultaneously with the size of the ecosystem.

Spotting a company using an ILC like model is fairly easy. Whilst the company might grow in terms of physical numbers of employees, it's apparent rate of innovation, customer focus and efficiency all seem to accelerate at a faster rate (because it's growing with the size of the ecosystem). Worse, this seems to happen all at the same time (counter to the old ideas of you can focus on one).

A telltale signal is when people & other companies start grumbling that this company has just trampled all over their business models. Words like 'eaten the ecosystem', 'bully' tend to get mentioned a lot. At the same time, customers (i.e. those not being trampled on which can include other companies) benefit from the net effect of an increasing number of useful services. This tends to act as a magnet and the model is therefore reinforcing with plenty of network effects.

Anyway, more information on ILC can be found from reading the above post (linked here also).

So, why do I mention this? Well, first of all the ILC technique has been in operation for almost a decade. Hence, to anyone who is recently discovering the force multiplier effects of ecosystems - can I suggest that something is going terribly wrong with your horizon scanning. 

The second reason is someone just asked me whether I thought Amazon was a good example of co-creation. Oh, you're kidding right? Seriously?

Data points for mapping ...

The mapping technique I describe (known as Wardley Mapping) is not widely used, in fact usage is quite rare. However, seeing that I made the technique creative commons many many years ago - I don't actually know how many people are using it.

Of those that I do know then I have numerous examples on impact e.g. :-

1) Estimated reduction in cost of an entire project by 30%

2) Reduction in cost of individual project transactions between 99.3% and 99.6%.

3) Identification of new opportunities and successful funding of new business to exploit this (around $70M raised in total).

4) Increase in market share in an emerging field from 5% to 70% with minimal (sub $1M) investment.

5) Identification and removal of project risks for large scale projects (in excess of $100M).

The problem of course is that "numerous" isn't the vast number of examples I need. Even the examination of high tech companies on strategic play (see figure 1) only covers 160 high tech companies.

Figure 1 - High Tech companies, Strategic Play vs Action


Now mapping has a reasonably solid base in terms of the research on evolution. But unlike the evolution work, it lacks the many thousands of data points that I require to confidently say (to my satisfaction) what the impact of mapping is to most organisations. The signs all look encouraging but that's not enough. I like my work to be backed by large volumes of supporting evidence as opposed to handfuls or a few hundred. I'm not into the "this company did A and is successful, so you should do A too" world of backward causality.

I don't obviously expect to get this data anytime soon - it'll be a very slow road (i.e. 10 -15 years). However, if you are using mapping then please take a short amount of time to jot down the impacts (positive, negative and no impact) and ping me.

Sunday, September 07, 2014

On D&D vs Ant Battles - a Question of Strategy

Recently I posted on the question of "Dungeons & Dragons vs the Art of Business Strategy" and received this wonderful riposte to the same. I do like a good joust and much of the response is perfectly reasonable.

Now, whilst I don't view D&D as a teaching tool itself, I do view it as a remarkable comparison between how a gaming environment and business operates. The premise that I proposed is that business can do better if they understand their environment, their capabilities and roles, improve their team play and prepare (i.e. scenario plan and train).

The impact of the first of these premises (the necessity of situational awareness) is demonstrated in the following graph (figure 1). This examination of 160 high tech companies showed that those with poor situational awareness tend to have a negative market cap growth over a seven year period. It seems that situational awareness is important to all endeavours of competition whether business, military or D&D.

Figure 1 - Examination of Strategic Play vs Action


In business we often have no form of competitive maps but instead rely on what should be artefacts of scenario planning. In the worst cases those artefacts (business model canvas, SWOT, kaplan strategy maps) become the primary source of awareness and the scenario planning required to create them isn't even done. This is my primary issue and why I made the comparison between D&D because such a basic element of strategic play shouldn't be missing from business. But alas, it more often than not is.

This absence often shows itself in the 'strategy' of a business being little more than a tyranny of action (how, what and when) with operational, implementation, purchasing and tactical choices.  This is opposed to situational awareness (where and why) being dominant. 

The 'why' itself can often be reduced to the copying of others on a premise of backward causality.  If A does B and A is successful then we too should do B. Hence many companies have identikit strategies covering topics like cloud, big data, social media, IoT but little awareness of why or the context they exist within. I have poked fun at this before. It is depressingly common.

Whilst I agree that strategic planning is complex especially over a considerable period of time, the basic premise of understanding your environment appears to apply regardless of time or complexity. Whether within Government or commercial settings, I have witnessed first hand the devastating effect of understanding the environment. Now, I do not propose that companies simply copy the actions of others but instead understand their environment before acting. 

We often like to think that business is like a game of chess. The reality is more akin to a game of chess with competitors that rarely look at the board before moving. I'm not being disingenuous when I state that D&D groups often have far greater situational awareness over their environment than a business does over its - that often appears to be the case.  I wouldn't also compare business to military because the level of strategic play within the military far exceeds anything I've ever witnessed in business, even in the most high tech of companies. 

This alone is why I often smile when I hear people ask how do we make the military more like a business? My normal response is - "Take away any maps, don't allow people to understand an environment before engaging, remove scenario planning and training, add in poor communication and replace combat strategies with a vision and some nice stories - once done, you'll be just like most business".

Now obviously, the scopes are different and business is a continuous and draining act of competition. However, it's for these very reasons that I strongly suggest we learn the basics from other competitive groups because we appear far behind them in terms of play. There are exceptions and there are companies such as Quid and Palantir that are trying to change this. But I do recommend that we should be realistic about business and not to be lulled into believing we're some bastion of strategy.

Instead, what we normally are is - an organisation with communication, management and control issues competing in an environment over which we have little to no situational awareness nor mechanisms for learning nor understanding of basic principles of change but in which we take action. 

Our saving grace is our competitors are normally in the same boat. In competition it's ok to suck as long as everyone else does.

Maps are imperfect but that's ok ...

The mapping technique I use (commonly known as 'Wardley map' - see figure 1) is imperfect. These maps are simply a representation of the problem but the act of making a map has some profoundly useful effects.

Figure 1 - A Wardley map


The useful effects are :-

1) It encourages you to think about USER needs. The map starts from the visible user needs and moves through the components necessary to make that need happen.

2) It encourages you to think about COMPONENTS. Rather than treating a system as one thing, mapping encourages you to break down complex systems into components and understand that a complex system is in fact many things.

3) It encourages you to think about METHODS. Rather than treating a system with one method, mapping helps people to understand that as a component evolves then its properties change (from uncharted to industrialised) and hence the methods you use are different. Use of multiple methods (Agile, Lean, Six Sigma) in a single system at the same time is appropriate. Hint: you can co-ordinate a mass of different components using different methods (agile, six sigma and lean) through a scheduling system such as a Kanban board.

4) It encourages you to think about CHANGE. Evolution is not static, the components evolve due to competition. Mapping teaches you that how you treat something today is not the same as tomorrow.

5) It encourages you to COMMUNICATE. One huge advantage of a map is that other people can read it and obviously compare to other systems. Having maps is extremely useful in identifying common components between systems, to avoiding duplication and for sharing plans and strategic direction.

6) It encourages you to CHALLENGE. If you can read a map then you challenge the assumptions made especially by comparing a map to the outside world. Is CRM really at the stage of custom built or are we custom building what is in fact common and ubiquitous and suitable for commodity provision?

7) It encourages GAMEPLAY. Once you have a map, you can ask questions about how to change it e.g. using open approaches to drive to an activity, practice or data (all can be mapped) to more of a commodity or slowing this down with dark arts, constraints or regulation. Manipulation is at the heart of strategy.

8) It encourages you to PLAN.  Once you have a map, you can test various scenarios and examine the probability of effectiveness of one scenario over another.

9) It encourages you to LEARN. With a map, you examine the effect of a given play before and after. This helps in learning what plays work, how economic forces change the landscape and how force multipliers (e.g. ecosystems) can be used.

10) It helps you to MITIGATE risk. Examining different scenarios, breaking down complex systems into components and effective communication are all necessary mechanisms for mitigating risk.

11) It helps you to COMPETE. Mapping can equally be applied to competitors to discover points of weakness, inertia to change and tactical plays (e.g. Tower & Moat) that you can exploit against others.

12) It helps you to find OPPORTUNITY. Understanding that the uncharted space is all about differentials and the industrialised is all about operational efficiency enables you to identify potential areas for improvement and how to exploit it.

13) It focuses on CAPABILITY and ORGANISATION. Once you have a map it becomes fairly easy to identify what aptitudes (skills) and attitudes (pioneers, settler and town planners) are needed for each component.

Now, if competition, strategic gameplay, opportunity, communication, risk mitigation, capability, scenario planning, challenge, organisation and user needs are not important to you then you probably don't need a map. If however the above is important for you then a map - even an imperfect map - will help you. The beauty of maps is of course that they can be shared and it is this act that improves them.

Friday, September 05, 2014

Robots vs Intelligent Software Agents

When examining potential points of future change, I use a very purposeful distinction between robotics and intelligent software agents. One is a component of the other.

Robotics is rapidly heading towards a state of early generic robotic platforms (as per Baxter) which over time promise greater commoditisation of this space (often associated with human physical effort). As we all hopefully know by now, it's never the first innovation of something that overhauls our society but commoditisation of pre-existing acts. Robots have existed for sometime, generic and hence more commodity robotic platforms haven't.

However, those generic robotic platforms are limited in scope to the system in question because the "intelligence" behind them is targeted to that scope. When you examine medical systems or self driving cars or SIRI or any number of environments - the intelligent agents are specific. There is no generic intelligence agent ... yet.

But there will be (see figure 1).

Figure 1 - map of robotics.


Today's "intelligent" agents are still in relatively early stages. But in the near future the "intelligent" agent needed to drive your car will be no different to the one that flies a plane, delivers your coffee or undertakes your cosmetic surgery. Obviously those "intelligent" agents will be trained for the task in hand and some will be trained for multiple tasks. But this "intelligent" capacity will be very much a commodity.

So what's with the distinction here? Why bother?

Well, as things evolve they go through the stages of wonder, peace and war. It's never the wonder but the war stage (where things become commodity) that impacts society widely depending upon how well spread the activity, data or practice is in other value chains. 

Hence in this case, then in the first instance we will see disruption and change caused by the introduction of generic robotic platforms but because these will have targeted intelligent agents they will be generic to a specific area - the intelligence behind self driving cars will not be the same as the intelligence behind your surgeon. Hence to some extent the impact will be constrained. Much of the disruption will start in robotics manufacturing and existing industry users. These targeted systems will tend to be adopted by other industries hence the self driving car will be a feature differential of high end vehicles and not a destroyer of the automotive industry.

Alas, there's a later stage when the intelligent agents become commodity. At this point we will see truly commodity platforms in robotics and numerous other fields. This in turn will drive commoditisation in those sectors. Every car, every airplane, ever railway, every truck, every 'doctor' will be a 'self driving' and intelligent machine based upon the same intelligent system. The once benign feature differential of high end cars becomes the commoditising force behind the entire industry.

So why mention it? Well, I've summarised this in figure 2.

Figure 2 - Impacts of War


In the first wave (2020-2025) we should see rapid introduction of generic robotic platforms for different activities based upon targeted intelligent agents. Expect commercial high end self driving cars, increased use of robotic platforms such as Baxter. The impacts of this will generally be adopted by various industries from automotive to transport to healthcare. Disruption will tend to be fairly minimal or localised to existing users and robotics industry.

In the second wave (2030-2035) then you should expect to see the rapid introduction of generic intelligent agents. The agent that drives your car, pilots the plane, automates your house will be the same. This will rapidly spread impacting and commoditising multiple industries. Every car will be self driving - not that you will own a car anymore, you'll just pay for the use of the journey through an Uber like service. The entire transportation system will change. Many will be disrupted.

Now whether the timings are right here is highly questionable. The overall transition to commodity depends simply upon competition but the timing depends upon individual actors actions - this is always unpredictable (see Hayek and the pretence of knowledge). There is also constraints such as power and impacts such as Jevon's paradox to consider.

I would suggest however, that before people claim doom to humankind and our role in society due to the introduction of generic robotic platforms that they consider there are two waves approaching. The later is unquestionably the more dangerous in terms of social policy but it also allows for the greatest possible number of recombinations of higher order systems and hence the creation of unimagined roles today.

In much the same way the gas lamp lighter could see their job going but no-one could tell them that we'd have radio producers, television personalities and computer programmers - then the Barista maybe worried by a robot but find themselves later on as a counsellor to a neurotic intelligent agent. Can you honestly say that intelligent machines aren't going to need psychologists? Have we forgotten that the best chess computer in the world can beat a human BUT an average chess player with an average chess computer can beat the best chess computer?

So, will everything be rosy? No. But the real threat to society is not so much the machines but other humans and self interest. I'll leave that post to another time - fortunately by my reckoning then we still have quite a bit of it left.

Tuesday, September 02, 2014

Rough guide - use cloud, build cloud or micro-services?

A quick and rough guide.

First, map your environment. Remember that the rate of innovation of novel and new components (i.e. higher order systems) is exponentially related to the level of industrialisation of the underlying components (an effect known as componentisation).

With this in mind, then ...

Figure 1 - using cloud.



Figure 2 - building a cloud service.


Figure 3 - How to build? Micro services or not?


First, I'd like to note that every node in your map is a component and ideally would be built as a 'small' and relevant component (see USAF FIST) for the activity that the component represents. Hence, for the activity of computing infrastructure then in the past we used product components such as servers though today we tend to use utility service components such Amazon EC2. Not breaking things down can cause all sorts of issues - see ASPIRE

From the above example, it should be clear that how a component is delivered depends upon how evolved the activity is. In some cases the component can be provided as a product, in other cases (when the act is less evolved) you have to custom build it whilst in others (when the act is highly industrialised) you can use utility services or commodity components. The type of component you use to deliver an activity will also change over time (as the act becomes more evolved).

HENCE don't rush to build a micro-service for a novel act because it will rapidly change (evolve) in both code base and interfaces. Let me emphasise, the interfaces are anything but stable. Hence an 'experimental' code base with objects in a code repository is more than enough at this stage. Don't enforce its rapidly iterating schedule and changing interfaces on other consumers in your organisation. Let them choose the version they wish to use.

However - word of warning - ask yourself is this really a novel act? Just because it's the first time you're doing something doesn't make the act novel. For example, user object, security permissions, financial transactions are anything but Novel. So, check with the market and find out how evolved (i.e. ubiquitous and well defined / understood) something is.

Assuming the act is novel then as it evolves and the interfaces start to become more stable then by all means start to consider providing it as a common library and then as a micro-service to others. Yes, everyone using other versions will have to refactor a bit for use of the new micro-service. 

For the more industrialised components, if you're not using utility services or your own micro services (in an ideal world the service would be both) then please ask yourself 'why?'

The above was brought to you with experience of building large and complex environments for millions of users with micro and some not so micro services between 2003-2006. It's a rough guide and not a substitute for thought.

Friday, August 29, 2014

Business Model Canvas ... the end of a long road.

I'm currently hitting a road block with the latest memes around business model canvas and it's driving me nuts. First, let me be clear, I find business model canvas an extremely useful tool but it's not the beginning but the end of a long road.

Whenever I look at doing something in business, the first thing I do is map out the landscape focusing on the user needs. In figure 1, is an example map (an old early draft) from a section of the security industry.

Figure 1 - Security Industry.


The next thing I do is look at WHERE we can attack i.e. the various plays open to us. This usually is an intensive process of discussion. In figures 2 & 3 are two example plays from a dozen odd potential plays in the map in figure 1.

Figure 2 - Play 1 - a commodity play around Identity.


Figure 3 - Play 2 - Trust as a Service


The map usually provides immediate cues as to what is risky, what has potential now and what has potential for the future. I then normally look at what steps we can use to make the plays happen (see figure 4) looking for supporting and complimentary approaches.

Figure 4 - Potential Steps


I then take these multiples WHEREs and examine the outside market, looking at competitors, inertia they have, inertia we have, what we can exploit, what capabilities are needed, where we can build ecosystems, what constraints exist, buyer / supplier strengths, likely economic effects - an example of a small part of very old map in a different field is provided in figure 5.

Figure 5 - Comparison to outside


I then normally pick a few of the most attractive WHERE's which we can influence highly (either through open approaches or use of dark arts) and have beneficial properties (constraints we can exploit, potential for ecosystems, poor strategic play by competitors) and run a few scenarios looking for how things are likely to evolve, potential for co-evolution, impacts of points of change, predictability of change, what's likely to emerge, what we should discontinue or sell elsewhere etc e.g. see figure 6 - from another industry.

Figure 6 - Scenario comparison


At this point, I normally have multiple WHERE's, the user needs, the potential impacts of changes, what we can influence, target markets and information on how to play the game. This can take a lot of effort, for a reasonable size business then you could be talking a few days work or even a week or so of hard graft. But at the end of this process then I'm at the point of saying WHY we should attack one space over another or WHY we should attack multiple points. I'll normally have a map and the background info to demonstrate this in a way that everyone in the organisation can understand, discuss and input into.

It's at this point we can develop our chosen point of attack - I can usually state all the activities , practice and data involved, how we should attack, what the user need is (and what we emphasise on), what components we need, where the constraints are (and how we exploit), what markets to focus on, our revenue models, how we should manipulate (e.g. open approaches) and estimate the likely cost structures from the components. I have a good idea of how to play the game, cope with competitors, who we should acquire and what to watch for. I'll have a pretty decent idea on how to play the game to our advantage.

I'll even have a decent idea of how to manage and organise around this, what we need to build, what techniques to use, where to differentiate, where to copy and what we need to experiment on etc (see figure 7)

Figure 7 - Managing a system


At this point, I'll have ALL the information I need to fill out a business model canvas (see figure 8).

Figure 8 - Business Model Canvas


I prefer just to use the maps since the business model canvas is an artefact of the process. However, it's a neat summary of the bits of the map (or maps) that I want us to focus on and hence I do find it can help. The map however provides the greater context and situational awareness is key with strategic planning.

Oh, and just for your info, mapping is the stuff I used when I was CEO of a Canon subsidiary and when I ran strategy for Canonical. I would never hand this off to some other company or agency. Mapping was important in understanding how to play the game which is what we would do next. Let me emphasise - WE played the game which meant WE had to understand the landscape that WE were competing in.

So, given I think Business Model Canvas is a useful technique then what's my problem with it?

I'm starting to get companies asking me what do I think of their Business Model Canvas which is all good. BUT, I normally respond with "can I see your map or some other expression of situational awareness, the plays, comparison to market / competitors and your scenarios examined?"

A disturbingly frequent response is "we don't have that but what do you think of our canvas?"

Let me be clear to everyone. I think you're foolish to even consider committing one cent to an idea expressed on a business model canvas without any situational awareness of the competitive landscape or scenario planning. The business model canvas is not where you start, it's at the end of a long road which could take a week to travel. Ok, it's better than the even more crazy ideas of not even expressing what you're planning to do in a clear form but the canvas is all about the 'how, what and when'. You really do need to answer the 'where' and then 'why' before you start using it. The canvas is the end of a journey and not what you fill in at the beginning!

Don't get me wrong. The business model canvas is an extremely useful tool BUT if you think that filling it out has anything to do with understanding strategic play then you are sorely misguided. Yes, you may well still be successful but you're not looking at the environment and that's a bad move on average as you're leaving more stuff to chance than necessary.

Wednesday, August 27, 2014

Aspiring for more Fiasco … again

The Times today screamed one of those eye catching headlines - "Whitehall IT Fiasco" - with a fairly detailed dissection of the HMRC Aspire contract. The relished shout of "failure" was only surpassed by the monumental fallacy of "the solutions". I think it's worth exploring why.

Lets start by simply taking the Times and its "experts" views that Aspire is a project that has 'spun out of control' with 'spiralling costs' and is beset by 'previous disasters'. I won't argue whether this is true or not but simply ask the question - why?

IT failure is not an unusual story in both the public and private sector. There is however a common factor at the heart of many of these problematic systems which is best illustrated with a map. Mapping, for those who don't know, is a process of comparing value chain against evolution. In figure 1 I've provided a map from current government system (I've removed the terms describing each component because it isn't relevant). The map is derived from three user needs (components A, B & C).

Figure 1 - A 'Wardley' map


The key thing about mapping a complex environment is it teaches you that ANY complex system contains multiple components at different stages of evolution. For example, in the above map there are 24 different components, some of which are in the 'uncharted' space (3 components - D, E & F) and some are highly 'industrialised' (G to M).

Now, each of those stages of evolution have different characteristics and require different methods to manage. For example, the uncharted space is best suited to in-house development with agile techniques because it's uncertain and it requires experimentation as the requirements are unknown. However the industrialised is best suited to outsourcing to a market with highly structured methods (e.g. six sigma). The industrialised is known, it's defined.

Now, key to mapping is to realise that there is no magic one size fits all method to management. Of course, when it comes to dealing with a complex system then you could decide to apply a one size fits all approach (e.g. agile everywhere or outsource everything) rather than apply appropriate methods to each component.  However, this 'one size fits all' choice normally occurs because no-one has a map and so they don't realise that multiple methods are needed.

Now, a 'one size' can be fairly problematic. For example, suppose we decided to outsource the entire of the system described in figure 1. We are likely to want to implement a contract which describes in detail what we're getting for our money - that sounds perfectly reasonable. The supplier however is likely to implement some process for managing any changes. All very sensible. However, here's the problem. 

If you look at the map, then components D, E and F are all in the uncharted space. This means we don't actually know what we want, those components will change rapidly. But if we've implemented a one size fits all contract across the entire system based upon an idea that we do know what we want, then we're going to get stung with the expensive change control processes for components D, E and F.

To be honest, most vendors seem to know this. The beauty of this approach for them is they profit handsomely from change control and they certainly (as the article points out) have "little incentive to keep fees low for changes". Even better than this, when the customer complains then the vendor gets to blame us for not knowing what we wanted and can get to point to other more industrialised components (those that didn't change such as G to M) as having been efficiently delivered.

It's all our fault! But we couldn't know what we want! We could only know what we wanted with the more evolved, the more industrialised components.  The fault is of course with the process. We should have never outsourced these uncharted components but instead we should have used agile, in-house techniques. By all means, we should outsource the industrialised.

A better way to treat this project is described in figure 2. 

Figure 2 - using multiple methods


However, vendors tend to dislike this concept because they make a fortune on change control processes. In some cases, the effective treatment of a system as components has led to cost reductions of individual components in the order of 99.3% - 99.7%. The sums of money (or profits) involved can be significant.

So, now let us turn to Aspire or what is described as the "country's biggest IT contract … heading for disaster". I can assume (as with most private company projects) that HMRC in the past didn't have a map, which is a pity. I can only guess at that the number of components involved in a complex system like this. So let us say it is 100 - it maybe more, it maybe less. 

Now with no map, I can't tell what components are evolved and what are not. So let's take figure 2 as a benchmark and generalise it for all projects. We know from figure 2, that there are 24 components. In the legend, I've quickly summed up how many of each type exist. About 12% are uncharted and around 42% are highly industrialised with the rest in between. So let's assume this "benchmark" is also true with Aspire … it's not much to go on.

So our guess gives us around 12 uncharted components and 42 industrialised components in our 100 component system. The 12 uncharted components are more in the experimentation phase, more suitable  for in-house, agile development techniques whereas the 42 industrialised components will be suitable for outsourcing to utility providers. The remaining are suitable for products ideally with minimal change. It's worth noting that you can also map data, practices and knowledge along with activities. 

Now, at the moment we can't say (without a proper map) if those figures are even roughly right but we can be pretty certain that Aspire isn't all uncharted and it isn't all industrialised. If you decide to outsource this entire project then you're going to be hit with excessive change control costs because those 12 uncharted components will evolve, they won't stand still and we don't really know what we want. No amount of specification will solve this. We have to (and literally are forced to) experiment. 

Of course, you don't want to run the entire project in an agile manner because at least 42 industrialised components are suitable for high volume, low cost, tightly defined utility like services. 

So lets go back to the Aspire article and look at some points in detail.

1) "it's heading for disaster", "it a fail" … well as the article seem to emphasise it has been a disaster for 20 odd years. There's nothing new here other than practices around how to manage complex projects have significantly changed during that time.

2) "plans to split into 100 parts" … seems to be cited as the problem. But hold on, this system probably contains a 100 different parts. So we want to pretend it doesn't?  Breaking complex systems into relevant components rather than pretending it is one thing doesn't seem a bad idea. We don't build cars by pretending they are one thing, in fact we often have complex supply chains meeting the needs of all the components. Now, we could simply break Aspire into the relevant components and offer one supplier (as we've done in the past) all the components to provide. Ideally you'd use a market but even with a limited choice then the advantage here is we can make sure appropriate methods, measurement and contracts are deployed based upon the component. It might make a little bit more work but we're talking about a project which already has a running cost at over £8 billion and is considered to be 'spiralling out of control'. From Amazon (see two pizza) to USAF (see FIST) to Manufacturing (see the entire industry) then organisations have learned how to manage effectively componentisation with supply chains and they certainly don't find it "too difficult to manage". Why not here? Why not Gov? Treating components appropriately seems to be the sensible thing to do.

3) "It will cause chaos" … cue the old "riots on the street" line.  Given construction, automotive and many other industries have no problem with componentisation and given a worst case of getting one supplier to build all the components with appropriate methods (which they're likely to outsource some of this anyway) then I can't see how we jump to this notion. We've continued to repeat the "one size fits all" approach which has led to countless cost overruns and failures. This seems to be scaremongering and I'm not sure what the objection here is to learning from other industries.

4) "hundreds of experimental startups" - ok, this one is becoming surreal. If you break a complex system into components then you're likely to give a large number of highly industrialised components to established utility providers (e.g. companies like Amazon for infrastructure) but you won't give them all the components because some are going to be experimental (they're uncharted). For these components then you're likely to do this in-house with agile techniques or use a specialist company focused on more agile processes. I'm not sure how the "experts" jump from componentisation (a sensible action) to giving it all to "hundreds of experimental startups". This wreaks of nonsense and a desire to keep the current status quo.

5) "interfaces" - this is where we use appropriate standards. Pretending a complex 100 component system with uncharted and industrialised components that have interfaces between them is in fact one system with a one size fits all method and non existent interfaces is fantasy. Those components are there, same as the interfaces. The complexity doesn't go away simply by "outsourcing". All you've done is try and pretend that the complex thing you're building is somehow simple because then it's easier to manage. It's barking on the delusional and it's extremely poor and dated management. It would be like BMW or Apple outsourcing their entire product lines to someone else and trying to have no involvement because it makes management simple. Whilst some have apparently said that HMRC "doesn't know what it's doing", it has obviously realised that doing the same failed process over and over again won't make things better. Good on HMRC.

6) "more expertise" - let us be clear, so far the "expertise" has managed to create "spiralling", "out of control" projects over a 20 year period. Yes, the project "spiralled out of control partly because of four major renegotiations" and yes, three of those negotiations happened between 2006 to 2009 with some absolute corkers like "granting exclusivity" and costs rising from £1bn to £8.1bn by 2009. It's worth noting that when this all happened was well before any apparent "imposed ban" on management consultants. By the way, the rate of cost growth seems to have dramatically slowed since the supposed ban. 

So, can I check that what we actually need  is more of "spiralling" and "out of control" costs because that's what the "experts" seem to bring or at least the data points to this. I certainly agree that the past vogue of outsourcing had weakened the government ability to negotiate but this is changing (see OCTO, see GDS etc). I can understand why we need to develop skills in contract management and supply chains which seems to be happening as this is a perfectly reasonable thing to do. Other companies have, why not UK Gov?  I'm not sure why we want to take a backward step here.

7) "500 people to manage 100 contracts" - ok, this seems to be one (and there are many) of the most exaggerated claims. I used to work in purchasing, I managed around 100+ different active contracts on a daily basis with over 100 different suppliers buying everything from stationery to missile components to jet fighters. I can sort of see the argument for a team of 25-50 (at a push) but 500. I'm guessing the "experts" would have us outsource that as well, probably employing them into the bargain. 

8) "Labour" - you could point out that such monolithic disasters using inappropriate mechanisms and excessive outsourcing occurred during Labour's reign and even make pointed remarks about Ed Milliband and Ed Balls involvement. Yes, the coalition has been carefully trying to unpick the mess that was created. However, it seems pointless to dwell on the past unless there's some belief that Labour is hell bent on recreating it. I don't believe that's the case, so this is just unhelpful point scoring by the Times. Not needed.

Overall, if the report is correct then yes we seem to have a mess of a project based upon outdated methods of thinking, The problem is that the "experts" then describe the same failed and outdated modes of thinking as some sort of future solution. The article doesn't stand up to scrutiny, you could drive a truck through the gaping holes in this one. 

Yes, some past disasters are bearing fruit and need to be fixed and no, that doesn't involve repeating the same mistakes which made those disasters. As Einstein pointed out, "insanity is doing the same thing over and over again and expecting different results". HMRC seems to be learning that.

But learning is not much of a headline or a doom laden story. Which then begs a question - why was this article really written? 

Well, as the article points out the changes have "created a backlash" and there's been "concerns over the merging of back office systems like HR and payroll". However, the civil servants I've met seem broadly supportive of the changes and understand the need to do so. Government isn't there to waste taxpayers money, it's there to ensure it is wisely spent on things we need.

So, who benefits from encouraging a move back to the past and creating fear, uncertainty and doubt over the current changes and practices? It's worth noting that these change have simplified Government websites, won design awards, led to significant cost savings (National Audit Office) and propelled UK Gov IT from a backwater to a model being copied by other Governments. 

The question you really have to ask is who stands to lose the most by the continued progress and wants to paint a picture of heading towards disaster. There are two fairly obvious candidates and this is the real question that we should be looking into. 

As for HMRC, well problems in IT are not new and it's good to see that changes are being made. Many of the problems of the past are almost certainly due to single size contracts and the "expert" opinion involved. Obviously you're ruffling feathers and that's a good thing. Keep it up.

As for the "experts" - bah humbug. Given the widespread use of componentisation concepts in multiple industries over the last decade then I'd be more inclined to haul these "experts" in front of the Public Accounts Committee and where necessary hunt down those involved in this mess and sue them into oblivion for negligence. As a taxpayer, I save my wraith for them and not HMRC. I fully understand the awful games and exploitation of change control for commercial gain that happens. My preference is to use real experts which Government is already developing in groups like GDS etc.

Good on HMRC, Good on UK Gov IT. Keep going.

---

P.S. For clarity on any bias I might have. Though I'm not an employee of UK Government (either full time or as a contractor), I do spend time at various Government departments teaching them how to map out complex environments along with observing impacts. UK Gov is a member of the private research organisation that I belong to (the LEF) and I'm given considerable freedom by the LEF and UK Gov to observe the changes. I also (many years ago) wrote the 'Better for Less' paper with Liam Maxwell et al. I'm also 'old Labour' and whilst I might strongly disagree with many coalition policies,  I'm highly supportive of the positive changes that I see being led by the Cabinet Office. You'll often hear me saying "Rock on, Francis Maude!" which gives you an idea of both my age and that I can't give two hoots about politics when it comes to having the right person in the right role.

Tuesday, August 26, 2014

How accurate is a Wardley Map?

I was recently asked how accurate the 'Wardley' maps produced of a competitive landscape are? An example map (an early draft for a border control system) is provided in figure 1.

Figure 1 - An example map.


So how accurate is it? 

Well, first all maps are simply representations of what actually exists and are hence imperfect. Second, mapping is still in its infancy i.e. we're only just learning about how to map competitive environments, how to deal with bias, how to learn and exploit the landscape. We've had about a decade of practice at tops and there is a long way to go. So whilst the maps are useful tools for discussion, for risk mitigation, for management, for scenario planning - they are not even close to being accurate.

In business, I'd reckon we're about the stage of early Babylonian maps when it comes to mapping out the competitive environment. Very basic, with some understanding of principles but still a lot more useful than no map at all.


Before geographical maps we used to rely on story telling and poems with named visible celestial features and prominent geographical landmarks to convey navigational directions. It's amusing how story telling is currently the vogue for business strategy. We've got a long way to go before we can reach the finery of military strategic play and situational awareness ... a very long way.

Dungeons and Dragons vs the art of business strategy

For those who have ever played Dungeons and Dragons then there are some basic practices which become ingrained. These same practices appear in MMORPG such as world of warcraft (WoW). These include ...

1) The importance of maps. Before launching your team of elves, halflings and dwarves into the midst of a battle then the first thing you do is scout out the landscape and improve your situational awareness. Understanding the landscape is critical to strategic play, to learning, to using force multipiers and to not getting spanked (beaten soundly by the opponent).

2) The importance of capabilities and roles. The biggest battles require a multitude of roles from damage (those who do our spanking usually from range) to tanking (defensive protection) to healing (those tanks get spanked a lot and need healing from our Clerics) to crowd control (those Wizard sleep spells aren't there for just looking at). The way you play and how the roles are deployed depends upon the scenario. Of course, without situational awareness then you're at a huge disadvantage.

3) The importance of team play. A multitude of roles requires team play which means communication, co-ordination, acting in the interests of the team etc. If you're taking on a Lich or a Beholder then your team (unless massively overpowered) better be on the ball. 

4) The importance of preparation. There's no point turning upto the fight with a Sphere of Annihilation if you don't know how to use it. Preparation, the role of each group, working with each other, timing and discussion of strategic / tactical plays are all essential elements to good play.

So, how does this compare to business?

1) Maps. In general we don't have them. Most companies suffer from poor situational awareness being caught out by predictable changes. The most telling factor here is that business strategy is normally a tyranny of action (how, what and when) as opposed to awareness (where and why).

2) Capabilities and Roles. On the whole, we do a bit better here as we recognise multiple capabilities (aptitudes) are needed. However, we often fall down by not considering attitude, the scenario (we have poor situational awareness) and isolation (operation in silos).

3) Team Play. We certainly try, often having team building exercises which can be a bit hit or miss. We often complain about communication despite the plethora of tools available. The problem can usually be traced back to poor situational awareness - if we don't know the landscape and create a plan of attack based upon this (replacing it instead with vague notions of vision or a story) then it's difficult to communicate how things are actually going.

4) Preparation. Almost non-existent. In some areas we might attempt scenario planning and a few exec games (e.g. imagine you're a startup trying to disrupt your business) but on the whole we're often so busy with immediate work (e.g. firefighting) that there is little time to build an effective and prepared team. The largest guilds in some of these MMORPGs have many hundreds to thousands of players supported with extensive wikis, communication mechanisms, training and development, tactical game plays, UI engineering, structure, leadership, specialist cells and information systems. 

There's an awful lot to be said for learning about these aspects from online games - though it's rarely done effectively. However for anyone under the illusion that business is some bastion of strategic play then can I suggest you spend a few minutes either watching an experienced group play D&D or an organised raid on WoW. Those people tend to use levels of strategic and tactical play that businesses can only dream of.

Fortunately in business we're often up against other organisations that equally lack situational awareness, suffer from isolation, have weak team play, poor communication and lack preparation. The effect is somewhat remarkably similar to a group of inexperienced D&D players just charging at each other. An exciting brawl of chaos with often single participants (hero players) making the difference. Of course, face either team (or in fact both teams) against an experienced and well rehearsed group then it stops becoming a brawl and starts becoming a massacre. Opposing Clerics get wiped first, followed by crowd control, tanks and then poor (and undefended) damage dealers.

In the world of business, there are some really dangerous groups out there e.g. Amazon. Don't expect to go up against them with the usual 'Charge!!' approach. You won't last long. That's a hint to those gaming companies starting to be concerned about Amazon's encroachment into their space. Start learning from your own online players.