More and more I am seeing Project Change Request submissions that request a return to green health by re-baselining schedule. The rationale varies....poor vendor code quality, lack of internal resource availability, doing something took longer than expected. I am pretty traditional and rigid regarding what I feel constitutes changing of a schedule baseline. I would like to know if any of you have a definition or set of criteria that works for you/your organization. Saving Changes...
I am skeptical of management who wants to re-baseline a project to show it green. Resetting the plan to equal actual performance often hides all the problems.
On the other hand, when you show a baseline plus several schedule slides and accepted change requests, it becomes very difficult to understand the baseline, which is what everyone on the project uses to coordinate their own activities.
If it is just to get to green, then you really need to ensure your risk register is current. The many performance issues occurred for a reason, and you likely have compressed the schedule in areas which are now at risk of not meeting the new plan.
I have not seen a fixed set of criteria unless we have planned blockpoints to occasionally update the baseline similar to rolling wave planning. The cost to rebaseline may be significant however since it may impact many if not all parties involved in the project.
In my work we often consider whether we can manage 80% of the project to the baseline and the 20% exceptions at risk, or the risk of managing exceptions is too high, and it justifies resetting everyone's schedules. Managing many simultaneous recovery plans is also costly. It increases the risk that a late discovery will upset the plans of teams still working to the baseline, causing even more disruption. Saving Changes...
From a purist perspective, baseline updates should be driven by approved changes and not to formalize an unrecoverable negative variance.
However, there are contextual reasons for doing so:
1. In some companies, it is not permitted to spend money you weren't approved to spend (from a policy perspective). Public sector agencies are good examples of this. In such cases, a negative cost variance MUST result in an update to a financial baseline.
2. If a schedule negative variance is unrecoverable and the project has many months or years to go, holding that "over the head" of the team can sometimes be demoralizing so in such cases a "reset" is desirable. It doesn't prevent folks from being able to compare how far off the original baseline the team had strayed.
Kiron Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
My interpretation of "baseline" is a representation of what we intended to accomplish "at the beginning". It seems that some want to revised the baseline in terms of re-writing history - the revised baseline overwrites the original, ie., this is what we really meant. I see no honest purpose in that.
However I see great value in updating plans, including revised cost, time and scope objectives, to reflect today's reality. These should not be labelled 'baseline'.
In my experience governments are experts at adjusting baselines as the project advances so that they don't have to answer to comparisons of actual to initial or intended project delivery. Especially when it costs three times as much and takes twice as long to get only part of the promised scope.
If/when a project exceeds the allowed variances (+/-%) ie., it falls outside the initial scope and constraints, thus:
New Project = New Baseline.
...
1 reply by Keith Novak
Dec 23, 2020 3:54 PM
Keith Novak
...
The term baseline has largely lost its original meaning from what I can tell. Really it is like the prime meridian running through Greenwich England that serves as the reference system for longitude and time around the globe. That is a literal baseline in the truest sense of the word originating in map making. Different locations may shift the time for convenience, but GMT serves as the reference system. Periodically GMT changes slightly, and other time zones shift in response.
It's a very useful concept since projects often have a lot of local deviations from the established plans which change day by day. Those deviations can be managed locally with little external impact. The true plan is then the baseline plus approved changes/deviations. Resetting the baseline however, like moving the completion date to the left, requires everyone to replan.
My interpretation of "baseline" is a representation of what we intended to accomplish "at the beginning". It seems that some want to revised the baseline in terms of re-writing history - the revised baseline overwrites the original, ie., this is what we really meant. I see no honest purpose in that.
However I see great value in updating plans, including revised cost, time and scope objectives, to reflect today's reality. These should not be labelled 'baseline'.
In my experience governments are experts at adjusting baselines as the project advances so that they don't have to answer to comparisons of actual to initial or intended project delivery. Especially when it costs three times as much and takes twice as long to get only part of the promised scope.
If/when a project exceeds the allowed variances (+/-%) ie., it falls outside the initial scope and constraints, thus:
New Project = New Baseline.
The term baseline has largely lost its original meaning from what I can tell. Really it is like the prime meridian running through Greenwich England that serves as the reference system for longitude and time around the globe. That is a literal baseline in the truest sense of the word originating in map making. Different locations may shift the time for convenience, but GMT serves as the reference system. Periodically GMT changes slightly, and other time zones shift in response.
It's a very useful concept since projects often have a lot of local deviations from the established plans which change day by day. Those deviations can be managed locally with little external impact. The true plan is then the baseline plus approved changes/deviations. Resetting the baseline however, like moving the completion date to the left, requires everyone to replan. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Some points: 1-a change request could be or not could be for put the project in green. 2-if you are using baseline, baseline is unchangeable from the original. In fact, there is no reason to change the baseline to put a project in green. 3-I saw along the years (and it is what I do from long time ago) that baseline has no sense. There are other ways to control a project, but just my personal experience and something I wrote in a research paper and I exposed in PMI World Tour meetings. But again, just my personal opinion which I can sustain. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Baseline is an important concept from a contractual perspective - it sets the conditions at the time of the agreement. Changes to the baseline are potential changes in the contract leading to damages.
Baseline is also useful when identifying gaps and developing recovery plans - how do we get back to the initial plan.
If the initial plan is no longer feasible then we essentially have a new project. Not only does everyone have to replan but also re-commit.
ie, is the project viable at 75% scope, double the cost taking one and a half times longer to deliver? New business case, new authorization! Saving Changes...
It's clear that people have different meanings when it comes to the term baseline. I have frequently seen that in my own experience where it is applied in different contexts. It's a subject I think would make a good webinar because I see a lot of PM functionality in the concept that not everyone has seen in practice when it comes to efficient change management.
The definition I use relates back to the origin of the term in map making where is a convenient established reference system. When you get too far from your original reference system, it adds significant complication so a new baseline is established to simplify future work. In many contexts people on a project may even use different baselines to reduce the impact of change, when reusing existing work to develop new products.
It's one of those terms where I often find people disagree because they don't recognize that they are using the same word in the same context, but each person has different definitions, creating confusion. Saving Changes...
"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."
