Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Scheduling
What are Some Common Criteria for When Schedule Rebaselining is Required
avatar
John Bacon Project Manager /Agile Product Owner| Not Disclosed Fl, USA
I'm developing a schedule management plan for my project and my organizations PM maturity level is still at an Ad-Hoc level. In the schedule management plan in the schedule changes section, I'm trying to come up with the events or conditions that would prompt a schedule to have to be rebaselined. A couple thoughts I had were:

1. If an approved change request results in an increase or decrease in overall schedule duration by 10% or more.
2. If the Duration Variance (Difference between Baseline Duration and Actual Duration) for the overall project reaches 15%, likely because many of the tasks are finishing behind schedule

What other criteria might I include that would require rebaselining a project schedule?
Sort By:
< 1 2 3 >
avatar
Kiron Bondale
Community Champion
Retired | Mentor| Retired Welland, Ontario, Canada
John -

By the book, the only time you'd re-baseline is if there is an approved change which impacts key milestones or the project end date. A variance (regardless of its magnitude) should not result in a baseline change, otherwise your actuals will always match your (approved) plan!

From a reality perspective, I have worked for organizations where their governance bodies elected to authorize re-baselining once a variance was unrecoverable.

Kiron
...
3 replies by Francisco Masbad, John Bacon, and Mohammed Alansi
Aug 09, 2022 1:25 PM
John Bacon
...
Thanks for the info. When you refer to by the book, is this in the PMBOK guide or PMI Guid for Schedule Development?
Aug 16, 2022 4:45 PM
Mohammed Alansi
...
I also do agree with Kiron
Mar 11, 2024 7:55 PM
Francisco Masbad
...
Good day! Yes, I do agree with Kiron. From a reality perspective, that's one of the reasons why Subcontractors claimed from main Contractor the construction compensation/ damages due to re-baselining. I have worked for EPC Contractor, the PMT decided to re-baseline 6 times. The Subcontractor claimed 6 times accordingly. It's a good lesson learnt.
avatar
Abolfazl Yousefi Darestani Manager, Quality and Continuous Improvement| Hörmann-TNR Industrial Doors Newmarket, Ontario, Canada
I do agree with Kiron.
avatar
John Bacon Project Manager /Agile Product Owner| Not Disclosed Fl, USA
Aug 09, 2022 9:40 AM
Replying to Kiron Bondale
...
John -

By the book, the only time you'd re-baseline is if there is an approved change which impacts key milestones or the project end date. A variance (regardless of its magnitude) should not result in a baseline change, otherwise your actuals will always match your (approved) plan!

From a reality perspective, I have worked for organizations where their governance bodies elected to authorize re-baselining once a variance was unrecoverable.

Kiron
Thanks for the info. When you refer to by the book, is this in the PMBOK guide or PMI Guid for Schedule Development?
...
1 reply by Kiron Bondale
Aug 10, 2022 7:44 AM
Kiron Bondale
...
Page 210 of the Sixth Edition of the PMBOK Guide covers both the conditions I'd mentioned in my original response.

Kiron
avatar
VerĂ³nica Elizabeth Pozo Ruiz
Community Champion
RYLAI Access Control Quito, Pichincha, Ecuador
I agree with Kiron. According to PMBOK, rebaseline is only performed when the end project date or key milestones are affected with a significant change request approved.
...
1 reply by Thomas Walenta
Aug 10, 2022 5:13 AM
Thomas Walenta
...
Hi Veronica,
where in the PMBoiK Guide do I find this?
avatar
Keith Novak Tukwila, Wa, USA
The unrecoverable variance can be a big driver. If you have some major issue that drives a variance to a major milestone, then that in turn can affect a very large number of smaller milestones and release events.

If you try to depict the schedule graphically, you have so many event slides that the schedule becomes extremely confusing if not completely unreadable. That can cause even more problems with people planning to bad dates so there might be a decision to reset the baseline so that everyone is working to the same plan.
avatar
David Portas Ny, USA
Maybe it's worth mentioning that in some contexts the temptation to baseline plans at all ought to be resisted. In software development for example, the plan may evolve so quickly that comparing any current iteration to previous iterations, particularly early ones, would be a distraction and counter-productive. OKRs, velocity, burn charts and other metrics ought to be more useful.
avatar
Thomas Walenta Global Project Economy Expert| self Hackenheim, Germany
Aug 09, 2022 4:22 PM
Replying to VerĂ³nica Elizabeth Pozo Ruiz
...
I agree with Kiron. According to PMBOK, rebaseline is only performed when the end project date or key milestones are affected with a significant change request approved.
Hi Veronica,
where in the PMBoiK Guide do I find this?
avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
In my personal experience you have to decide if baseline is needed. Mainly if you work using agile based approaches.
avatar
Kiron Bondale
Community Champion
Retired | Mentor| Retired Welland, Ontario, Canada
Aug 09, 2022 1:25 PM
Replying to John Bacon
...
Thanks for the info. When you refer to by the book, is this in the PMBOK guide or PMI Guid for Schedule Development?
Page 210 of the Sixth Edition of the PMBOK Guide covers both the conditions I'd mentioned in my original response.

Kiron
...
1 reply by Thomas Walenta
Aug 10, 2022 11:06 AM
Thomas Walenta
...
Sorry Kiron,

could not find the language you refer to in PMBoK 6th. Page 210 refers to CPM and says nothing about baselining, but I also scanned the rest.

Certainly it depends on what the organisation wants (if they want anything about scheduling). For me the primary purpose of a schedule is communication and since we have different stakeholders with different communication needs, we have different representations of the schedule, all based on the same schedule model which is baselined (not a schedule is baselined).

So, I can define when deviations should lead to changes, but nevertheless when communicating to the team at work, I probably do not show them 2 years of activities, or slipped or original start dates but the next 3 months of actual planned dates, as I expect them to meet them. KISS. (Gets even more stressful for them when I use CCM techniques).
When communicating to the sponsor, I do not show them variations of all task start/end dates but the milestones, both planned and actual, and which of the next ones bear a risk. And yes, the 2 year GANTT chart on 1 page , to remind them about what the project is about (they might sponsor 10+ projects and do operations, after all).
When reality (actuals) deviates too far from the plan, I tend to reduce complexity by introducing re-baselining. New stuff comes up all the times, estimates show up too optimistic, team members change ... it is not hard to find reasons for a change.

I have no emotional attachment to the original baseline. It is faulty anyhow and should not create additional obstacles. Yes, if shifting the deadline becomes necessary, too many stakeholders are affected, and other options should be considered. I found massaging the scope and quality easiest and most common.

Thomas
avatar
Peter Rapin Subject Matter Expect; Project Delivery| Independent Consultant Ontario, Canada
I really avoid rebaselining as it becomes too convenient to adjust delivery based on monthly updates or whatever seems suitable at the time. Rebaselining should be part and parcel of revising the Project Charter as you need authorization of all original stakeholders signatory to the Charter. Too many project final reports claim delivery compliance based on revised schedules rather than what was initially projected.

I see schedules somewhat like budgets. It should include contingency and risk allowance and thus a delay within the contingency is not grounds for a rebaseline. A rebaseline should only be contemplated when all contingency is gone and there is no hope of recovery. - essentially a major adjustment to project delivery requiring appropriate authorization.
< 1 2 3 >

Please login or join to reply

Content ID:
ADVERTISEMENTS

"It is better to deserve honors and not have them than to have them and not to deserve them."

- Mark Twain

ADVERTISEMENT

Sponsors