A Brief Introduction to Buffer Management
Projects are often comprised of a sequence of dependent tasks that are new to the
Execution Team.
Being new tasks and often totally new to the team, teams can expect significant
uncertainly and even discovery while some tasks are being implemented. This means
that estimating the duration times of Projects Tasks is not easy, with any degree of
accuracy. Project task duration times are simply a guess
at best.
Project Teams are expected to bring Projects in on their committed Due Dates, within
the original Budget and without compromise to Specification. This is exactly where
Buffer Management provides an early warning system, well in advance, of over or under
Task Time estimates in real time, while the project is being executed.
Buffers absorb the “shock” of any Task slippage and provide a visible gauge to the
depth and severity of the task slippage. Gaining time during the execution of any Task
appears as a gain on the Buffer “gauge”. Any slippage into the RED zone of a Buffer
requires early and active intervention – known as “Active Buffer Management”.
A Black line in the center of the Buffer indicates Buffer penetration into the Green,
Yellow or Red zones of the Buffer.
Under active Buffer Management, the highly visible Buffer
Mechanism is elegantly simple and an effective means of keeping a
project on track.
Understanding where time is lost during Project execution.
Most of the time wasted during Task execution is lost through
disruption.
This includes, but is not limited to:
⦁ Task priority changes (stop /start effect).
⦁ Multi-Tasking (constant reassigning of Resources)
⦁ Meetings (re-planning, competing alternatives).
⦁ Intervention points of recovery are unclear.
Summary: Effective Touch Time is fragmented by periods of
disruption.
A Brief Introduction to Buffer Management (continued)
A suitable amount of safety time is removed from each task in the project, this is
accumulated into a “shock absorber” and this aggregated safety Time is reinserted
automatically by Exepron® at critical points back into the project in the form of formal
Buffers. Think of them as “Time Buffers”.
Exepron® automatically inserts a single main Project Buffer at the end of the longest chain of Resource and Task dependent events. Several Feeding Buffers from strings of dependent Feeding Tasks are automatically inserted by Exepron’s intelligence at points of integration with the Critical Chain. Both Buffer types have Green, Yellow, and Red zones – overlayed by a black penetration needle highlighting the degree of lost time caused by accumulated delays.
The color code system indicated possible management intervention to address Tasks consuming more time than originally estimated. Proactive intervention is required when a Buffer penetrates the Red zone. RED means take appropriate corrective actions on the Task causing the RED condition.
See the section on Individual Project Dashboard and Early Warning Charts for more
detail.
Exepron’s default portion of extracted “safety time” is automatically inserted in the Project and Feeding Buffers is 50%.
Why? 50% of a Tasks allotted time is typically “safety” time. Most non-productive
Project Task time is taken up by disruptions and not actual “hands on” (touch) time, working on the Task itself.
Disruptions might include resources attending meetings, resources removed to answer customer questions, work on urgent requests for quotation or any other activity not directly contributing to the Task scheduled on the Project, or other daily activities.
Most resources, if left alone to focus and actively work only on the assigned task, will in many instances, complete that Task in half of the allocated Task Time.
Exepron® utilizes this inevitable disruption time and accumulates it as a Buffer automatically reinserted at critical points in the Project Network. This disruption time is now turned into an effective Management tool in the form of dynamic real–time Buffers.
Therefore only schedule the known “Touch Time” on a Task and Exepron® will automatically insert Time Buffers to protect against the unknown variability
encountered during execution.
