90% of the work is completed in 10% of the time….the remaining 10% of the effort is completed in 90% of the scheduled time. I’ve heard of the 80/20 rule…but the 90/10 rule is a new one.
I had one of my clients explain how the 90/10 rule is killing his projects…and I started thinking about this and started noticing it in the project I’m working on too.
That last ‘little bit of stuff’ seems to take forever to get done…..or maybe I’m just not that good at managing projects 🙂
[tags] project management [/tags]
5 responses to “The 90/10 rule for Projects?”
HI Eric,
I’ve seen that sort of percentage play out in certain types of negotiations, particularly conflict resolution. The 90% in 10% of the time doesn’t mean you were productive and the reverse that you weren’t. In the first case it means you were attaining agreement on issues that weren’t particularly controversial, and in the second that you were confronting the core, divisive issues about which people were digging in their heels.
Some negotiators – you hear this a lot in politics – like to do the 90% in 10% stuff first, imagining that it will produce a kind of momentum or atmosphere of goodwill making the last 10% easier, but my experience is that it still usually takes the remaining 90% of the time!
The application of this to program management is interesting. Are we talking about things that involve collaboration between units that are in different command chains?
Though maybe not as insightful, most problems solved (at least in the IT world) require a lot of time focusing on the “exceptions”. It’s usually pretty easy to solve a basic business need; it’s the “special considerations” that end up requiring (in many cases) more time to solve than the original basic problem.
Hi Jim,
Thanks for the comment.
I’ve seen this pop up in many different situations. Same groups, Separate groups, Vendor/Client, etc….I think it’s just very noticeable in the IT space.
Good points Steve……the 10% that I’m dealing with now in my current project has to do with ‘what if…” so I think you are right on the money
I think Steve is on the money, perhaps in part because putting analysis of the exceptions off until the core development is complete is an logical approach. I’m sure there is some process parallelism that can be leveraged to allow the hard yards to be attempted earlier in projects e.g. defining use cases/problem statements up front.
I’ve been challenged by my colleagues about the apparent disparity between citing both pareto and having high expectations. Recently it has occurred to me that by using two different strategies the theoretical yield rises to 96% with (again theoretically) 40% of the effort. My maths says 80% by the first 20% effort + 16% (80% of the remaining 20% by the second). I call this “pareto squared” . It rings true on three levels, first on the outcome itself , secondly as a higher return on investments, and finally that a 4% variance is more “socially acceptable”.
I wonder what portion of the 60% effort remaining is converted to wastage (especially in the form of time).