Please login or join to subscribe to this thread
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.
I do agree with Kiron.
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.
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.
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.
where in the PMBoiK Guide do I find this?
In my personal experience you have to decide if baseline is needed. Mainly if you work using agile based approaches.
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.
Please login or join to reply