Theory of Constraints Handbook - James Cox Iii [641]
Before we discuss an example, we should be clear that we are interested in providing senior management with information that is useful for managing the whole organization. Within each separately measured unit of the organization, we expect managers to use TOC solutions (primarily DBR and CCPM) to manage their resources to meet their commitments. We are proposing here that TDD only be assigned at the point that either a production flow or project moves from one separately measured unit of the organization to another, that is, at the handoffs between separately measured units. We are using TDD to measure unit performance, not individual task performance within units.
It is also important to state that we are not suggesting that a milestone be established for every activity in a project. We are trying to provide senior management with information about separately measured units in complex organizations. A major problem in organizations that have significant project work is understanding the relationship between capacity and demand. In units that have both production and project work, most resources will generally work on one or the other. Occasionally a resource will be required to work on both production flows within the unit and project activities for other parts of the organization. For example, a test engineer may have day-to-day quality control responsibilities for a unit’s production and be required to regularly complete activities that are part of projects managed by other units of the organization. If the test engineering resource is a non-constraint, BM within the unit will ensure that both process flows and project activities are completed as required. If the test engineering resource is a constraint, use of DBR within the unit should prevent commitments either to an external customer or to another organizational unit that cannot be met. However, unit managers frequently have difficulty assessing whether they have resource constraints, and consequently, frequently make commitments that cannot be met. This is particularly a problem when project activities are a source of demand. In these situations, TDD will provide useful information to senior management as to where attention should be directed.
Using TDD to assign lateness to different departments and independent business units is similar to the TOC Replenishment solution for Supply Chains. It is not the same as normal CCPM. In CCPM, the project manager uses BM to take care of task variations. The project manager can allocate resources as needed to deal with buffer penetrations. However, in complex organizations, the resources are not generally available for reallocation. In complex organizations, the workflow is secured by promises that are critical to synchronization.
Most complex organizations make extensive use of milestones. Milestones are not so much a measure of performance as they are markers to indicate a project or process has progressed to a certain point. Milestones are not very good management tools because there are too few of them and they are too far apart. In addition, milestones are lagging indicators: They do not tell you what is coming in time to make corrections. They only tell you when it is too late to do anything about it. A missed milestone usually means a serious problem has occurred. Missing a milestone puts tremendous peer pressure (if not management penalty) on the errant party. To avoid this peer pressure, groups will often inflate their delivery times and create all the problems discussed in Chapters 3, 4, and 5 on CCPM.
In contrast to milestones, TDD is a forward-looking indicator of what is going on in the organization. Units will begin incurring TDD before commitments to customers are missed because production flows and project activities that result in TDD are still buffered by shipping and project buffers. In addition, TDD is reported often. The periodic TDD by unit shows which units are having the hardest time