There’s often the mindset on projects of “all or nothing”: customers (internal and external) want to see a completed solution that fully fits their vision when, in fact, that may not be what they need in the end. This leads to development teams trying their best to get everything done in one go when in fact it might be more efficient to do less.
Here’s an example to illustrate: I was on a project where we were automating the creation of material master data between one system and another. The full set of (pretty complex) requirements were provided in May.
We kept asking the development team when we would have something ready.
“Soon, soon,” they would tell us.
This went on until November. We didn’t see anything until December.
In the end, the IT team had obsessed on having everything completed perfectly, and had spent the entire time implementing all of the leading best practices, flawless architecture integrity, and all the theoretical bells and whistles…but had not managed to automate the bare-bones creation of one material master data record.
It took two extra months of intense work to get a first material record published.
Better than Perfect
I’ve learned that on projects, 80% is the sweet spot. It harkens back to the Pareto Principle: 20% of causes create 80% of effects.
Rather than putting in 100% effort to create a solution that, in the end, isn’t really 100% of what was ultimately required, putting in less effort (20%) to get the majority of the results (80%) may be more effective.
No one truly knows what perfect is. What seems perfect during planning will inevitably shift as reality sets in. To paraphrase 19th-century Prussian military commander Helmut van Moltke, “No design survives contact with the reality of business and testing!“
It could take six months to deliver 100%…but a month to deliver 80%, and that could be enough to build the next phase. This less-than-perfect deliverable could be enough to do twice as much testing and could be the difference between having a steady pace and a fire drill. And if you do the math, doing five rounds of 20% effort to get five outputs of 80% gives 5x efficiency over grinding to a single 100% outcome. And that could be the difference between success and failure!
The Benefits of Good Enough
Getting just 80% allows you to verify and adjust what remains, and then to rinse and repeat much sooner. This is the heart of Agile after all. The business team may see that the solution doesn’t look quite as they expected it, and they may then tweak requirements. Better to find that out now than waiting for 100% to do so. As the saying goes, fail fast, get smarter faster.
Delivering “good enough” fundamentally builds more confidence because it provides positive confirmation of what works and what the end product looks like. Some IT teams sometimes go into a black hole to get work done and emerge months later with a not-quite-right solution. Building 80% rapidly lets the business team see where the work is, and the two teams can collaborate for future planning.
Having a short feedback loop can ensure the project stays on track and on time. This can keep IT on a short leash, ensuring that the project veers away from having all the fancy bells and whistles and stays true to overall strategy and objectives.
Perfection sounds great on paper, but reality has proven on project after project that imperfection and 80% may, in the long run, be exactly what your project needs.
Share: