What are best practices if you will not meet a target completion date? Do you keep the target and then just report actual complete? Or would there be any reason to change a target complete date? I would like to hear from your experiences. thanks! Saving Changes...
It depends. If the date doesn't change the critical path, then I would typically show the original date and the new expected date. That provides visibility that we are off plan and consuming schedule buffer/float which increases risk.
If there is a major change to the critical path, it might require rebaselining the schedule so that all the moving pieces are in synch. If you think about a schedule with a lot of interrelated dependencies, having many people working to plans based on dates you know that you can't meet can cause confusion, wasted time and effort, faulty priorities, etc.
You really have to look at the effect of the missed date on the project and make a judgement call.
...
1 reply by Stéphane Parent
Oct 26, 2022 12:58 PM
Stéphane Parent
...
I usually avoid re-baselining a schedule unless it is a result of a change. Of course, we can often be quite liberal with our defintion of "change".
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Oct 26, 2022 11:51 AM
Replying to Keith Novak
...
It depends. If the date doesn't change the critical path, then I would typically show the original date and the new expected date. That provides visibility that we are off plan and consuming schedule buffer/float which increases risk.
If there is a major change to the critical path, it might require rebaselining the schedule so that all the moving pieces are in synch. If you think about a schedule with a lot of interrelated dependencies, having many people working to plans based on dates you know that you can't meet can cause confusion, wasted time and effort, faulty priorities, etc.
You really have to look at the effect of the missed date on the project and make a judgement call.
I usually avoid re-baselining a schedule unless it is a result of a change. Of course, we can often be quite liberal with our defintion of "change".
...
1 reply by Keith Novak
Oct 26, 2022 1:11 PM
Keith Novak
...
I do too, but sometimes some event has such a cascading effect that redlining all the dates makes the schedule unreadable. Either we need a recovery plan to show all the impacted dates and new actions without all the confusing clutter, or a new baseline which would involve supplier contracts and all the formal resource planning to support.
I agree though though just changing the plan to match the actuals is very bad practice.
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Did you identify a schedule variance threshold in your project management plan? You should be thinking of variance corrective actions if your schedule is outside of the defined thresholds (i.e. out of whack). Saving Changes...
I usually avoid re-baselining a schedule unless it is a result of a change. Of course, we can often be quite liberal with our defintion of "change".
I do too, but sometimes some event has such a cascading effect that redlining all the dates makes the schedule unreadable. Either we need a recovery plan to show all the impacted dates and new actions without all the confusing clutter, or a new baseline which would involve supplier contracts and all the formal resource planning to support.
I agree though though just changing the plan to match the actuals is very bad practice.
...
1 reply by Stéphane Parent
Oct 26, 2022 5:48 PM
Stéphane Parent
...
Sounds like the "event", in this case, is the change.
Changing completion date to meet the plan goes against good project management practice. You can calculate the schedule variance and the schedule performance index to obtain a value about your project delay. Saving Changes...
Before updating plans, I'd first meet with the team to review options and if the approved date (either project completion or an intermediary milestone) can't be achieved, I'd meet with key senior stakeholders such as the customer and sponsor to review the issue and decide how they'd like to proceed.
You should be maintaining an updated schedule (and cost and quality and benefits...) forecast, but whether the approved plan is updated to reflect that forecast is subject to your project change control policies and procedures.
Kiron Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Oct 26, 2022 1:11 PM
Replying to Keith Novak
...
I do too, but sometimes some event has such a cascading effect that redlining all the dates makes the schedule unreadable. Either we need a recovery plan to show all the impacted dates and new actions without all the confusing clutter, or a new baseline which would involve supplier contracts and all the formal resource planning to support.
I agree though though just changing the plan to match the actuals is very bad practice.
Sounds like the "event", in this case, is the change. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The reason because organizations hired project managers is because to avoid risks or in other words to avoid "do not come with surprises" related to projects. So, a delay has to be detected in advance. Perhaps the "best tool" to do that is risk management. With that said, when you detect a deviation a change has to be created. Project management is accountable for all activities defined in the change managment process to put on the table all the needed information to facilitate the decision related to the change. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Elizabeth
happens very often.
First, be transparent with the deviation, share it in the team, with sponsors and clients. If you detect it early enough to be able to catchup, it is a risk to be shared, which might be followed by a change. If you have no clue how to meet the deadline, it is already a change. I am with Sergio on this.
Many options are available to hold the date, including
- fast tracking - doing things in parallel, which might not be available if this the last and only left activity in the project, but if you recognise the deviation risk early enough is always an option
- adding skilled resources to speed up - normally takes time to acquire and onboard them (and be aware of the rule that adding people to a late project makes it later)
- descope - deliver a first tranche of scope with immediately needed functionality and plan for when to deliver the rest, often results in releases
- shift the date, if nothing else is available, but evaluate what it means to your stakeholders (is the team still booked, reputation for your company, lost revenue for the client etc) before suggesting a shift Saving Changes...
