Buffer, downtime, and productivity

Buffer, downtime, and productivity | Microsoft Share Point

Buffer, downtime, and productivity | Microsoft Share Point — Fri, 29 May 2009 20:35:54 GMT

PingBack from http://microsoft-sharepoint.simplynetdev.com/buffer-downtime-and-productivity/

re: Buffer, downtime, and productivity

jack dahlgren — Sat, 30 May 2009 06:11:01 GMT

There are a number of different methods to manage "buffer" or contingency. Sometimes management owns the contingency and doles it out. Other approaches like CCPM include buffer for the critical chain and also insert buffers for feeding chains (chains subordinate to the main chain) and then produce indicators based on buffer consumption.

There are good reasons to include it. Whether you hide it or make it explicit boils down to culture of your team/organization, but I think there is almost always some there.

Buffer however is not equal to downtime. You sort of expect to use the buffer because the unexpected happens (among other reasons). Making some downtime for your team is a different thing.

re: Buffer, downtime, and productivity

Dean — Thu, 04 Jun 2009 16:23:44 GMT

As Jack mentioned there are many methods and apporaches. What we mustn't forget is Parkinson's Law:

"Work expands so as to fill the time available for its completion."

http://en.wikipedia.org/wiki/Parkinson%27s_law

re: Buffer, downtime, and productivity

Rob Schneider — Thu, 04 Jun 2009 16:36:08 GMT

I would not in general include "buffer" time unless there was a good reason.

I prefer to do a more analytical take on the issue by doing a Monte Carlo simulation of the project plan based on making reasonable assumptions about probabilistic parts, e.g. the durations, start dates, weather down periods, etc. Things the we don't know for certain, but we have judgments of data about their probability. Compute the probability distribution of the completion parameters (date, cost, etc.) of the project. Then based on that set targets. That by definition puts in the net effect of buffers, but in a more understandable way.

re: Buffer, downtime, and productivity

Geo. Cookman — Wed, 15 Jul 2009 02:50:34 GMT

Buffers are not a good idea. Risk Management is. Why? Because the buffer belongs to the sponsor. He or she should decide when to "spend" it. If you have properly alerted the sponsor to the key risks, and how much you and the team think they could delay the project (which you can cost out), then the sponsor owns the risk, not the team. If the risk it realized, i.e., becomes an issue, the PM has the right to submit a Change Request to change the end date and / or cost. The sponsor then decides if that is acceptible. Maybe they will descope the project, maybe they will go for it, but it is their show. The PM is trying to give the sponsor the informaiton they need to make the right business decision. If the PM is sandbagging, he or she is effectively lying to the sponsor ... Oh want a tangled web we weave...when first we practice to deceive...