Like the Golden Ratio, or fractal geometry, once you understand it you will see it is again and again as you explore our universe.
It is usually described as a feature of economics, where it is sometimes called the Pareto Principle. In the context of a todo list, for instance, it is likely that completing just 20%, or for instance two items on a list of ten things to do, will provide 80% of the value of doing the whole list.
In application, you can quickly prioritize that list of ten things to do and pick out two that are most vital, and doing those first. The rest of the items are trivial in comparison. Even if you do those you still have done 80% of the valuable work.
If we don’t prioritize the vital, we run the risk of spending our time and energy on the trivial, which often appear to be easier or require less time and energy, and don’t get the most value out of our time and energy.
“Perfect is the enemy of good”. 80% complete I sn’t perfect, but it is good.
With this in mind, I often cap my two do lists at 10-12 items, then do the most important two or three first. Then I actually scrap the whole list, assess where priorities stand now that many important things have changed, and make myself a new list of 10-12 things and repeat this until my resources are exhausted.
People have built bridges for 1000s of years and in that time, the physics have been continuous and the technology has stayed relatively stable. Building a bridge today takes more time to plan than it does to actually build. Every single factor needs to be known in advance or the bridge may fail. When the bridge is complete it may stand for 1000s of years with very little maintenance. Usually, if one of those known factors changes post-planning during the construction phase, the bridge is not completed, and the incomplete bridge will not be finished until an entirely new planning effort is completed.
From twenty years of software engineering I have worked with different project management paradigms. The ones that work best in real world applications IME are the agile cohort. A feature of these is that you never finish a comprehensive project plan, but you keep revising the plan as you go. Thus you avoid the problem with planning a bridge, which is important in software because all of those factors engineers are supposed to know in advance, well, TBH they don’t. And that doesn’t matter to the market, who if anything is going to move the deadline closer to now, so engineers can’t delay beginning coding because they aren’t done planning yet. You plan the most important stuff and start it, and then in two weeks you do that again, and again, until you run out of resources and then you ship it. The drawback to this is the software will have bugs, which you can’t have in a bridge, but can be patched in software.
80/20 rule
It doesn’t work in every area of life, but it works in the vital 20%
edit: tossed some word salad