Wednesday, January 18, 2012
When you begin work on a new project it is usually an exciting time when anything seems possible. Everyone is brimming with new ideas and a strong desire to do everything right. The initial optimistic view is that this time we’ll develop the perfect product following the perfect plan using the perfect team. It would be truly wonderful if that would be the case, but typically life intervenes to throw you some curves (see The Best Laid Plans … and Then Life Happens!). Aiming for perfection may be a noble objective, but achieving perfection is another thing entirely There is a quote from Voltaire from 1764 that literally translated is, “The best is the enemy of the good.”, but this is more commonly cited as, “The perfect is the enemy of the good.” What this means is that pursuing the “best” or the “perfect” solution may end up doing less actual good than accepting a solution that, while not perfect, is effective. As you’re undoubtedly aware by now, my blog posts, newsletters, and my consulting practice are all about effective solutions. George Patton may have said it a bit better for more modern times: “A good plan implemented today is better than a perfect plan implemented tomorrow.” The reality in virtually every case is that perfection is never realized. People often use the promise of perfection (or the expectation of perfection) as a rationale for doing nothing, rejecting actions that would achieve beneficial but not perfect results.
Here’s a fairly simplistic example from my distant past where a “good” solution enabled a design to move forward quickly, where a “perfect” solution would have taken significantly longer with no real impact on the outcome. Way back when, in the days before microprocessors (I’m clearly showing my age J), I was tasked with implementing an iterative algorithm using gate-level logic that theoretically required a number to be divided by 18. Well, dividing by 18 in those days was difficult, to say the least. However, dividing by 16 was trivial, consisting of shifting the binary number 4 positions to the right. Since the algorithm was iterative, part of a tracking loop, it homed in on the same result whether dividing by 18 or 16. So a “good” approach took almost no time at virtually no additional cost, where a “perfect” approach would have taken far longer, at significantly higher cost, and would have yielded the exact same result.
A good way to think about “good” versus “perfect” can be found in the 80-20 rule that applies broadly to most things in life; that is that 80% of the benefit typically comes from 20% of the work. [In my specific example above it was more like 99-1; that is 99% of the benefit came from 1% of the work.] The 80% of the benefit is the “good” solution. The last 20% of the benefit, achieving the “perfect” solution, most often requires four or considerably more times the work. People who believe that perfection (100% benefit) is only slightly more expensive/difficult than good (80% benefit) are deluding themselves; it simply isn’t true! Perfection is a mirage. You can’t reach it, and the more you try to get to it, the more time you waste. More often than not, the time and cost required to achieve perfection results in a product not being released or a service not being performed at all. In most situations it is far better to know when good enough is enough and not to worry about making the perfect choice. It is better to get something done imperfectly than to get nothing done perfectly!
Often, the difference between “perfect” and “good” is an issue of timing. In the same time period as my example above, our organization at Bell Labs had a talented group of scientists who developed a large body of work relating to data communications. They postulated solutions to pressing problems that were forward thinking, elegant, and solid. However, in many cases their solutions were substantially ahead of where the technology was. For engineers like me, their solutions called for a technology (digital signal processors) that simply didn’t exist at that time. A few years later, when that technology did exist, their solutions could be implemented and proved to do everything they said they should do. By then, more “perfect” solutions were practical and cost effective to implement. Of course, by then there were new problems, requiring even newer technology that didn’t exist, and had to wait a few more years for “perfect” solutions to catch up. In the meantime “good” solutions had to suffice.
I submit that engineering itself is the embodiment of this quote. Engineering is taking ideas and reducing them to practice. Scientists generally work in the theoretical realm, developing theories of how things came about or theoretical solutions to difficult problems. Their concentration is on developing mathematical explanations of, or solutions to underlying problems. Their world concentrates on the “perfect”; the “perfect” explanations and/or the “perfect” solutions. Engineers are the people who develop practical implementations of what the scientists postulate. Engineers concentrate on the “good” solutions.
More broadly, most people who live in the real world, as opposed to the theoretical world, are, like engineers, people who concentrate on “good” solutions to pressing problems. This involves making practical decisions that enable the intent of ideas to be implemented even if the perfection in these ideas can’t. This is true for sales, marketing, services, customer support, manufacturing, operations, finance, etc. Aiming for excellence is fine and to be encouraged, but demanding perfection is plain bad engineering and business practice.
I’d like to thank my old Bell Labs friend, George Scott, from those same days as discussed above, for suggesting this topic. It is timely and timeless, and applies broadly to almost anything we do in life.
Copyright 2012 Workplace Insanity, All Rights Reserved