I have been using the phrase “Perfect is the enemy of good enough” very often relating to current projects. I cannot claim to be the originator of the phrase – it seems to have been in use in various forms for many years.
For any task or activity, a key requirement to understand relates to when it should be completed and how ‘robust’ that solution should be. Delaying ‘completion’ in order to achieve ‘perfection’ may mean that you are too late to get the desired benefits or that the results are too difficult for end users to understand. So what can be done?
For example, should a new business process be defined to cover common situations only, or to ensure that every conceivable situation is detailed?
The simpler business process will be far easier to visualise and understand, but will need clear instructions so that staff know what to do when a situation arises that is not covered in the core process.
A fully defined, comprehensive business process has the advantage that all (or at least, most) conceivable situations and appropriate actions are recorded. The complexity of the resulting process documentation may make it far harder to train staff and for users to understand the overall process.
Pareto principle
The pareto principle or 80/20 rule is very applicable here:
- The simpler solution may take 20% of the time/ effort to complete and cover about 80% of situations
- The fully defined solution is likely to take 80% of the time to cover the remaining 20% of situations. Depending on the scenario, it may be impossible to fully define all situations but you may expend significant time and effort in the process.
Seeking perfection
By nature, some people tend to be perfectionists. They will tend to always be looking for that perfect 100% solution, even if project deadlines are missed to achieve it.
Other people may be more pragmatic and seek ‘good enough’. They recognise they have not defined everything, but have created an outcome that supports wider objectives and within required timescales. Therefore, you may need to consider which staff you assign such tasks to.
Understanding the consequence of ‘getting it wrong’ and the criticality of a situation is essential. Designing safety critical systems for a nuclear power station will need almost all situations to be clearly defined. Defining the process to follow when handling a customer query has less severe consequences incorrect approaches are taken. It is more important to ensure the process handles required volumes of transactions to a good enough level of quality.
You clearly need to make sure that good enough is good enough! A desire for a quick fix may rapidly create problems if it is not good enough. So a desire to act quickly and not spend ages seeking some mythical perfect solution should not over-ride the need for a solution to be effective in supporting most situations correctly.
Don’t forget, developing a solution to a problem/ defining a business process etc. is not a ‘one-hit’ activity. There will be (and should be) opportunities to refine the approach in future. Therefore, treat any proposed solution as a platform for improvement. Plan review activities at key dates/ timescales and then stick to them. This will be a defence against those seeking perfection who may argue that “you will be permanently locking the organisation into a sub-standard solution”.
Considerations
Key questions to consider:
- What is the importance/ criticality of the problem?
- What are the consequences if errors arise?
- What is the minimum set of requirements that must be fulfilled by the solution?
- How complex is the problem? Is it likely that ‘all’ scenarios can be understood and defined?
- When must the solution be completed?
- When should the solution be reviewed and refined?
- Who will be using the solution? What level of understanding are they likely to have?
Inventor of RADAR Robert Watson-Watt suggested a “cult of the imperfect”, which he stated as:
“Give them the third best to go on with; the second best comes too late, the best never comes”.
L Brown (1999), Technical and Military Imperatives: A Radar History of World War 2, p. 64, ISBN 9781420050660
Are you spending too long trying to create the perfect solution, or should you be implementing a good enough solution and then refining it?