Is Time Buffering Dishonest?

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.