Twitter is an incredibly useful medium for numerous reasons but one of the things I like is that every now and then you're asked great questions. One of these for me was from Florian Otel on the use of incrementalism and the "art of muddling through".
To give a bit of background, when I talk about strategy it's all about the where (to attack) and the why (a relative statement of why here over there). Tactical choices are all about how you go about something and finally the what and when is simply implementation and operational planning.
Most strategy documents I read have a tyranny of how, what and when and very little of the why because the where is almost always absent. I know they're called strategy documents but I usually refer to them as tactical and implementations plan with no strategy. On the most part, they're fairly hopeless.
Now in order to plan out a strategy you first need to map the landscape in order to determine where you might attack. For the last eight years I've happened to use a technique called mapping to do this though other techniques exist.
In figure 1, I've mapped out a hypothetical value chain of an organisation which is built from components (including activities, practices and data) over the state of evolution of the components. I will use this map to identify where I might attack and then determine why one route over another.
Figure 1 - A Map
I'm not going to go through that exercise for now, since the above is a hypothetical example but instead I'll assume I've done the work and determined that the best option for strategic gameplay is three routes described in figure 2.
Figure 2 - The Strategic Play
The three routes are :
Step A) : A particular activity we consume is currently provided custom built and in-house but it is widespread and well defined enough to be suitable for provision by a product as evidenced by existing products on the market. I will therefore move away from our custom built example to using a more standard product with a view of minimising customisations.
- How to go about it? I'd examine competing products for fit, check to ensure that data is extractable (i.e open data formats etc), determine standard market KPIs for implementation and probably implement with a waterfall method. A key part of this is ensuring that data is extractable because I know at a later stage the activity will evolve to a utility and for reasons of past business model it is unlikely that my vendor will provide the utility, so I'll have to move again. I'd therefore concentrate on what the cost of exit will be, aim to minimise it and certainly factor it into any purchasing decision.
Step B) : A particular activity we consume is provided as a product but it's widespread and well defined and suitable for utility provision. The technology exists to achieve this, I know customers are dissatisfied with the product cost but no utility provider exists. This is an opportunity for me.
- How to go about it? If I have the technical capabilities then I'll aim to provide a utility service to the market based upon our experience of the product. We will focus on providing the utility through APIs and building up an ecosystem with an ILC model. Ecosystems are valuable future sensing engines if used correctly. I know existing vendors will have inertia due to past business models, this is beneficial to me. I know existing customers will have inertia due to past practices, changes in relationship (social capital), knowledge capital, prior investment along with concerns over lock-in. I'd look to counter by adopting an open approach (e.g. source). Since the activity is well known and defined, my focus is on industrialisation and hence I'd use a structured approached designed to remove deviation e.g. six sigma / ITIL.
Step C) : We've identified a concept for an entirely new activity which we believe has potential of being a differential.
- How to go about it? This novel act is uncharted by nature (being novel and new) and hence highly uncertain. It's a gamble but might provide us with a differential for our customers. I'd aim to minimise any costs by ensuring that underlying components consume commodity or utility services where possible. The approach we'd have to take is incremental i.e. we're going to be exploring our way and change is a necessity. I'd focus development on in-house with use of agile techniques (which include Test Driven Development). TDD is essential because though it incurs some overhead it reduces the overall marginal cost of change and I'm expecting lots of change. The approach will be one of minimal viable offering, quickly gathering feedback and "muddling through". We don't know what we will end up building, we'll have to find our way.
Now, as per normal practice I'd break activities into small components with small teams (think FIST, Two Pizza etc) in order to focus on the right approaches, create the right cultural fit for that activity and use the right sort of people (pioneers, settler, town planners) but this is getting more into operational details. The point of the above is to show that once you've determined where and why, then the how varies accordingly. All three steps would probably occur simultaneously. Hence at the same time an organisation might embark on efficiency in one area, building of a utility in another and creation of entirely new activity with each using different approaches and methods.
Try doing that with one size fits all methods like "we're an agile shop", "we're a six sigma shop" etc etc. To answer Florian's question - incrementalism is a tactical approach (a how) to a specific type of problem.
Try doing that with one size fits all methods like "we're an agile shop", "we're a six sigma shop" etc etc. To answer Florian's question - incrementalism is a tactical approach (a how) to a specific type of problem.
Now, if the above doesn't make sense to you, well I've been doing this for eight years and so it's easy for me to gloss over things and take them as granted. I will at some point write another beginner's series on this, just not now.