Buffer Time in Project Management
3 years back, when I was not a part of project management, I was not aware of the term "Buffer Time" or BT. or fairly I can say I was not aware of the actual meaning of "BT". When I primarily started my carrier in Project Management, I came to know the actual and meaningful meaning of this term. I was fortunate to start my role in project management in a very small company but a value centric company with a genuine and great management team. At that time, I was under the impression that BT means time that is being kept by the management to protect the project from the impact. I believe that is somehow the appropriate definition of BT. At that time, I tried my best to keep BT on the basis of other factors so that it can be evaluated in a proper way.
As far as factors affecting the BT is concern, two factors “Risks” and “Dependencies” plays an important role to evaluate this. There are some common rules based on these two factors that calculate the BT for any project. Whenever I asked to provide the effort estimation for any Testing cycle, I always try my best to calculate the effort estimation including BT on the basis on these two factors – Risks and Dependencies.
But now days, BT is becoming a part of effort estimation in projects. Let me clear it in a mathematical way.
What I have seen recently is that Buffer Time is being used by the teams (either development or Test) as a part of performing their activities. In that case, if anything goes wrong i.e. any of the risk or dependency happen, the project delays. Ideally, the BT should not be used in the primary activities. The managers should not disclose the BT to the front desk employees. If the BT is being shared with the team members, everyone is assuming this time as a regular project activity time. These practices definitely delay the project deadlines.
But before calculating the BT, the managers should be aware of the risks and dependencies. Not to disclose this but I have seen some managers in my carrier who are not aware of these terms and managing the project. What a joke.
I have seen on the road traffic signals a great example of crushing the BT. The vehicle owners always look on the other side traffic signal so that they can act according to its movement. If there is a green signal and the traffic goes on, the other side vehicle owners will not see their respective traffic lights. They will see the other side traffic lights and immediately when the green turns to orange, they start running irrespective of the fact that they still have red light to stop.
Now this orange light is the BT. But who cares. People start their vehicles running on orange light itself. Most of the accidents I have seen in the traffic signals in due to this BT crushing.
So a million dollar tip for the managers is that they be aware of the risks and dependencies of the projects and should try their best to evaluate the BT. If possible, do not disclose the BT in front of your team and if you have to do that, in any case, keep another BT for the completion of the project still on the planned dates.
(Quality Assurance and Testing Expert)
1 comment:
I personally appreciate the comparison of Buffer Time of Project management with the Traffic Signal. Traffic Signal is definitely is rare example to present in a better way of how the Buffer Time is being ruined by the teams and their managers.
* J. Belcho *
Post a Comment