What is a shared project buffer?
To accommodate for the uncertainty in the work estimates and the resource’s availability to do the work, the artificial, invisible task buffers are replaced with a shared buffer at the end. The published completion date (promise date) is at the end of the shared team buffer.
Estimating a shared project buffer
Instead of artificially buffering all our tasks, we estimate durations using a 50/50 guideline - 50% of the time the task will be completed on or before the estimated date and 50% of the time the task will take longer. These are sometimes referred to as focused durations.
We then focus (single-task) on the task until it is complete. We’ll do the same amount of work, have some margin, work under less stress and we’ll likely complete the project sooner.
What's the benefit of using a shared project buffer?
The length or size of the shared team buffer is smaller than the sum of the task buffers, because we benefit from variability pooling, similar to statistical tolerance analysis. If you’d like to learn more about how to size buffers, click here.
Interested in understanding more Lean-Agile Principles? Check out our free Lean-Agile training on Playbook Academy such as Rolling-Wave Planning, Applying Agile to Hardware and Critical Chain Project Management.
Why don't individual task buffers work?
Let's look at the rationale behind why individual task buffers don't work.
Student syndrome
To explain individual task buffers, we’ll start with a discussion about Student Syndrome.
Student Syndrome refers to people’s tendency to procrastinate - only starting to focus one’s effort on an assignment at the last possible moment before its due date.
What happens is that we multitask, unknowingly causing more delay, until a task’s due date approaches, which invokes a sense of urgency followed by a more concentrated effort to complete the task.
Sometimes the task is completed by its due date and sometimes it takes longer.
Student Syndrome consumes potential safety margins, puts people under stress and pressure, and often requires heroics to get the task done. The impacts of Student Syndrome is that each and every task takes longer, causing the project to take longer, and the resource may cut corners because they’re late.
Parkinson's Law
But that’s not all. There’s another phenomena affecting how long it takes us to get the work done – Parkinson’s Law. Parkinson’s Law is the adage that the “work expands to fill the time allotted.”
For example, the larger the suitcase we bring on a trip, the more stuff we pack, right?
So, the more time we have to work on a task, the longer we work on it, forever trying to improve or perfect it.
“Perfect is the enemy of good enough.”
-Voltaire
The prevailing culture that feeds into Student Syndrome is one in which task duration estimates are treated as commitments and being late is unacceptable, therefore it’s better to under-commit and over-deliver.
For example, if Mary, Bob and John think their tasks will take them 5 days each to complete, they might commit to have each complete in 10 days, for a total of 30 days. This is a safe bet. Mary and Bob have high confidence they’ll complete the tasks no later than the commit date. Estimates like these are referred to as 90/10 estimates, 90% confidence the task will be done by the estimated completion date and a 10% chance it won’t be.
Since we’ve been measured on our ability to hit due dates and being late is unacceptable, we’ve been conditioned to pad our estimates (90/10 estimates). This padding is what we refer to as individual task buffers.
In fact, because of Student Syndrome and Parkinson’s Law, the individual task buffers typically get used and often the time to complete the task extends beyond the buffer.
The bottom line impact of Student Syndrome and Parkinson’s Law is every task takes longer causing projects to take longer.
"Insanity == Doing the same thing over and over again expecting different results."
- Albert Einstein
Nothing will change unless we do something differently. If we could adopt a new way of executing our work, we could get projects done sooner.
Using shared project buffers just makes sense
Instead of artificially buffering all our tasks, we estimate durations using a 50/50 guideline - 50% of the time the task will be completed on or before the estimated date and 50% of the time the task will take longer. These are sometimes referred to as focused durations.
We then focus (single-task) on the task until it is complete. We’ll do the same amount of work, have some margin, work under less stress and we’ll likely complete the project sooner.
For example, if Mary, Bob and John think their tasks will take them 5 days each to complete, then their 50/50 estimates for each task is 5 days.
To accommodate for the uncertainty in the work estimates and the resource’s availability to do the work, the artificial, invisible task buffers are replaced with a shared team buffer at the end. The published completion date (promise date) is at the end of the shared team buffer.
The length or size of the shared team buffer is smaller than the sum of the task buffers, because we benefit from variability pooling, similar to statistical tolerance analysis. If you’d like to learn more about how to size buffers, click here.
Because we’re single-tasking more and multitasking less, fewer tasks will go to full buffered length and some will get done early.
If we adopt this new way of executing our work, we will complete projects earlier and with greater confidence than the traditional individual task buffered approach.
Key Principle
Using visible, shared team buffers, instead of artificially inflating schedules by buffering every task, drives focus and encourages teamwork.
How do you monitor shared buffer consumption?
The shared team buffer is like a cake (yum, did someone say cake?!).
Those involved in earlier phases of the project aren’t allowed to eat all of the cake, only their portion. They have to leave some cake for the downstream activities, such as verification testing, manufacturing, etc.
Buffer Charts (fever charts) are used to track the performance of the project by tracking the amount of buffer consumed, visibly.
Typically buffer usage is charted weekly. If this week’s usage is in the green, the project is on track. If it’s in the yellow, the project is starting to use the buffer too fast and the team plans interventions. If it’s in the red, the team executes interventions. If you’d like to learn more about Buffer Charts for Power Users, click here.
In Playbook buffers are made visible using a task.
The amount of buffer used is seen by looking at how far the Project Complete milestone has moved across it. When the Project Complete milestone reaches the end of the buffer task, all of the buffer has been used.
You may be thinking, “What? If I remove my teams’ commitments to Due Dates – won’t the tasks take even longer?!”
There is a common concern among managers that removing commitments to due dates on tasks will cause engineers, for example, to keep working on their design much longer than they would with a due date. This concern is certainly valid, but there are good ways to prevent people from ‘over-polishing the BB’ without resorting to task commitments (and therefore individual task buffers). The answer is three-fold:
1. Visibility to the resource’s work
2. A little peer pressure (via shared team buffers and standup meeting).
3. A good Definition of Done for those tasks where the end is not already clear
We’ve discussed the virtues of visibility to the work in several posts in the series. It is a key ingredient in successfully accelerating projects. In the next post we will discuss standup meetings for fast feedback. Stay tuned…
-----
Ready to learn more? Find out the real cause of project delays. It's not what you think. Watch this 9-minute video to find out what it is.
Related articles
Lean project management
Lean project management methodology
Lean project management Kanban
Lean project management principles
Resource management
Pull vs. push
Task management
Shared project buffers
Decentralized planning
Daily stand-up meetings
Guide to Lean Project Management
