Tuesday, March 19, 2013

Basics ... repeated ... again ...

I thought I'd put a quick post on some very super simple basics to any software project ... scrub that ... anything you're planning to build (business to technology to whatever).

Step 1 - Needs
If you're going to try and build anything, start with asking questions like what does this thing need to do, how will its consumers interact with this, what will they expect or desire from this. If you haven't got a list of needs, then STOP ... go write one (Hint: Post-it Notes are brilliant for this). It can be pretty high level and yes, some of the more novel "needs" are bound to be wrong. This is ok.

Step 2 - Write down the Value Chain
Now you have a list of Needs, write down the value chain i.e. the components you're going to use to build something that meets the needs (Hint: Post-it Notes are brilliant for this). You need to think about activities (i.e. systems you might use), practices and data. You can even include things which have never been built before (e.g. cat mind reading system) but at least put the effort into writing it down and what you think you might need to build it (e.g. servers, data storage, a large number of cat CAT scans - geddit).

Step 3 - Evolution
Now everything (i.e. activities, practices and data) evolves. For activities that means from genesis to custom built to product to more commodity. Knowing how evolved something is matters otherwise in a world of utility computing infrastructure you might start thinking that a custom built server makes sense ... it rarely does unless you can build more efficient / commoditised environments than currently exist. To identify how evolved something is, ask yourself the questions of how widespread (ubiquitous) and how well defined & understood (certain) that thing is and use the figure below. Go through your value chain and determine how evolved each of the components are.

Step 4 - MAP it!
Now you know what the components in your value chain are and how evolved each component is, then put it down on a map (Hint: Massive whiteboards and Post-it notes are brilliant for this). Use one axis for value chain and one axis for evolution.

In the tradition of TV cookery programmes, here's one I baked earlier. In this case in 2005 - a simplified map of part of the value chain of an online photo service known as Fotango. (NB. back then, I used to use the term innovation rather than genesis but alas since innovation is widely used to mean many different things I've chosen genesis to mean the novel and new).

Step 5 - Check the Map for unmet needs
Take your map and look at it. The top (higher order systems) should contain all the components that provide the visible need (i.e. what the consumer uses) along with areas of differentiation (i.e. novel and new). Check to make sure you haven't got any unmet needs i.e. missing bits.

 Step 6 - Check the Map for areas of efficiency
Take your map and look at it, again. Many of the lower order components will be hidden from the consumer (i.e. they don't know what CRM system you are using) however you may well be treating those components incorrectly i.e. treating a customer relationship management (CRM) system as something novel and new when it's more of a commodity. Look through and identify any areas which you could treat more efficiently.

Step 7 - Break existing model (if necessary)
In some cases you're dealing with an existing system which may be treated as though it's one thing. This creates all sorts of one size fits all problems as the characteristics of activities, practices and data change as they evolve. If you've got a large complex value chain which you're planning to outsource for example, break the model ... there's a better way.

Step 8 - Treat as Small Units
Break down large complex systems into small units because the way you treat each unit may vary (more on that latter). Ideally you can even organise around this e.g. copy Amazon's two pizza structure.


Step 9 - Apply the right techniques / methodologies
Now you've broken down the value chain into sensible component chunks start by making sure you apply the right techniques to the right stage of evolution. If you've got a management consultant in telling you that you can become an "Agile" shop or a "Six Sigma" shop then consider letting them go. There are extremely rare exceptions where "one size" works but for the majority you'll need to use both agile and six sigma and alter which technique you choose based upon how evolved something is.

Step 10 - Manage the Chaotic (the uncharted)
For example, the creation of novel and new (as in Genesis, Custom Built) should be done in-house with use of Agile techniques because of the chaotic nature of what is being managed (constantly changing, rare, highly uncertain, deviating from the past, unpredictable etc).  These activities are all about experimentation, gambling, failing (lots of this) and potential future value. If you can't afford to do this in-house, then hire a contract developer and ask yourself why are you doing this?

Step 11 - Manage the Transitional
The transitional activities (more evolved than chaotic, less evolved than linear) which are represented by products and rental services need to leverage the outside ecosystem i.e. buy products, listen to customers etc. These activities are ones which are becoming more widespread and well defined, they are becoming predictable, customer feedback and data is key etc. From a consumption point of view, try to use open means (source, data, process etc) where it exists and look for more open standards (saves future headaches).

Step 12  - Manage the Linear (the industrialised)
The more industrialised activities which are represented by commodity and utility services are ones which are  widespread, well defined, predictable and are all about efficiency and consistency. Use highly structured methods, outsourced to tightly defined contracts or even better utility services. Ideally you want a competitive market with switching so insist on open standards and open methods (source, data etc) where possible.

Step 13 - Shared Components
Once you've create one map of a value chain for your business then go create more. Once you have enough maps, start looking for shared components and start consolidating them.

Step 14 - Update your maps
Evolution is a consequence of competition (consumer and supplier) and it's continuous. So update your maps and make sure you know your needs, where you differentiate, the value chain, areas of efficiency, shared components and that you treat components with the right techniques. Writing a map for a value chain should only take a short time once you get good at (i.e. varies from 20 minutes to an hour or so). Updating is even quicker.

Step 15 -  Now you're ready
Once you've done the basics, you can now start thinking about how to exploit ecosystems or open mechanisms or dark arts to manipulate the map. You can look at competitors value chains, consumers and your own suppliers and look at the impacts of changing the environment. You can look to push something more open, encourage efficiency, drive development of higher order systems, create new sources of worth, undermine competitors barriers to entry, run a tower and moat play ... oh, there's a long list. You can start to predict obvious changes in the industry, competitor moves, deal with inertia, game your culture, create structures designed to cope with change, create centres of gravity ... oh, there's a long list.

However, most importantly you're in a position to discuss this, to talk about strategy in some form of meaningful sense, to talk about the why of action. All the previous 14 steps are about getting you into a position of talking about why.

Now in practice, you don't have to write out maps, you just need to ask equivalent questions. A mental model is fine as long as you can articulate the value chain, how evolved its components are, realise that you'll need multiple techniques and can play the game that way. I happen to draw it out because my memory sucks and the visualisation helps me explain to others what I'm thinking of doing. The steps above are of course a simplification, I didn't want to make the post too long but it's good enough.

Which brings me to the point of what not to do. Don't come and ask me a question about whether this or that strategy make sense unless you have done the above or something similar. I'm simply going to ask you "why" you're running this strategy? If you don't understand your value chain and how evolved the components are, then any strategy you have will either be shooting in the dark or because everyone else is doing this. 

If you want to really get up my nostrils you might tell me that your strategy is to be agile, efficient, nimble or innovative OR alternatively give me a long list of how, what and whens such as purchasing choices, implementation details, operational decisions or tactical choices OR you might just throw in a couple of buzz words like cloud, big data and social media to jazz it up. It'll be a very short conversation.

Situational awareness is essential to any form of competitive environment. Mapping is an extremely useful tool in this regard.