Hello Josh,
I have been following your website and information for a while now. I find it helpful and insightful. To be honest, I didn’t really think about this question until yesterday. This is a topic about time buffering, a project management best practice. It is a good idea to plan for adjustments, as things will not always go as planned. However, my question is how do you communicate that time?
Any project has a set end date. This is the expectation between the stakeholder (or project leader) as to when it will be completed. Do you communicate the time expectation? Do you communicate the adjusted date with the added time buffer? Do you communicate both?
Conflict is a result of my desire to be honest and straight with people. It is natural to assume that people will work at a faster pace if they are told they have more time. However, if we communicate a date and the expected date of the project, we can manage both. I expect that the date communicated is the required date. However, with the information of the stakeholder about the project deliverable it gives people full visibility to make informed decisions and make prioritization judgements.
I never really thought about it as I have always done both and have been very successful with that approach. I don’t want anyone who would only see the deadline as the date and slow down their pace accordingly. Recently, however, I had to confront a client who was driving one of my teams with fantasy dates (I believe that he is referring time buffering). He feels that they are lying and deceitful. I see both sides. I understand time buffering and believe it is a good practice. However, I prefer full visibility so I can see why they feel they have been lying. I promote honesty and open communication in my culture to encourage honesty and truthfulness.
What are your thoughts? I’m honestly confused by my own thoughts. Thank you for your feedback and keep up the great job!
Respectfully,Jeff
This is a great question. I don’t have the answer, but I can share my thoughts.
This is what I do
My company follows fairly standard software release cycles. The final delivery to customers is waterfall-like. Lean/Agile concepts are applicable within this framework. But that’s another story.
Three major milestones are scheduled towards the end each release cycle. I’ll first explain them and then discuss how Schedule Management Reserve, (SMR), fits into this.
Test Readiness Review (TRR).
TRR is a review with the customer that demonstrates that we are ready and prepared for formal testing of the system.
Our code is now fully developed and tested. We also have peer reviews.
The test cases between TRR and PSR are executed on the system using the appropriate test data to verify requirements, and evaluate the system’s functionality.
Pre-Ship Review (PSR).
PSR is awarded after our testing phase has been completed.
Release Delivery
The PSR date plus the reserve (or buffer) is the release delivery date. If everything goes according to plan, we release on the PSR date. However, testing issues or delays in development can cause delays. Sometimes we even finish earlier, although that’s less frequent.
We end up with a range rather than a single target date. Both our customer and we can accept any date between the PSR or Release Delivery dates.
If you have a customer who thinks that having a schedule reserve is unreasonable, educate them.
