I'm with Michael on the power of status reports. There was one group I worked with that implemented a simplified version of Critical Chain in which the ground rules were laid out that as long as the project was "in the green" (zone of the project buffer), no project meetings had to be held. If the project slipped "into the yellow," an "all hands" meeting of resource managers was called to develop potential corrective actions.
Talk about incentives to keep a project moving! No one wanted to be the one to trigger the meeting, so the process became a self-governing mechanism. Extra effort was put in at the appropriate times.
Along with meaningful status reports that pointed directly to the effect on the organization's project promises, another piece of the puzzle was facilitated by the minimal information needed to update status in a Critical Chain environment. The fact that to maintain the buffer reports required only an easy, single number -- the estimated time to completion -- for active tasks, daily updates were painless, even in a non-web-assisted environment, which the better Critical Chain software tools support.
The third piece of the puzzle was good communnication of upcoming tasks. In a CC-based project, that is critical since task start and due dates will definitely differ from any original baselines. Again, along with buffer reporting, regular heads-ups of upcoming tasks will help to prepare resources to be on hand when needed for their tasks.
One more piece of the puzzle -- multi-project management. If you are trying to manage a single project in an environment that does not synchronize the efforts associated with other projects, you're task will be a hundredfold more difficult, as you do battle for shared resources with other project manager and owners.
If that's the environment, you can't expect consistent success with individual projects by making believe they're in a vacuum. You have to have a consistent approach to manage all projects in relationship to one another so that it is clear to everyone where the best use of the resource (for organizational goals) lies.
In my implementation workshops, we joke about how resources usually get allocated. . . Put the two project managers in a room and the one that comes out standing gets the resource. In the CC, world, we send them into the room with the relevant buffer reports, which will give clear direction how to best use the resource and allow that decision to be developed without physical violence.
Back to the original question.
Commitments have to be around playing by rules that are set up ahead of time. Rules about how much of a head's up is needed to reserve a resource (project status reporting), how a resource will act on the task once started (head down until done), how those rules might be bent if circumstances require (buffer management), and how the portfolio of projects are coordinated (synchronization).
Trying to put these into place mid-stream to protect a particular project may be difficult, but not impossible, especially if all the other projects in the organization are suffering from the same symptoms.
(And I would think some clear rules along these lines would be welcome by the resource owners as well, who probably feel like the rope in a game of tug-of-war between project managers.)
