It makes sense when applied correctly but in our company it's viewed as a 'golden rule' and it means whatever they want it to mean. They call it the "80/20 rule" and to our project/program managers it means they only have to do 80% of their job.
Basically the "20%" is always the part they don't want to do or they consider too hard. When applied this way it leads to half-assed solutions that leave out significant usecases, meaning the old solution will still need to be kept around. In the end this leads to a messy environment and significant technical debt.
The principle as I see it, is not meant as a cop-out at all. Rather it's a warning for project managers to budget and plan carefully because some features may be much heavier on resources than others. It's not an "oops we stumbled onto a hard problem, oh well, 20% so let's drop it". As the article states:
> 80% of your application (if you could get away with only doing this 80%) could be developed in 20% of the time and budget.
This check "if you could get away with..." is always automatically dropped in our company.
It makes sense as a principle but as a rule it leads to mediocrity and incompetence. I often wonder whether project managers are so consistently bad in other companies too :)
PS their latest excuse by the way is 'agile'. "We can worry about this problem later because we're agile". Not to mention that we don't actually use agile methodology at all. They just have us log our hours in Jira. Besides that our projects are simple waterfall projects. A tool does not a methodology make.