Project Management Central

Please login or join to subscribe to this thread

Topics: Communications Management, Scheduling
when buffer is not enough
Network:68



Hi everyone, I need some help here.
I have worked as a PM for 10 years now, as I progress in my career I am a the level of reporting to Senior VPs and Directors and I've found myself on a situation I seem to not been able to figure out, get out of or understand.
I have applied PM techniques for many years and in the PM environment I've done the scheduling, risk management, scoping and all this techniques, but the more and more high I report all this seems to be far from what my stakeholders expect to hear about.
I've not been able to manage their expectations or not able to communicate, and as my Schedules have slipped and I have to give bad news it gets worst.
I have had a couple of large programs 3-5 years with 5 million dollar budgets and have had some delays, a 6 month delay which I was not able to oversee, even when I had used best practices in scheduling, buffer and risk management. I don't know what to do with a Program so large and with so many unknowns, should I had a 50% buffer just in case? And if I did, will they be expecting this to be late anyway? so if I had said my project was going to last another year when it started it would have been unacceptable, and as I approached my timeline and announced a 6month delay due to unforeseen issues, 6 month delay on a 4 year project was completely unacceptable too, so I find myself wondering what do I do, I don't have other people to ask for advice on this matter, I will appreciate your input
Sort By:
Page: 1 2 next>
Network:297



You’ve encountered some pretty significant unknowns, and it sounds like you might encounter still more. Unknowns are unavoidable on any project, but I'm wondering if this project’s tasks, risks and/or relevant stakeholders weren't defined thoroughly. If this is the case, simply increasing your buffer probably wouldn’t have helped. I suggest you examine the project to identify more tasks, risks and stakeholders, and then rebaseline it. This will give you a more accurate schedule, and you’ll be able to give the Senior VPs and Directors more realistic expectations.
...
1 reply by Betzabe Villarreal
May 22, 2017 4:30 PM
Betzabe Villarreal
...
Hi Eric, in this case the task were very fix, as well as the Stakeholders, it was just an issue that was already on our risks and we had planned for, but it went out of our hands regarding how long was going to take to resolve, and although we had informed of this in advance and even communicated of the 6 month delay a year in advance, still the timeline was not possible for me to estimate. Re-baseline is something is not spoken off
Network:68



May 22, 2017 4:13 PM
Replying to Eric Simms
...
You’ve encountered some pretty significant unknowns, and it sounds like you might encounter still more. Unknowns are unavoidable on any project, but I'm wondering if this project’s tasks, risks and/or relevant stakeholders weren't defined thoroughly. If this is the case, simply increasing your buffer probably wouldn’t have helped. I suggest you examine the project to identify more tasks, risks and stakeholders, and then rebaseline it. This will give you a more accurate schedule, and you’ll be able to give the Senior VPs and Directors more realistic expectations.
Hi Eric, in this case the task were very fix, as well as the Stakeholders, it was just an issue that was already on our risks and we had planned for, but it went out of our hands regarding how long was going to take to resolve, and although we had informed of this in advance and even communicated of the 6 month delay a year in advance, still the timeline was not possible for me to estimate. Re-baseline is something is not spoken off
Network:156



Betzabe, I am inclined to agree with Eric. You indicated that the risk was identified in your project plan and even planned for, but you were unable to control that risk. The indication there is that neither the impact of the risk nor the planned course of action to deal with the risk were appropriately identified and agreed to. One of the major items at this point is to review your Risk Assessment and ensure that all stakeholders agree with the courses of action (including rebaselining for significant events, if possible) and trigger points associated with the existing risks. Even if you can't rebaseline, you need to make sure that everyone is on the same page related to potential future impacts.

As for the next steps, your existing plan is no longer valid, and reporting against it is only going to continue to create tension between yourself and upper management. The first conversation I would have is with the Project Sponsor. Discuss that you need to re-evaluate the scope and schedule for the project (and most likely the budget too), due to the delay. Identify that the existing project schedule is 6 months+ out of alignment and that continuing to use those details will only continue to provide a false picture of the actual project status. Then let him/her you need his/her support in getting approval for a rebaseline.

