audio


 

 



Is Time Buffering Dishonest?

Is Time Buffering Dishonest?

by Josh

Hello Josh,

I have been following your site and information for some time now and have always found it to be helpful and insightful. I have a question that to be honest I never really thought about until yesterday. The topic is on the project management best practice of time buffering. It is common and wise to build in time to allow for adjustments as things will always go not as planned but my question is what are your thoughts on communicating that time?

There is a planned end date to any project where the expectation is set between the stakeholder and the project leader as to when the completion date is to be. Do you communicate the actual time expectation set? Do you communicate the adjusted date with the time buffer built in? Do you communicate both?

My confliction comes from wanting to be straight and honest with people. While it can be natural to assume that if people are told they have additional time they will work to that pace I believe that if you communicate an actual date along with the project expectation date we can manage do both. I have the expectation that the date communicated to the project deliverable is the date needed but with the knowledge of the project deliverable to the stakeholder it allows people full visibility to make intelligent decisions along the way should they need to make prioritization judgment calls.

I had never really thought about much as I have always done both and been very successful with that approach. I assume that anyone that would see only the late deliverable date as the date and slow their pace accordingly is not someone I want in my project teams. Recently however I have a client who is driving one of my teams with what one team member calls fantasy dates (I believe he is referring to time buffering) and feels that they are being deceitful and not honest. I see both sides in that I understand time buffering and believe as a best practice it is wise I also prefer full visibility and can see why they feel they are being dishonest. I have a culture and environment where I require and encourage full truth telling to empower people to just be straight and real with all things.

What are your thoughts on this? I am honestly confused within my own thoughts! Thanks for any feedback you can give and keep up the great work!

Respectfully,
Jeff

This is a great question, and while I may not have “THE” answer I can share my thoughts.

This Is What I Do

At my organization we work with fairly standard software release cycles, waterfall in nature in terms of the final delivery to the customer. I employ Lean/Agile concepts and techniques were applicable within this framework, but that’s another story.

We schedule 3 major milestones towards the end of any release cycle.  I’ll explain them a little first and then talk about how Schedule Management Reserve (SMR) fits into this.

Test Readiness Review (TRR)

TRR is a review held with the customer demonstrating that we have prepared and are ready for formal testing of the system.

At this point our code has been developed and unit tested, and we’ve also held peer reviews of the code.

Between TRR and PSR the test cases are executed on the system with appropriate test data to verify requirements and evaluate the functionality of the system.

Pre-Ship Review (PSR)

PSR is held when our testing phase has been successfully passed.

Release Delivery

The release delivery date is the PSR date plus the reserve (or buffer if you like).  If everything goes according to plan we’d release on the scheduled PSR date, but snafus in testing or even earlier in development may delay us. Sometimes we even finish early (although that’s less common).

So we basically end up with a range instead of a single target date. Anywhere between the PSR and Release Delivery dates are acceptable to both us and our customer.

If you have a customer that thinks having schedule reserve is unreasonable, you need to educate your customer about how product development really works.

It’s Not All Sunshine and Rainbows

There is known risk involved and there are unknown variables at play.

That’s par for the course with product development of any kind.

My opinion is that being as open and honest as possible with your teams, customer, and sponsor is the best policy.

When I’ve heard or seen people being secretive with schedule data, it’s usually because there is a sponsor or customer involved who is a bully.

As the project manager, part of your job is to stand up to bullies and turn them into friends of your project.

Leave a Comment

{ 8 comments… read them below or add one }

Steve Ford August 9, 2012 at 11:18 pm

Josh,

That’s a great answer… as you stated… honesty is the best policy! That being said… there is almost always hidden reserve, float or contengency built into just about any schedule. In aerospace you may find an activity just prior to Launch Readiness activities so that any observer can easily see how much contengency is available after each update cycle… it gives management the ability to protect a firm launch date and feel good about it!

However, we usually find that during the construction of a schedule, when planners meet with engineers and project managers to discuss Design, Fabrication, Integration and Tests… there is always “built-in” or “hidden” reserve… its human nature not to want the spotlight shown on “your work” causing a schedule slip… especially if “your work” is sitting on the critical path!

A seasoned planner will ask questions such as “does it really take 34 days to run that test”… “historical data dictates we have only taken 28 days to perform a vibration test”…etc. It is very important to build a relationship of trust with your team… so that they realize you are there to help them not cause problems for them… this will help minimize hidden reserves and enable the planner to produce a more realistic schedule. Will there still be hidden areas? Sure… but usually at a minimum.

