Although I am not the one that came up with this aphorism, I surely feel like I am a heavy user of it.
Whether it is this version or one of its variations, like "Perfect is the enemy of Good Enough" or "Perfect is the enemy of Done", I constantly come across the tension that these sentences so nicely expresses.
Where do I see it mostly happen? When accurate and measurable output is needed, such as quantifiable KPIs, sales projections, effort estimations, bugs root cause analysis, and alike.
A classic example to such tension can be when the management level wants quick and clear bottom lines on a project's effort estimation while the subject-matter-experts (SMEs) are living in the details and keep considering more and more data, input and other considerations. Nothing is provided quickly and the management level doesn't have anything to work with.
One side expects something good enough, while the other side aims for perfect.
This is like asking someone to describe what they see through an out-of-focus lens. The person behind the lens keeps focusing the blurry picture more and more but says nothing to describe it until the image is perfectly in focus and they are able to describe it to the smallest detail. In the meanwhile, the other person who is not looking through the lens, is waiting not knowing if the picture is of a dog, a person or the Eiffel Tower.
In many cases, these two world collide not because of different perspectives but because of miscommunication more than anything else. Everyone understand that the task is hard, (or that the image is blurry), and it is simply a matter of expectations to provide continues input as we are trying to get it more and accurate and clearer.
How would I avoid getting into this situation? Each side should know and communicate the following:
The SME:
Know that probably no one else can do the work of "guesstimation" better than you. No one's goal here is to challenge the work you do or yourself. If questions are asked it is in order to better understand.
Also know, that giving nothing at all has its implications. You have to provide initial output and quickly.
Output can be provided in an agile process and anything can be improved or revised. Communicate that you are providing initial, crude, results while continuing to work in an agile manner on refining them.
For the requester:
Communicate clearly that you understand the difficulties, the complexity of the task, and that you are aware that "the devil is in the details".
Communicate clearly that this can be an agile process. You need to see a quick output that is good enough and later on it can be improved or revised.
As you can see, being empathetic to each side of the the transaction while communicating clearly expectations, is the key.
