Realization's mantra

Realization clearly encourage presenters at the Project Flow 2010 conference to use a similar template for their case study presentations.  This goes something like: Situation before implementation, What was done, Results, and Challenges / Next Steps / Lessons.  The format may get old, but the stories are usually pretty interesting.

In addition, Realization repeats their mantra throughout the conference and in many of the customer presentations.  The mantra elements:

1. Pipelining.  Reduce work-in-process (WIP).
2. Buffering.  Remove local metrics, and insert buffers.
3. Buffer management.  Drive execution priorities based on relative buffer consumption. 
4. [And sustainment by driving continuous improvement.]

These apply to project management, whether or not software is also involved.  One of the presentations talked about implementing these rules as their first steps - they haven't even begun to implement the software solution for project management.  These rules can also apply to shop-floor environments where the implementation is drum-buffer-rope, instead of CCPM.  The rules are essentially the same.

If you are familiar with Theory of Constraints, these rules probably sound familiar.  But if you aren't, what do these mean?

1. Pipelining is all about the realization that when there is too much work in the system, priorities get muddled and everything takes longer.  Reducing the WIP - actually removing work from the system - helps the system by reducing the priority conflicts.  Ongoing pipelining ensures that the WIP stays at appropriate levels.  How do you know what level is correct?  Monitor project buffers and cycle times.
2. Buffering.  You know that Murphy will strike, you just don't know when.  Use buffers to protect the project from variation.  Buffers belong to the project, rather than to individuals or groups.  Local measures are count-productive to driving project completion.  Make it known in the organization that the local measures don't apply any more.
3. Buffer management.  During execution, task-level priorities are defined by how much potential damage the related sequence of tasks is causing on the overall project.  Potential damage is measured by buffer consumption, relative to project completion.  People must work and drive those tasks that are causing the most buffer penetration.  This also helps set priority around stuck tasks too: a stuck red task is a lot more important than one that is green.
4. This one isn't stated explicitly, but once the system has changed to the new rules, you need to keep moving.  Monitor the system; Find ways to get even better; ...