Don't Let Perfect Be The Enemy of Done

A problem not often discussed in management is employees that are too conscientious and so eager to make an excellent product/program/etc. that they may, in fact, blow right past deadlines in trying to put out the best possible thing they can produce. On the face of it, it's a good problem to have all things considered: folks working with and around you with little interest in the best outcome is a completely different, and very serious problem to have; its hard to get people to care, but it is easier to reign in folks that care too much. Many people would be stoked to be with a team that puts quality above all else.

However, there's a reason that Voltaire wrote "Le mieux est l'ennemi du bien," frequently translated as "The perfect is the enemy of the good." Even in his day, a missed deadline was a missed deadline, and it didn't really matter how seriously awesome the castle walls were if they weren't up by the day they were being attacked by the British.

It is a fine balance between focusing on quality and focusing on the deadline. Delivering a product on time with too many bugs and not enough features should be just as bad as missing the deadline, but having great quality two weeks later. Sadly, it typically isn't because most companies measure success by meeting deadlines. While bugs creeping into 'finished' projects at the end often cost the company considerably more than what they would have if they'd been eliminated in the design phase, the types of measurements for fixing critical bugs don't often factor into the review process for the folks setting the release cycle. Additionally, the bugs that don't get fixed--in favor of putting in more features, for example--have no easy method of measuring affect to the users of the product unless they are very severe, in which case they affect the trust relationship with the customer. Understanding of this affect goes from 'hey, nothing's wrong, we rock' to 'crap, they hate us, what now?' pretty darn fast.

Not all companies judge strictly by the requirements of the deadline; but in software, my experience has been that at least 75% respect the deadline more than just about anything else. So deadlines are important. However, so is quality.

While I've discussed that it's hard to quantitatively determine loss of productivity and money in terms of missing bugs, I can say that there are losses if not all features are implemented, and those are very easy to ascertain. In working on a banking application, for example, failing to complete the user creation portion of the process renders the rest of the program useless, because users cannot log in to access their account information and/or make transactions. For a social website, completing the e-commerce component but failing to provide the services promised by marketing--for example, forums for the users to discuss things--have immediate impact on sales and the future success (if there is a future) of the product being constructed.

Thus, the quandry: the item needs to be built and delivered on time to preserve you and your team's reputation and your livelihood within the company as well as the company's livelihood, but it also needs to be feature robust (at least to some extent of the promises made by marketing/sales so people will buy/rent/use it) and as bug free as possible (to avoid affecting future feature creation which would be delayed by mission critical bug fixes or, worse, loss of trust with clients over severity of live bugs).

Take this quandry to a team of professionals who are here to kick ass and chew bubble gum, who are now all out of bubble gum, and you are in a position where you have to balance their natural desire to kick ass with quality as well as to kick ass within the assigned time frame.

Whether your industry is computer/IT (like mine) or building ambulances, you need to build in quality as part of the construction process of the product. Including quality in the feature creation and description will help you estimate the time to complete those features, quality included. In my previous article on the iron triangle, you have three axis to play with in order to complete a product: resources, schedule and scope. Including quality in the construction of the scope gives you information about the schedule, and can let you know early on if you need additional resources.

Prioritizing the scoped features is another huge help. Folks concentrating on quality will feel good about knowing what the most important items are to be quality, versus the items cared less about product management. For example, in a software product, the additional work to completely redesign the existing UI is easy to prioritize below the new features being promised by sales; on the ambulance example, the length of time the red paint on the ambulance will last is not as important as building a car that can withstand an impact going through a red light with a patient in the back and getting hit by someone who cannot hear the siren.

This gives your quality folks a place to SHINE. It gives them focus to make things great, and to spec out the time for that greatness. It then gives you more to bargain with and discuss when you get to the less prioritized features; they may still want everything perfect, but you have given them an opportunity to get other things perfect. Now you can focus them on getting things DONE.

Even then, folks who like to do things perfectly are usually unhappy (at least a little), and that's really what you love about them: their devotion to the work. In this case, you write bugs for the imperfect parts. You prioritize the bugs and fix the highest impact/most important ones, and then set the others aside for the next version of the product. They feel heard. Their ideas aren't lost. They can let go of perfect, and get to good.

Sometimes, as the manager, its you who needs to confront your assertions around perfect and done. It can be overwhelming to feel that you have X amount of time to deliver Y amount of quality. 99% of the time, the way that schedules are created, that business folks come up with new ideas, that customers request things, that bugs are found, things are set up to prevent both quality and timeliness. Its not like a group of people organize it that way just to see what you'll do (though it can often feel like that), it's just how things fall out in business when multiple parties at multiple levels provide input and priorities.

To combat it, do the same as you would for your team: include quality in the feature creation and scoping process, prioritize the highest features that deserve the most quality, "let go" of your need for perfection in the lesser prioritized items, and keep track of defects/issues/bugs so that the imperfections can be fixed at another time, but you can release the product now.

Good enough sounds terrible to say: "This product is good enough to go out." But the truth of the matter is that if you built a quality product, it really is good enough to go out. And the next version will be even better, because of you and your team's committment to quality. Don't let perfect be the enemy of done.