I'll huff and I'll puff and ... ohh I like how you've painted it.

Whenever I'm mapping out the activities (for example business processes) of an organisation, I try to use colour codes for the different lifecycle stages of an activity. I find this helps me when visualising what the organisation needs to do and how it needs to change.

It's just something I do. I've provided four images to show the colour codes I use.

Stage 1 - Innovation, First Instance
(click on image for larger size)

Stage 2 - First Movers, Bespoke examples
(click on image for larger size)

Stage 3 - Transition, Products
(click on image for larger size)

Stage 4 - Commodity.
(click on image for larger size)

It's worth remembering that any activity has an effect on the organisation. In the case of a created product the effect is overall on cashflow, however you could equally have a process whose effect is on the efficiency of operations and cost reductions.

Generally, any innovation should be built upon many commodity or transitional like activities. If it's not, you need to ask yourself why not?

Componentisation of systems into activities and use of commodity components where possible is a massive accelerator for innovation. It is the reason why I advocate using Service Orientated Architectures (SOA), Software as a Service (SaaS) and Enterprise Architecture (EA) frameworks like Zachman.

The speed at which a complex system evolves is much faster if it is broken into smaller stable components and hence organised into one or more layers of stable subsystems (for more on this read up on Howard Pattee).

If you:-

1. take a system of k elements
2. group every s number of k elements into a new component, l
3. group every s number of l components into new component, m
4. keep on repeating this grouping until you can't group any more

Then, with each component being considered stable, the rate of evolution of the system will be proportional to the log to base s of k.

To show this in action, consider the three little piggies building a house. Let's say each house requires 100,000 bricks and whilst the big bad wolf can blow down an unfinished item, any stable component is too strong to be blown apart. Our three little piggies will follow different strategies:-

• Piggy 1 : Build the house in one go with each brick being a single component.
• Piggy 2: Build stable components, each component containing 10 sub-components. i.e. 10 bricks = a line. 10 lines = a section of wall etc.
• Piggy 3: Build stable components, each component contain 100 sub-components.

OK, let's say on average you can put together 1,000 components before the big bad wolf returns. Then :-

• Piggy 1 : will never be completed.
• Piggy 2 : will be completed by the 12th visit of the wolf.
• Piggy 3 : will be completed by the 2nd visit of the wolf.

In general: build in blocks, use small stable components.

[NB: For simplicity of explaining the analogy, I've taken the initial act of combining 100 or 10 or 1 brick(s) into one component as creating one component. If you instead treat each brick as a component, then the times are Pig 1: Never, Pig 2: 112 visits, Pig 3: 102 visits.]

It sounds obvious, but knowing the lifecycle stage of an activity along with componentising systems which can be componentised is a necessary step to increasing innovation. In other words: if someone has already built a hammer, use it and don't rebuild it.

Equally essential is to use different methodologies at different stages of an activities lifecycle (it's not agile vs six sigma or networked vs hierarchical or innovation vs efficiency - it's a mix of each, all the time). In other words: get used to living with change.

Using such an approach you can balance the innovation paradox between the order needed to survive and the disorder needed to create a future.

In summary: build in blocks, use a hammer, expect the plan to change and don't forget to add a splash of colour.