Published in Computing, 19th Feb 2004, page 18, under the title Entropy and Ivory in Imperfect Harmony

Or Leeming’s Laws of Paralysis and the Common Incapability Index, CII (pronounced sigh)

Large corporations have someone in their IT department to control who has Internet access, who has intranet access only, and who has no browser on their desktop. They have someone to control who has external email access, or internal email only, or no computer access whatsoever. The controllers have a manager, who manages how they prevent people from doing things.

Such an example is the tip of the iceberg of effort being expended by IT departments without any measurable outcome. The bootprints of many more policies leave common sense huddled and bleeding in the corner, unable or unwilling to surface. Technology, once the enabler, becomes the tool for enforcing incapability in the name of cost and risk control.

The NHS, our flagship and largest institution, asks for an extra two billion for IT. What are they thinking? Is that 100 million for development and support, and another 1900 million to overcome the incapability?

Incapability hangs on two factors: latency and entropy. Latency is a measure of how long it takes between asking for something and getting it, or even getting a response. Entropy is how much energy is lost to the process. Latency and Entropy make things more difficult.

First law of Paralysis

The larger an organization is, the greater its latency and entropy will be.

Second Law of Paralysis

Kipling wrote: “When thou hast seen the elephants dance…”, and he meant never. Management bigwigs Rosabeth Moss Kanter and Lou Gerstner seek to persuade us otherwise, and as Professor C.K. Prahlad said in his address to the Strategic Management Society in 1988, "Successfully managing large, diverse nations like India is like teaching elephants to dance. The important thing is that once they start dancing, everyone else has to leave the floor." IBM is looking like the dance leader. India is singing at the same time. Our internal IT efforts, gnat-sized by comparison, are grinding to a halt. They are tomorrow’s wallflowers, standing back as the elephants waltz, puzzling their own incapability.

Laws of Paralysis through Entropy

• Each piece of policy limiting access to an application or technology will increase entropy.
• Each piece of technology performing the same task will increase entropy.
• Entropy increases around bonus time*
• Each form filled in increases entropy
• A poor working environment increases entropy

* On average, people are optimistic. This leads them to expect a bigger bonus than they actually get. They are disappointed. Disappointment leads to higher entropy. It is better to have no bonus system.

Laws of Paralysis through Latency

• Matrix management increases latency
• Each layer of management increases latency
• A rhythmic release process without the rest of VRAPS increases latency
• An IT department likes to form itself around a business strategy. If there isn’t one (which seems to be commonplace at present) then latency, via indecision, increases
• Each point of authorization in a process increases latency

The Common Incapability Index

• No defined process to follow
• Hard working skilled people working in tight teams who get the job done
• Architecturally led software development
• VRAPS development for COTS software products
• XP style development principles

• A defined process to follow
• Non-technical project management

• People who want to create roadmaps and frameworks and implement CMM 3 while they’re still at CMM 1
• An architecture team, but no architecture
• Waterfall passes between analyst/developer/tester/deployer
• Project management, but no programme management

• A plethora of energy-sapping rules which prevent anyone from being enthusiastic for long
• Waterfall passes and sign off processes
• Many programmes of work without cross-programme management
• Senior managers micro managing many layers beneath them

• Hiring good people will make no difference.
• Hiring more people will make no difference.
• Increasing the budget will have no effect

I have mirrored the CMM’s 5 levels of maturity to highlight that a decrease in incapability is required by those reaching for higher levels of capability. Many companies ‘put in’ CMM without reducing their incapability, resulting in no measurable increase in their ability to repeatedly create software. In the diagram below, the unreachable land exists not because once you reach for higher levels of maturity, your incapability evaporates, but because you will never reach higher levels of maturity without reducing your incapability.

Common Incapability can only be defeated by common sense. But it is common knowledge that common sense is uncommonly rare these days.

Acronyms:

CMM: The Capability Maturity Model from the Software Engineering Institute (SEI)
NHS: The National Health Service
VRAPS: Vision, Rhythm, Anticipation, Partnering, and Simplification
XP: eXtreme Programming
COTS: Commercial Off the Shelf Software