This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
Friday, September 17, 2004
Multi-Project Management and Organizational Effectiveness VI -- Protective Capacity -- The current constraining resource in a multi-project system could be located anywhere. By definition, other resources are non-constraints and have more capacity than would be technically needed to support the possible throughput of the system. But to start cutting and slashing this extra capacity indiscriminately would be a mistake. At some point, that would merely shift the constraint from where it is to another, potentially unpredictable part of the system at the same or lower level of capacity, or worse, set up a situation with hard-to-manage interactive constraints.
Instead, the means of managing the constraint for growth of throughput starts with stabilizing the system so that the extra capacity upstream of the constraint assures that the constraint is not starved for work. The only resource that should be kept near high utilization (note “near high” is not “at full”) is the constraint, since the output of the system is tied directly to its output. Project launches that are synchronized with the ability of the constraint to deal with them will, if sufficient protective capacity is available up stream, flow smoothly to the closely managed possible bottleneck. Similarly, once through the identified constraint, no downstream resource should be so tight that it delays the conversion of constraint output to a complete accrual of project benefit. Again that implies a necessary level of protective capacity downstream as well.
Once stabilized and ridden of the effects of overload and multi-tasking, the true capacity of the system and of its components is far more easily identified. At this point, the organization can take rational steps to grow its capacity and capabilities by systematic constraint management.
Implications for project portfolio management. Once the constraint of the system is understood, it will have implications beyond just project delivery performance. It will also provide useful input to the project portfolio process. If the organization is limited to taking on projects at the rate that they can pass through the bottleneck, then those projects that have a higher relative benefit value per time required of the bottleneck will be more valuable to the organization than those that require more bottleneck time, all else being equal.
One project may seem to have small face value, but if barely involving the constraint, it will be able to deliver that value while barely displacing some other project and its benefit. It’s almost a “free” project, taking advantage of the slack in the non-constraint resources. On the other hand, if a project that looks very valuable when complete, but requires so much constraint time that many other projects are denied or delayed, it becomes a serious strategic decision to move forward with it. If, by the nature of a bottleneck or constraint, taking on one project forces us to forego or delay another, then this metric of benefit per constraint usage becomes an important factor in the decision to launch.
posted by Frank - Permanent Link -
|