September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
the PMBoK is written in very broad terms so often I find that when something appears to be missing it is just not very obvious. Changes to schedule often do require a formally approved change. My employer has a change type specifically to recommit the dates without changing any of the work content.
The reason this is important is schedules are often very integrated. If I change my design release date, that may impact other design release dates from other teams who need my work as the basis of their own. It may also impact downstream manufacturing plans, supplier committments, and whatever else. It is that formal recommittment process that figures out all of what is impacted, and sometimes we find things we didn't consider.
Once the change is formally approved, the schedule dates for all the various impacted stakeholders now have formally committed plans based on the new date.
Keith is right, if anything in the approved Project Management Plan changes, it is subject to change control. Think about cost rates, quality requirements, resource availability beyond scope and schedule.
The change procedures could have different change control board levels with thresholds defined, at the lowest level the project manager, the top level the steering committee.
A most important aspect of change control is that accepted changes are communicated, so there is the need to at least document the PCR and how it is handled.
This is actually a very common situation.
From a purist perspective, a variance remains a variance and using change control to make it "go away" is not ideal since post-project one would have to compare final results against original approved baselines to understand true performance.
However, if you think about a long running project, if a variance which cannot be absorbed occurs early in the life of the project, do you want to psychologically penalize the team and other stakeholders by calling the project "red" or "yellow" till the end of time? Also, in many organizations such as large banks or government agencies, projects cannot overspend, hence cost variances must be approved and result in a re-baselining of your budget.
I am so glad I came upon this thread, because we are having this very conversation in my organizational unit right now.
We are trying to set some ground rules for "junior" PMs as to when and how to address changes on the project.
And so far we agreed that unless there is a change in scope or objectives, we will treat the schedule slippage as delay and manage it accordingly.
But in a few instances, the variance is so large (in years) that we have to resort to re-baselining the schedule via CR process.
My opinion is that should something like this happen, PM needs to address the possible scope adjustments with the project leadership, possibly breaking the scope into more manageable chunks or introducing phased approach. It just does not sound right to issue a PCR just to keep KPIs from slipping into "yellow" or "red".
So I would be very interested in hearing more opinions on this subject.
I must add that we took PMBOK as a basis for our PM methodology, but do not follow it religiously, neither do we practice pure Agile - rather sort of adaptive project management approach.
If the project duration is short, then continue to report true slippage as a variance. However, as I indicated in my original note, for projects where variances occur early on, the psychological pain caused by showing a project as being "red" for many months or years shouldn't be discounted and assuming all stakeholders are agreeable, re-baseling but preserving the original baselines is a common practice.
I guess, next step would be to define what is considered "short" and "early on".
Most of our projects are about a year-long (plus/minus few weeks) - to me it's a "short project", considering other government initiatives. So would you say then that "early on" would be two-three months delay? Please keep in mind that I will be using your opinion here as a "voice of authority", when presenting my findings to my leadership :)
We do have a couple of projects that now have been going on for almost 5 years and we have done just what you suggested - instead of keeping them in "red", re-baseline the schedule, albeit the scope remained the same.
I agree with Kiron.
There is a darker side of frequent re-baselining that was discussed a few posts ago. Some PMs want to look great, with green status, throughout the project, so they rebaseline often. I think, if PM is trying to be honest (and not political) the PM should not show project in Red all the time, it should be rebaselined - but - all stakeholders should be totally onboard with the decision (why, how, etc).
Re: slippage. Somehow I think that the discussion is tainted by thinking that "slippage without increased cost" is ok. It don't think it is because there the project has to consider calculating ROI, Present Value vs Future Value, IRR, first-to-market, resource allocations and other factors.
Secondly, I am a little confused about the point of PM wanting "to be honest (and not political) by not showing project in RED all the time". I might be reading something wrong way here, but if a PM wants to be honest (BTW, there is no alternative, IMHO) she/he must accurately reflect a status, even if it is red all the time. Now, being political is to an extent a part of the game - one must know about politics going on and then present the facts (unadulterated facts) in a manner that plays up to all involved stakeholders.
Please login or join to reply