The 80/20 principle has been round for many many years and is in use daily across business and just about every genre. It's quite simple and straightforward it basically means that for 20% of the effort you can actually get 80% of the results you want.
The Pareto principle[2] as it's known has a very valid set of findings and it is a good "Rule of thumb", the rule of thumb, is a whole different thing as that's when you look at Daniel Kanemann and and the whole thing around using intuition [1].
My take on it is a slight addition to the 80/20 principle I like to think of 80/20/80 rule, I call the "All-mo-done", (almost done). If you think about it, it's true most of us especially in business and at work want to get things done now. We all love progress. We all I hope strive to add value with intentionality.
Something that occurred to me the other day while I was doing some chores basically tidying up, is that quite often, will outsource things to a service provider or consultant or associates or subcontract to get someone else to do it.
I always try to get the worst job of the day done first, you know clean the cat litter tray type thing. Some jobs are too over whelming so are best tackles in a couple of goes, hence the 80/20/80..... Have you ever considered that you could do 80% of the work for 20% of the effort involved and get all the glory for what we call it and show the minimum viable product MVP??
What I'm trying to say to you is quite often we look at job and we just scope it all out (109%) and get someone else to do it for us because we're too busy it's not but she's her time whatever. Doing that means the outsourced resource gets the benefit of the 80% "Quick wins" for 29% of the effort!
When you apply Dave Allen's principles of Getting Things Done (GTD) [3], sometimes your better off doing the job, than specking it out for someone else! As we say in the IT security industry the "JFDI" approach you can look that one up later [6]!! You can actually achieve an awful lot by doing the 80% in 20% of the time, yourself this does two things;
One because there has been demonstrable progress and achievement, what a waste of your effort scoping it all to it have a commissioned. The work your boss or whoever your doing it for, realises you've actually my quite a lot, with tangible results.
What you then do is scope out the remaining 20% of the job which you know it's gonna take 80% of the effort and then you've got you've already delivered and demonstrated the low hanging fruit, that phrase im not a fan of, but does apply and it does make sense. The fact that you've got the MVP [5] ready to go before you've even commissioned the work to finish it off!
Sometimes you might actually find that when you get round scope in the last bit it's actually not worth the amount of effort and money involved in doing it but you can demonstrate that because you've already shown by delivering 80% of the results very quickly, the last 20% if it's required it's gonna probably cost 80% of the funding to do the job hence my 80 2080. You absolutely know the external resource will be earning their money!
Because that last 20% could well be 80% the effort and 80% of the cost to finish the project.You might want to think carefully about your "Definition of done" [4] and about rescoping. Another thing to consider is that why you're going through doing 80% of it very quickly and looking at it your understanding very intimately all of the last bits that remain to be done, this may mean rescoping a project it may mean realigning your expectations and it could even mean instead of investing that money in doing that final piece if you can make do with a bit of a reshaped phase 1, you have a proof of concept and do the last 20% later if it's still required.
In summary it's just a different way of thinking 80 20/80 get the 80% done very quickly because often you can't even scope out the last 20% and the finishing until you understand the job intimately you might as well do the big part yourself and deliver them very quickly and then you can really work out if the requirements are changed what the functional and non-functional requirements are for the last bit. Then decide if the business case to do it stacks up in the first place.
References:
