This week in pm-clinic: the myths of buffer
This week in the pm-clinic discussion forum:
I’m a lead programmer on a web 2.0’ish startup. Our team of 7 released an alpha version last week and we’re planning the final release, and need to make partner date commitments for launch.
Our biggest debate is buffer. All of our experienced programmers have pet philsoophies about buffer and I’m looking for someone to dispell the myths and give real advice on: Should buffer be used at all? When? why? Where do you put it in the schedule? Do you tell the team? And what are common stupid things arrogant leads do with buffer that shoot themselves in the foot and how can we avoid?
thanks,
– Wannabe buffermaster (WB)
My strategy is to use buffer when:
– the items counted by buffer are not super critical to the project
– the cost of tracking is higher than the value gained from tracking
– anyone building the schedule MUST agree what is and is not buffer, otherwise we’re not comparing apples to apples
– there is some rational story for why the buffer contribution is what it is (e.g. we’re adding 5% buffer because there are 3 weeks of vacation and it ammortizes to 5%)
Types of things I put in buffer:
– vacation time ammortized across the project
– training
– writing/reading e-mail
– legacy product/service support
When talking about buffers a thing I’d start from is how good are my developers in scheduling. Majority of developers I met make scheduling rather poorly – they’re often too optimistic, they don’t remember they aren’t productive for whole work-day, they forget about meetings, e-mails, phones etc.
The key thing for “buffermaster” is to know who underestimates her work and how much (more or less) should be added to her schedule. It impacts whole project schedule – when you include all interdependencies a day of delay in single task can result in a week of delay in the whole project.
Something that helps much is experience – I’m quite often in a situation when I have to set the deadline on the fly (sometimes not even knowing all the variables). Then I follow rule of the thumb – I estimate optimistic (usually set by developers) and pesimistc (with rather safe buffers) and set the second as the official one. Quite often I hit the jackpot.
I agree with you Pawel that most developers are poor on estimates. As well as being a difficult thing to do, there is also pressure that will have an impact on these estimates.
Some developers may respond more to what they know management want to hear and therefore will be more optimistic. Whilst others will want to protect themselves and team members and so add ‘buffer’ even before you do.
Pawel – when you have your optimistic and pessimistic schedule and you use the pessimistic one as the official one. What do you do with the optimistic schedule? Do you refer back to it later or is it just part of the process to validate the official schedule?
Goldratt’s Theory of Constraints offers the Critical Chain approach for project management that incorporates a sound approach to buffer management. Basically, you estimate using a Pert approach (optimistic, pessimistic and most likely). Manage and plan to the optimistic and take the delta between the optimistic and most likely and apply that as the buffer at the end of the project.
Critical Chain works because it addresses the following:
– Work expands to fill the time alloted;
– Delays accumulate, advances don’t (if you put buffer on tasks throughout your project you will never see the project end date move up even if you don’t need the buffer);
– The Student Syndrome (waiting to the last minute to complete an assignment)
– There are some tasks in your project that will be completed within the optimistic estimate (more than you would think) and with Critical Chain you will realize the advance of the schedule.
Note that with Critical Chain it is not expected all tasks have to be completed within the optimistic estimate. You have buffer at the end of the project that will accomodate those tasks that meet your most likely estimate and even those that go towards your pessimistic estimate. Critical Chain teaches how to manage that buffer at the end of the project and how to recognize if / when you are exceeding the buffer and how to deal with that.
This is an over simplification to the process so please take the time to read Goldratt’s Critical Chain or Larry Leach’s Critical Chain Project Management before you draw conclusions.
Critical Chain ++1
See also: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results by David J. Anderson