Authors
Navigation
Archives
- April 2012
- January 2012
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- October 2010
- September 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- November 2009
- October 2009
- September 2009
- July 2009
Categories
Recent Comments
- John Carter on PIEMatrix: Projects as Processes, not Tasks
- Paul Dadurand on PIEMatrix: Projects as Processes, not Tasks
- John Carter on Getting More Done by Doing Less (11)
- Evi on Getting More Done by Doing Less (11)
- John Carter on Can You Open Source Your Strategy?
Recent Posts
Tweets from the trenches
Innovation versus execution - some useful thoughts, but you can't prove a case by a few poster child examples: http://t.co/Nb2DCgzW
5 days ago



Evi
Hi there,
What do those numbers (10, 15, 35, 25, 10) in the second graph denote? the number of employees that work on the amount of parallel projects corresponding to the left column (1 Project, 2 Projects …)?
In this example, do you mean the relationship between value added time versus number of parallel projects remains the same, i.e. it peaks at 65% when they work on 1-2 projects? I wonder how/what mechanism was used to derive this?
How does your model work for organizations of different sizes? what if for situations where some might work on more than 7 projects? How do you measure/benchmark as “value-added time” of an employee?
Thanks …
John Carter
Hi Evi,
Thanks for the comments. Yes, the numbers indicate the number of engineers working on a given range of projects at the same time (15 engineers working on two projects at the same time). I have found this to be true at Bose where I was Chief Engineer and for other consulting clients. If you want more detail, the mechanism used to derive this is explained in the literature (see “Revolutionizing Product Development” by Wheelwright), p. 90-91 and elsewhere in published papers. It was derived by studies of several organizations surveying engineers and team members doing typical new product development efforts of ~10-100 team members for projects lasting 9-18 months or so. Non valued added time was attending non project related meetings, coordination, tracking information, and administration.
Obviously, this model has its limits – for example if the development efforts are outsourced, and relatively trivial, then an engineer can work on more than 2 or 3 at a time. However, it should work with organizations with engineering teams from 10-10,000. The model breaks down with either very small organizations, or where project complexity is very low.
Regardless, this kind of analysis can be very helpful to understand – if overload is a problem – how to characterize efficiency and provide benchmarks if your organization has similar scope and complexity of development.
I hope this helps,
John