PUTTIN' COLOGNE ON THE RICKSHAW

Last week I talked about the chronic problem of over-commitment that plagues the business world today. I looked at the causes of this universal problem from the perspective of what organizations require of us on a daily basis−the cultural norms−plus our own personal bad behaviors and mindsets that get us into the mess of over-commitment.

There’s also another problem that’s both personal behavior related and many times an organizational problem. It’s what’s called the “Polish the Cannonball Syndrome.” This is a malady that affects organizations where design of new products is one of the mainstays of the business−this plague is especially prevalent in high-tech industry.

Since business today is all about “time to market,” the lower the time to get a new product to market can make all the difference in beating the competition. However, as we found out last week there’s the conspiracy of over-commitment that ham-strings many organizations into realizing the quickest time to market.

By the same token we have the “Polish the Cannonball Syndrome” that adds a new dimension to why projects take longer than planned. It revolves around the fact that engineering will continue to tweak a product design despite it already meeting the basic requirements for functionality. This tweaking includes adding features, with sometimes little value, or making irrelevant improvements that don’t affect product functionality. Thus extra time is spent on the product that delays its release.

It’s not quite organizational anal retention, it’s more that engineers like to engineer. Designing new products captures an engineer’s imagination and attention in such a way that they get distracted from the bigger picture (time to market and basic functionality) and go off in tangents instead of remaining focused on the goal.

Social technology analyst Jeremiah Owyang has also coined the phrase for this behavior/obsession as “Fondling the Hammer.” Hammer-fondling has to do with people that focus too intensely on the product hardware and not on the overall mission of the product. An example would be in building a house. The mission is building the house and the hammer is but one of many tools to accomplish that goal. Concentrating on the hammer doesn’t necessarily get the house built on schedule.

There’s also another problem within modern organizations that I’ve written about before in the post titled “The 80% Solution.” The crux of that post was that for many organizations there is no “notion of doneness.” Without it, projects just keep spinning on indefinitely, and thus never come to closure−80% being the goal or not.

Organizations need exit strategies and impending deadlines for every project they undertake, otherwise Polish the Cannonball Syndrome will set in. However, exit strategies and deadlines many times still don’t mean that a project comes to a timely end because every product design reaches that point where you think the product is releasable yet there will be a whole list of things that still need to be done to it.

The problem is that “doneness” is more a mindset than anything concrete, or subjective, in nature. In engineering-heavy projects you have the dogged determination to deliver the perfect design. So long as the engineer is active the project will continually evolve−keeping the design constantly in a state of change. To break that cycle you need strong leadership, for as the old saying goes, “sometimes it’s time to shoot the engineers and go into production.”

There comes a time when all projects/products should be taken out in the woods and shot. The only exception to this is a software project. These are, by definition, never done. The need for software changes will linger like a plague long after the product has shipped, e.g., MS Windows.

Alas, most projects are in a perpetual churn of change, without any way to escape. That’s because engineers want to know their product is perfect, better than the competition’s; that it’s bug-free and feature-rich. If their solution is elegant and clever, they are satisfied. However, they rarely consider whether their solution is to the correct problem. Engineers are perfectionists−they’re willing to put in extra hours to fix a bug, or add a capability, that only they know about and that will never affect a customer.

It’s this obsessive-compulsive disorder (OCD) that is really at the heart of this problem and a basic characteristic of all engineers. For an engineer the most interesting phenomenon is the one that is out of place. It is the signal that there is more than meets the eye and thus more to be done. As science fiction author Isaac Asimov once said, “The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ (I found it!), but ‘That’s funny…’”

So what’s the solution? It’s quite simple but none the less hard to implement. From my experience the solution comes down to leadership−doesn’t it always? My take: the difference between a perpetual project and a successful project−one that finishes on time with a high quality output−is the project manager. Organizations need anal retentive control freaks in these positions−better yet a benevolent dictator−who never loses sight of the project’s original set of goals and end date. With that focus, the project has a fixed notion of doneness, i.e., some delivery criteria or a point where the project manager can look at what’s been accomplished so far and say “there, it’s done.”

The thing to remember is that the Polishing the Cannonball Syndrome is completely natural. It’s even explained by the Second Law of Thermodynamics which states that the entropy (doneness) of an isolated system (design) never decreases, but evolves toward thermodynamic equilibrium which is the state of maximum entropy. The second law asserts that a natural process (engineering design) runs only in one direction, and is not reversible or stoppable. For those that may not know, entropy is define as a “gradual decline into disorder,” i.e., chaos. From my experience, this describes perfectly how many product design efforts end.

The bottom line is as Scott Adams tells us, “Engineers like to solve problems. If there are no problems handily available, they will create their own problems.”