Comments on: The 90/10 rule for Projects? http://ericbrown.com/the-9010-rule-for-projects.htm?utm_source=rss&utm_medium=rss&utm_campaign=the-9010-rule-for-projects Technology, Strategy, People and Projects Sun, 12 Feb 2012 18:52:08 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Lockie Stewart http://ericbrown.com/the-9010-rule-for-projects.htm#comment-378 Lockie Stewart Thu, 03 Jul 2008 06:50:19 +0000 http://ericbrown.com/the-9010-rule-for-projects.htm#comment-378 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). 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).

]]> By: Eric Brown http://ericbrown.com/the-9010-rule-for-projects.htm#comment-377 Eric Brown Sat, 12 Jan 2008 02:00:27 +0000 http://ericbrown.com/the-9010-rule-for-projects.htm#comment-377 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 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

]]> By: Eric Brown http://ericbrown.com/the-9010-rule-for-projects.htm#comment-376 Eric Brown Sat, 12 Jan 2008 01:59:20 +0000 http://ericbrown.com/the-9010-rule-for-projects.htm#comment-376 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. 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.

]]> By: Steve Wiley http://ericbrown.com/the-9010-rule-for-projects.htm#comment-375 Steve Wiley Fri, 11 Jan 2008 15:10:12 +0000 http://ericbrown.com/the-9010-rule-for-projects.htm#comment-375 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. 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.

]]> By: Jim Stroup http://ericbrown.com/the-9010-rule-for-projects.htm#comment-374 Jim Stroup Fri, 11 Jan 2008 07:46:49 +0000 http://ericbrown.com/the-9010-rule-for-projects.htm#comment-374 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? 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?

]]>