Wednesday, January 18, 2012

"The Perfect is the Enemy of the Good"

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!  

Wednesday, January 4, 2012

Excuses, Excuses!

You’re a manager and you’ve asked a member of your team to do a job. You’ve told him what the job involves, and you’ve given him the timeframe it needs to be done in. He agrees to do the job, says he understands what the job entails, and promises to deliver it in the required timeframe. You walk away confident that this job is in good hands, and will be done well and on time. You feel comfortable that you can move on to other critical people and items you are responsible for within and outside of your team. 

You hear nothing from this person, and assume all is going well (Your first mistake! Never assume!). You periodically check in with the owner of this job, and he tells you that while the job is going well, he is seeing problems in one area, but that you don’t need to worry about it; everything is under control (another warning sign!). Then you hear from others about some other problems this person has mentioned to them that make you question what you heard directly from him. So you go back to him and check again. Now he starts to tell you about more problems and gives excuses about why it’s not his fault, or about how he’s not getting what he needs from someone else, or myriad other excuses. The excuses start to grow, but you hear about them only when you approach this person (not the other way around).

Then he misses a critical milestone, and when you ask why, he gives you excuses and more excuses. Some sound reasonable; others do not. When you dig deeper, you learn that he has been having problems all along and seems to be in way over his head. When you confront him, the number of excuses rapidly cascade even more, with blame placed on everything and everyone but himself. He admits he’s in deep trouble, but that it isn’t his fault! (Waa!) So much for promises, and say goodbye to delivery! [See Promises and Delivery] If you were aware of the problems from the outset, corrective action would have been possible (e.g. involving others with more direct experience). However, since the problems were hidden from your view (were they really?), the situation has now reached a critical point. His actions are disruptive to your organization, likely to other organizations, to the point where the overall project may now be in jeopardy! 

What can you do to prevent such situations?