There is nothing wrong with “reserve” no matter what method you use… but we want to manage it in order to provide a solid believeable and trustworthy plan… planning to succeed will utilize “contengency” smartly… planning “not to fail” can bloat reserves leaving you with a schedule full of surprises.

It’s ok to tell management or stakeholders where reserves are… most likely the more informed they are the higher their comfort level will be with the entire schedule! Still, some managers may still challange their team to reduce reserves if they don’t believe what they are seeing…

Just my opinion!
Steve

Reply

Josh August 10, 2012 at 3:28 pm

Great comment Steve, thanks for chiming in!

Reply

Josh August 10, 2012 at 3:31 pm

Especially with new product development that is relatively unique, it can be difficult to come up with solid estimates in the first place. One thing I’ve re-learned over the past few years is to remember that when using new technologies in particular when developing a product additional risk is present and can easily be not accounted for in estimates properly.

I made this mistake myself, even though I should have known better and seen it coming.

Reply

Mike Clayton August 10, 2012 at 2:08 am

Josh,

I also think that the dishonesty arises not from your actions, but from how you represent them to your stakeholders: your client, your boss, your team, your partners. When challenged by a client about time buffering in the past, i have been very open and told them: “we can squeeze out the contingency and have a big risk, or we can keep it in and I can look you in the eye and confidently state that my team will hit the big milestones (subject, as always, to the big shift that can sometimes hit the fan)”.

This seems to me to be about having a mature conversation with the client but of course does not answer the substantive question it raises: “how much buffer?” This will always be a compromise between risk and cost (in time terms). The central requirement is for good judgement – in complex projects this means good judgement over what estimating tools to use (like monte-carlo simulations), how to use them properly, and how to generate robust input estimates for them. As so often, the answer to Jeff’s question relies on the wisdom and experience of the PM and their extended team.

All the best
Mike

Reply

Josh August 10, 2012 at 3:29 pm

Very well put Mike. Those conversations about the reality of risk and how contingency helps mitigate it need to be had in a candid manner.

Reply

Tom Long August 10, 2012 at 6:00 am

In construction, buffering of the schedule is a risk management tool. You have to remember though, nothing happens in a vacuum. If you constantly sandbag your schedules the owner will automatically deduct that buffer in their head. Either that, or they will find someone who will carry more risk in the schedule.

When developing a schedule each activity duration is examined for the following:

” optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected
pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes).
most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal.
expected time (TE): the best estimate of the time required to accomplish a task, accounting for the fact that things don’t always proceed as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time).

TE = (O + 4M + P) ÷ 6″

In construction contract law and schedule specifications there is a thing called “Float Sequestering.” Because time in construction is a valuable resource and often shared by the owner and contractor to mitigate unforeseen conditions, too much buffering can be seen by the owner as unlawful enrichment.

In complex schedules the best way to secure options for schedule slippage mitigation is through logic. Meaning, given unlimited manpower you can probably perform many tasks simultaneously. Manpower leveling, smoothing out the labor so that you don’t have ten workers for two days, one worker for three days, and then ten again, is sufficient justification for the contractor not performing all work as soon as it is available. This falls under the contractor’s right to means and methods. It also allows for the contractor to add more manpower and accelerate the schedule to mitigate slippage.

Part of scheduling is an art form. You learn through experience which activities, or sequence of activities hold the greatest risk. You would never build a schedule on the most pessimistic view, or you will never get another project again. You will also never build a schedule overly optimistic, or you will have a cash flow problem with the constant acceleration needed to meet the schedule.

Reply

Josh August 10, 2012 at 3:39 pm

Excellent comment Tom, and some excellent insight into how things are done in construction projects.

Do you call out specific portions of schedule float or reserve for inclement weather, or how is that type of thing handled?

Reply

Tom Long August 10, 2012 at 4:10 pm

Josh,
That is a touchy subject in my field. We utilize different calendars for different activities, which sometimes causes problems, expecially with SS and FF lags.

There are many ways of dealing with weather. Keep in mind, in construction the contractor assumes all risks for normal weather and inclimate weather is an excusable delay. The best way I like is to have a different calendar for activities impacted by weather. In the north, there is a quantifiable amount of work days lost. To address this I designate the last friday of the month as a “holiday” or non-work day. If you took out the first Friday it would slide the activities performed at the begnining of the month later. Since most schedules are updated at the end of the month, the contingency day is “actualized” out of the schedule for the next month.

Reply

{ 2 trackbacks }

Previous post:

Next post:

audio