Why Map?

Mapping is all about situational awareness and understanding the context of a complex system whether an organisation, a line of business or a technical system. Without good situational awareness then it's extremely difficult to identify where to attack and hence strategic why (since 'why' is a relative statement - why here over there). It's even difficult to know how to manage something.

Without this, you might as well write a strategy which starts with general platitudes :- 

"We're going to be innovative, be efficient, be agile, focus on core, create a strong culture, create shareholder value, and establish ourselves in [XYZ]"

Where [XYZ] is fundamentally what everyone else is doing - cloud, social media, big data, digital first, 3D printing - i.e. replace with whatever is popular amongst competitors at the time in hand and hence currently reported in the popular management press - HBR, Economist etc.

From my own work, the problem with situational awareness stems from how we view the landscape. In figure 1 is a typical box and wire diagram for a large complex system (this could be an IT architecture diagram, a business process map, a user flow diagram etc). I've removed the terms of the components so we can focus on the diagram.

Figure 1 - A typical box and wire diagram.

It's a great wiring diagram from the point of view of plugging boxes together whether those boxes are technology systems or business processes but it's less than ideal for strategic planning.  The diagram tells us nothing about how to manage the environment, where there might be opportunities to attack, how to play the game and how things might change.

So, in figure 2 here's an alternative mapping view from @crankypotato and his post on mapping. Now I know nothing about what value chain this represents because they've not given me the terms (it's a blank diagram) but there's an awful lot I can say about game play from this diagram.

Figure 2 - An unknown value chain

First of all, from the above I can immediately identify what should be representing the visible need of the user.  From this I can determine a few potential differentials. At the same time, I can see what are the hidden components and where potential opportunities for efficiency might exist (targets). I'll also note that two of the more hidden components appear to either be operational advantages or potential constraints. I've summarised this in figure 3.

Figure 3 - Needs, Differentials and Efficiencies.

I can also now look at focus and parts of the map clearly need an experimental focus e.g. minimal viable, willingness to experiment and fail etc. Others need an approach of feature differentiation and tight feedback loops whilst the more hidden components I should be looking to drive towards more commodity, standardising with open approaches and the use of competitive markets where possible. I've summarised this in figure 4.

Figure 4 - focus

Now, I can start to look at how I can manage things. Obviously in practice I'd challenge the map and question whether some of the activities are really as they have been described. It's quite common for people to describe something which is ubiquitous and well defined as needing a custom built solution when in reality it doesn't.  However, assuming the map is roughly right and there's no glaring errors (like treating a CRM system as bespoke) then it's fairly easy to identify what should be built in-house with agile techniques, what should be a modified project, where we should be using out of the box and areas where we should be looking at more utility or cloud services. See figure 5.

Figure 5 - How to manage?

Ok, now at this point I have an idea of where I can find differentials, areas of efficiency, the focus I need and how to manage but I've got a question of how to measure?  The mechanism of measurement will vary again with context, so I can take a stab at what I should be using. This I've added in figure 6.

Figure 6 - How to measure?

Now, I have a basic understanding of the landscape, what to focus on, how to measure, how to manage etc.  I can now take a look at where to attack. Remember that disruption can occur in the product space with substitution (i.e hydraulic to cable excavators) but that's difficult to predict. Evolution from product to utility is again disruptive (combination of inertia with a punctuated equilibrium) but its far easier to predict. So, I can look at the activities (or practices or data) and identify those which are suitable for utility provision, where inertia barriers exist and where I can build ecosystem (exploiting an ILC like model).  I've summarised this in figure 7.

Figure 7 - Possible "where's" to attack

Once I've identified the where, I can look for why this route over that (i.e. type of competitors, probability of exploiting inertia) and ask questions of how I do this? Can I use an open approach to drive commoditisation and create a competing market, can I alter buyer / supplier relationships, can I undermine barriers to entry in a competitor's space, can I build a tower and moat play ... a long list. 

I can enhance this further by looking at competitors maps, anticipating likely changes and potential competitor constraints. The more details I have (i.e. what the dots in the diagram actually mean) then I can dig further and write some form of sensible strategic play. With more maps, I can build ways of identifying common service and I can even look into how to organise a company avoiding the usual business alignment issue (an artefact of structure). 

However, that's not the point of this post. What I wish to demonstrate is that mapping is a far more useful tool for strategic planning than the box and wire diagram. Certainly box and wire can't be beaten for implementation but for strategic planning ... they're lousy.

Without good situational awareness then any strategy is likely to become full of how, what and when (i.e. implementation, operational, tactical and purchasing details) with little or vague "why" which where it exists will be one of those common platitudes.

Whilst I have no idea of what value chain @Crankypotato is talking about (i.e. I don't have the details), I can already ask some reasonable questions and if we ever sit down to discuss it then we can have reasonable debate on what the map means and how to manipulate the landscape.

This is why mapping is a useful tool.

When should I fire my CISO?

If you've ever been a CEO of any company then you'll quickly learn the role is not just about leadership and strategy but also about balance. Whether balancing existing business models and the inertia they create with the future, the culture that has been created or the various factions within it. 

It's very easy to lose sight of this balance. 

Everything we do is ultimately about meeting some user need. Those needs are multiple from the thing itself, the way it is operated, how it is interacted with, the experience, any regulatory requirements and any needs for security. Those needs also vary according to the type of user and what we're doing (the context), so for example security needs for a private wiki are somewhat different for a public wiki.

All of these needs have to be balanced with the context in mind. 

It's therefore a dangerous route to allow one need (such as user experience) to override all other needs (such as security) and establish itself as a principle for the organisation. It is dangerous because the needs vary with the context and so you can't have generic principles but instead end up with vague platitudes like "appropriate security measures need to be taken", "appropriate UI design is needed" etc.

Such "principles" give ample opportunity for groups to run amok in an organisation and a plethora of such principles loses sight of the one thing that matters - meeting user needs.

And that ultimately is the balance that a CEO needs to continually maintain by creating an environment which  meets user needs today and the user needs of tomorrow (the two are obviously not the same). To make matters worse the meeting of user needs today (i.e. a successful business model) will invariably create practices and cultural norms which will resist meeting the user needs tomorrow (i.e. inertia to change). This all has to be managed.

In specific circumstances such as when the change is unexpected (i.e. difficult to predict) this inertia can have dire consequences for an organisation through disruption. Examples of which are product substitution such a cable versus hydraulic excavators or different sizes of hard disks. This is what is classically called disruptive innovation.

In other circumstances such as the evolution of an act from a product to a utility (e.g. cloud) then the change is expected and can be managed with planning. Often companies get disrupted in these circumstances but that's really a consequence of executive failure and CEOs snoozing at the wheel.

But let us assume you're wide awake, you understand the issue of balance and the importance of user needs. So, what has this got to do with the CISO (Chief Information Security Officer)? The problem is Shadow IT.

Shadow IT occurs when your organisation is screaming at you that you're not meeting their needs and so they've gone and found their own way of doing it. Shadow IT is born out of frustration, it's a worrying sign that something has gone wrong with the balance.  Now, it's not simply just a case of users using some other more useful service to get something done because we've given it a name - 'Shadow IT'. The name implies its outside of our norms of operating which means our norms of operating aren't meeting our user needs. This should set alarm bells ringing.

At this point the CEO should be asking the CIO and CISO what is happening? There are two key message which are important.

If you hear the message that we need to make 'Shadow IT' part of the norm by enabling our users to use such services then this is good news. The focus is on user need, it's about abolishing 'Shadow IT' by making it an operating norm and by applying any techniques needed to ensure our other needs (e.g. security) are met.

However, if you hear the message that we need to ban 'Shadow IT' and force users to use our systems then you know that one user need (security) is overriding other user needs and you have a problem. This is the point where you need to start thinking about pruning some attitudes from the organisation.