Using a Project Change Request to manage schedule slippage
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.
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. Saving Changes...
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. Saving Changes...
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.