Apr 06
Better is the enemy of good enough
Mike Blair
I first started working at C/D/H in 1995. During my time here I’ve consulted in many technical areas including Novell, Microsoft and Cisco. As a network generalist, I gained a broad range of experience and skills that aid me in technical project management and IT strategy consulting. After going back to school and earning my MBA from Grand Valley State University, I found a passion for bridging IT with the business world. I discovered that there's a need for people who can talk tech and talk business.
I enjoy working with my clients on high-level strategic and financial matters related to IT and also working in the trenches, helping manage technical projects.
More about Mike
Articles by Mike Blair
I like to use our internal theme of “predictive excellence” in my writing because it can be applied every day in project management. This month I have one of my favorites.
A common mistake is when people use the concepts of excellence and perfection synonymously. Sometimes these words are used interchangeably by project stakeholders to envision project deliverables.
A typical scenario looks like this – a client comes to us and describes a project in terms of functionality, budget and timing. We all agree to the scope and off we go. The project cruises along, following our methodology, we gather requirements, design and develop the solution and jump into testing. No problems.
Then we hit a snag. The solution appears to deliver all of the stated requirements; however, testing is taking much longer than expected. We are having longer status meetings and the issues list is getting longer, not shorter. The budget is looking thin.
What’s happening?
One possibility is poor quality. That makes the most sense, right? We just produced a buggy solution. Not true. One of the great things about working at C/D/H is that we have some of the smartest, most experienced people in the business. “Buggy” just isn’t in our vocabulary. We don’t deliver buggy solutions. This just isn’t a problem that I have to deal with at C/D/H.
The reality is that, more times than not, these symptoms indicate that we’re dealing with the exact opposite problem. Once we hit testing, either in development or user testing, our developers or users find small ways to make the solution “a little bit better.” The stakeholders involved lose sight of the original scope and requirements and fall into a sort of “perfection quest.”
Small ideas pop up all over the place. You start to hear things like “it’s just a quick fix” or “this will take less than an hour.”
These are all warning signs. Many times these ideas are justified by saying it will make the solution “better.”
There’s a quote by Voltaire – “The perfect is the enemy of the good.” It’s been adapted and changed many times over the years. One modern adaptation that I’ve borrowed to describe this scenario is “Better is the enemy of good enough.” What it means is that by seeking the better solution, you may do so at the cost of that which was originally desired. This happens when several small tweaks to make the project better add up to delays and budget overruns.
When this happens, and we develop the perfect solution but go over budget and are two months late, have we achieved excellence?