That is only the starting point. There are a lot of steps associated with project recovery. Regrettably, contingency is not typically the silver bullet for these issues because the first thing upper management tends to take exception to and then cut is that contingency. A 50% contingency would never have "made the grade."

Expectation management, change management, and a solid communication plan will be your best friends until the end of your project. Best of luck.
...
1 reply by Betzabe Villarreal
Jun 03, 2017 5:06 PM
Betzabe Villarreal
...
Matthew, the matter of the fact is that a rebaseline is considered as a failure, I requested that and also asked for a change, but this is not acceptable. After the new target and baseline were set and we successfully attain it on time this time, it was considered a failure because it was not delivered at first. That is why I am asking about buffers, because even with involvement of all stakeholders, and team members and risks , things happen that no one foresee and then re baseline is not acceptable it is simply fixing what was done wrong at the beginning.
The expectation management is the part I believe is my handicap, when do you inform of the change to still look like you are in control, I just simply can't pin point that, and about the communication plan well I simply don't have access to the sponsor nor the steering committee.
Network:68



May 23, 2017 11:33 AM
Replying to Matthew Morey
...
Betzabe, I am inclined to agree with Eric. You indicated that the risk was identified in your project plan and even planned for, but you were unable to control that risk. The indication there is that neither the impact of the risk nor the planned course of action to deal with the risk were appropriately identified and agreed to. One of the major items at this point is to review your Risk Assessment and ensure that all stakeholders agree with the courses of action (including rebaselining for significant events, if possible) and trigger points associated with the existing risks. Even if you can't rebaseline, you need to make sure that everyone is on the same page related to potential future impacts.

As for the next steps, your existing plan is no longer valid, and reporting against it is only going to continue to create tension between yourself and upper management. The first conversation I would have is with the Project Sponsor. Discuss that you need to re-evaluate the scope and schedule for the project (and most likely the budget too), due to the delay. Identify that the existing project schedule is 6 months+ out of alignment and that continuing to use those details will only continue to provide a false picture of the actual project status. Then let him/her you need his/her support in getting approval for a rebaseline.

That is only the starting point. There are a lot of steps associated with project recovery. Regrettably, contingency is not typically the silver bullet for these issues because the first thing upper management tends to take exception to and then cut is that contingency. A 50% contingency would never have "made the grade."

