Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Change Management, Scheduling
Using a Project Change Request to manage schedule slippage
Anonymous
Hello - While I have been managing projects for years, I have only recently begun the formal approach of project management as defined by the PMBOK and am still in learning mode.

I recently joined a company where I have found that if something has caused the schedule to be delayed (be it a resource just didn't get to a task or another dependency was not finished at the due date) they issue a PCR (Project Change Request) to extend the timeline so that their KPIs don't turn the project yellow or red. This is a practice that seems to be supported by the PMO as well.

My issue is, as I was reading the PMBOK and understanding the use of a change request, I took it more as a "If something changes with the scope" or if something actively changes the project's objectives, that's when you analyze that change and process a request.

Am I just being too literal? I would assume that if the schedule is slipping, that's just something to be managed versus waving a PCR wand to fix it.

Appreciate the help.
Sort By:
Page: 1 2 3 next>
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.

Kiron
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.
...
1 reply by Kiron Bondale
Apr 02, 2020 10:52 AM
Kiron Bondale
...
Dmitri -

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.

Kiron
Apr 02, 2020 10:00 AM
Replying to Dmitri Kozlovski
...
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.
Dmitri -

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.

Kiron
...
1 reply by Dmitri Kozlovski
Apr 02, 2020 11:23 AM
Dmitri Kozlovski
...
Kiron, thanks for a reply.

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.
Apr 02, 2020 10:52 AM
Replying to Kiron Bondale
...
Dmitri -

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.

Kiron
Kiron, thanks for a reply.

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.
...
1 reply by Kiron Bondale
Apr 02, 2020 2:21 PM
Kiron Bondale
...
With most predictive projects, it is rare that you'll hit that sort of slippage that quickly so you'd be more likely to encounter big, scary issues mid-way or late in the life of the project.

Kiron
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.
...
1 reply by Dmitri Kozlovski
Apr 02, 2020 2:49 PM
Dmitri Kozlovski
...
So to the first point - that would be un-ethical according to PMI Code of Ethics. Wanting to look good, with green status and fudging the numbers - that's not managing a project.

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.
Apr 02, 2020 11:23 AM
Replying to Dmitri Kozlovski
...
Kiron, thanks for a reply.

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.
With most predictive projects, it is rare that you'll hit that sort of slippage that quickly so you'd be more likely to encounter big, scary issues mid-way or late in the life of the project.

Kiron
...
1 reply by Dmitri Kozlovski
Apr 02, 2020 2:50 PM
Dmitri Kozlovski
...
ah, so we can agree then that in most cases a PCR should be submitted to reflect a change in scope or project objectives, and schedule changes are really far and between and can be considered extraordinary events, right?
Apr 02, 2020 2:14 PM
Replying to Andrew Soswa
...
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.
So to the first point - that would be un-ethical according to PMI Code of Ethics. Wanting to look good, with green status and fudging the numbers - that's not managing a project.

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.
...
1 reply by Andrew Soswa
Apr 02, 2020 3:58 PM
Andrew Soswa
...
After 17+ years in PM business, 23 full time jobs, 50+ gigs, of which 1/3 in consulting and 2/3 as an employee...I have to say that ethical reporting is in the eye of the beholder.
I learned not to spit against the wind but too much politics and coverup rubs me the wrong way.

If the project is over-budget, over-schedule, with limited understanding of scope, created by your bosses for a client, and you were just onboarded to execute it - what's the point in accurate reporting.
So assume, you will try to be ethical PM, you'd have to re-estimate all project criteria and if you identify that the initial project was set up just to onboard the client with lowball offer - will you report it?
Or if you find out that all your KPIs are in red, will you rebaseline project without analyzing the root cause and presenting the findings to the client. Maybe you will just give it to your Exec team with hopes that they will ethically report it to the client?

Just saying... a PM is as good as their moral backbone!
Apr 02, 2020 2:21 PM
Replying to Kiron Bondale
...
With most predictive projects, it is rare that you'll hit that sort of slippage that quickly so you'd be more likely to encounter big, scary issues mid-way or late in the life of the project.

Kiron
ah, so we can agree then that in most cases a PCR should be submitted to reflect a change in scope or project objectives, and schedule changes are really far and between and can be considered extraordinary events, right?
...
1 reply by Kiron Bondale
Apr 02, 2020 4:35 PM
Kiron Bondale
...
Correct as far as the use of a PCR covering legitimate changes to any of the approved baselines for a project. The use of a PCR to legitimize a variance of some manner should be the exception rather than the rule, and that only if all stakeholders are fully aware and onboard with this practice.
Page: 1 2 3 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

It is wonderful to be here in the great state of Chicago.

- Dan Quayle

ADVERTISEMENT

Sponsors