Introducing a new policy can move the system capacity constrained resource (CCR) and create problems throughout an organization. These problems are foreseeable when a manager understands the effect of policies on the CCR. Policies are a type of constraint. The introduction of a new policy might make it the overall system constraint.

For example, let us imagine that the chief architect is becoming uncomfortable with the quality of emerging code and feels that the original architectural intent is not being achieved. With a simple announcement, he introduces a new policy that all designs must be reviewed by him before coding commences. In an instant, the chief architect is now the overall system constraint. A one-man bottleneck. It doesn't matter where the constraint was before - UI design, Testing, Usability, Requirements or Coding - the new policy moved the constraint.

What are the effects of moving the constraint? People downstream in the process find themselves idle for periods. Work upstream begins to stock pile. People producing designs can't get to "complete" without a long wait. The project schedule can be abandoned. It too needs to be re-written. The PMO (if there is one) needs to re-write the master schedule. Customers get frustrated and their expectations need to be managed.

When the CCR moves, everything changes. New policies can move the CCR. Changes in CCR should be planned and the overall system-wide effect understood in advance, otherwise chaos ensues, leading to accusations, blame and loss of trust. The introduction of new policies cannot be made locally. New policies should be agreed system-wide after being fully understood by the value-chain of line managers affected.