Critical Chain Project Management, Second Edition

The most important decision you make when you go about improving anything is determining what to change. Everything else follows from that decision. If you decide to change something that is not the constraint of the system, you most likely will not affect the system. You could make it worse by making a new constraint more restrictive than the old constraint. But you can never make the system better by improving a nonconstraint.
Throughout my career I have witnessed dozens of organizational structure changes, all attempting to improve the performance of the organization. None of them ever did. I have also witnessed several attempts to improve project management through improved software, more training, or more procedures that failed to achieve significant performance improvement. In each case, the physical change was accomplished boxes added onto the organization chart, people trained, software purchased (and, in some cases, used), books of procedures written but project performance remained about the same. Of course, managers changed as well. TOC taught me that this means one thing: the solution did not exploit the system constraint. The one experience I had before learning of TOC that did result in significant change did, in retrospect, address the constraint. It included many features of CCPM. At the time, the leaders of the change did not understand the theory under- lying CCPM. If they had, the change would have been even more successful.
Now, having seen CCPM deliver in multiple organizations, I know why.