Expectation management, change management, and a solid communication plan will be your best friends until the end of your project. Best of luck.
Matthew, the matter of the fact is that a rebaseline is considered as a failure, I requested that and also asked for a change, but this is not acceptable. After the new target and baseline were set and we successfully attain it on time this time, it was considered a failure because it was not delivered at first. That is why I am asking about buffers, because even with involvement of all stakeholders, and team members and risks , things happen that no one foresee and then re baseline is not acceptable it is simply fixing what was done wrong at the beginning.
The expectation management is the part I believe is my handicap, when do you inform of the change to still look like you are in control, I just simply can't pin point that, and about the communication plan well I simply don't have access to the sponsor nor the steering committee.
...
1 reply by Matthew Morey
Jun 05, 2017 12:25 PM
Matthew Morey
...
Betzabe:
I think I have a better understanding of the issue, based on this response. For the future (so that you don't run into this again) I would say buffers are only the first step. The other items to do at the very beginning of the next project are to fully describe not only the scope that you will deliver but what is considered out of bounds for the project (what will not be delivered). In addition, a listing of assumptions/requirements as part of the scope statement is usually a smart thing to do, so that you have reasons to work through a change management process.

Which is the other thing that needs to be defined at the beginning of the project. stakeholders, upper management, and the project team need to understand the boundaries of the scope (what is and is not included) as well as the assumptions that the scope is built on. Then everyone needs to know that a specific change management process is the ONLY way to adjust the project and that changes can happen when adjustments are necessary due to changes to the assumptions.

With the combination of the two, you have started the expectation management process. When someone provides an update or requirement outside of the Scope definition, then you can point them to the change management process. If it is important enough for the project, people will follow the process. If it is fluff, they will grumble about the process, but leave it alone (provided the ENTIRE TEAM knows to follow the process). To address your second point, as the PM it is critical that you have communication with sponsor and steering committee. If you aren't able to do that now, then talk with your manager about the deficiency and how it is hindering your ability to manage the project. Identify ways that YOU can help bridge that gap. If you wait for them to come to you, it will get very lonely, because they won't think to. Too often these critical project contributors have day jobs that distract them from the project details.

Buffer is useful when someone says it will take them 3 days of work to do something and you allocate 5 because the person isn't going to be able to fully dedicate a concentrated 3 days, or if you know the ballpark cost for material, but want wiggle room in case market conditions change. I hesitate to recommend too large a contingency or buffer because it screams to management that you don't know what you are looking at and is usually the first target for cuts. In addition, the project teams tend to take advantage of extravagant buffers (i.e. I could do this today, but I have until Friday, so why rush?). Buffers have a tendency of being used up, and very early if the PM isn't careful.

Looks like I wrote a small novella, my apologies. I hope you find this helpful.
Network:3461



I feel your pain what a tough situation to be in. I have to wonder, how much of what is going on has to do with the culture. I've been on projects where people were forced to estimate tasks and timelines, but key high level stakeholders trumped the decision making process, forced their agenda and made it impossible to keep to the deadline. Though this may not be your situation at all, it is worth a look to see if at the root of it are people being forced to make unrealistic choices and a leadership who are inclined to ignore practical advice.
Network:366



Hi Betzabe

I exactly know what you mean. Because I managed large programs, heavy teams, dispersed, diversified, no voice, no organization, no structure and programs about 25plus million.

Now, for the question you put out- first of all, any amount of buffer would not help avoid risks or project failures, whether small or big, large or small.

Now in terms of mitigating risks, close monitoring of risks so they don;t become issues is highly critical in such large programs. Accountability of the stakeholders, higher visibility, problem-solving, assigning risk owners, making the project to red/yellow is crucial. Yes, you will go through fire drills, from upper management but you as a PM is only accountable for reporting, monitoring and controlling of risks/issues along with your triple constraints. Chaos happens, and if we let go of the grip, it multiplies, so hold accountable of the stakeholders from where the work is slipping.

Buffers aka contingencies can be added as quantified/identified/unknown risks. unknowns are always unknowns. You don't know what you don't know, however, if a buffer is quantified, the manageability is easier and you have something to baseline on.

Hope this helps!!
Network:366



Also, I worked at various companies, only a couple did a max 10%buffer for the unknowns, and the one now, I am working on, has a very strict PM process and does not even allow any buffer. We obtain LOE and if there is a variance, it is reported and explained.
Network:1314



(1) Did the scope of development change? If so, then you need to re-estimate the new development timeline and communicate to stakeholders and get their agreement on this.
(2) Did you involve the actual team in providing estimates? In our project we have a (kind of like MPP) SharePoint spreadsheet which we use to allocate tasks for different team members based on their availability. So a person A will get tasks sequentially keeping in mind the time taken to complete these tasks. We talk with the team, make them understand the upcoming tasks and the duration it takes. If they feel that the task needs more time, there is negotiations (and corrective actions). Otherwise they are told to push the red button when they feel that the task is taking time (could be due to any reasons).
Network:1314



Try to use Agile principles wherever possible. Identify team members who are not adhering to set deadlines. They may need training or they may be having other secondary tasks given to them unknown to you or they may be spending time in meetings, emails, calls, etc which are not adding value. Find out how you can eliminate waste.
Network:2034



Do we (Project Manager or Team) have control on buffers? Unknow buffers(Management Reserve)-- decided or derived by Senior Managment/Clients (Not by the team/SME). Buffer handling is one of the key factors helps to measure/determine the capability of Project Manager. To add the additional buffer in the plan is not easy because it will indirectly increase project cost & time.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Teachers open the door, but you must enter by yourself."

- Chinese Proverb

ADVERTISEMENT

Sponsors