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.
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
A simple example: Sometimes having a pitch for say 1 hour extends for any reasons. What I do is to issue a change request to the audience. Tell them that I suggest to take another say 10 minutes, and ask for their approval, whoever cannot stay is free to leave. Normally most agree explicitly (raising hands) and only 1-2 leave. Very rarely many say no, and we can skip it this time.
But they feel respected, in control, have certainty and clarity about the remainder and are free to leave. Good vibrations and trust created by 30 seconds talk.
Why would I take 10 minutes more? Rarely I extend scope, e.g. by explaining something more in detail, give an example, tell a story. Mostly I just replied to questions. My initial estimate is normally quite good and I build in some flexibility (reducing scope), so I indeed fill the time allocated.
If you scare away from change requests, you might not have seen the beauty of them. Saving Changes...
Dmitri KozlovskiProject Manager| FDAParsippany, Nj, United States
oh wow - so this escalated quickly from bantering about hypotheticals to sharing real life horror experiences. I swear this was NOT my intent :)
But thanks to all for sharing. This seems to be a real pain point to many and I would be very interested to learn about any policies your organizations might have in place to remedy situations like that.
In the meantime, I am going to continue to insist on getting PCRs done only when there is impact on scope, and not willy-neely schedule adjustments. Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
Apr 03, 2020 9:49 AM
Replying to Peter Rapin
...
My experience and interest is in delivering physical infrastructure. Although I'm sure the Agile affectionatos will object, Agile has limited application in this aspect of project management. A bridge cannot be "adapted" as its being built - you cannot start construction with 2 lanes and finish with 4, or start crossing the Niagara River and end up crossing the St Lawrence, or a cow pasture in the middle of nowhere.
With physical infrastructure you have to get commitment from the 'stakeholders' early in the project and then lay out the route to get there (plan).
Yes, there can be changes but changes hurt, really hurt.
The old adage still applies " Fail to plan - plan to fail".
If, as a project manager, I have the attitude: "We'll get somewhere, sometime with some undefined effort but I'll make sure you're happy when we get there" I will always be able to claim success but most likely not get too many project offers.
An Agile-blindfolded person would say that, a really good Agilist would, through past best practices/refinements and experimentation, come to the conclusion that certain types of products/services are better suited to one methodology or another.
I really like Agile, but it is not suitable for most projects in construction, infrastructure, network/phone, big transport, government (when they require up front requirements), and many other types of industries and business structures.
One could say that purpose of Agile is to adjust and find the best way, so in this trail of thought... you could call everything Agile. Just need to find out for yourself what is the true Agile definition. Saving Changes...
The Red/Yellow/Green stoplight colors for projects can be a political mess with managers wanting to show that they have things under control to their own bosses, while PMs are dutifully trying to show where the true issues are.
I prefer to stick to a very pragmatic approach and use them to send the right message while being very honest. When taking on PMO leadership roles, one of my first tasks has been helping re-define what those colors mean in a consistent and practical way.
If anything late with no ECD drives the whole project to go red because Bob or Karen got sick on a Friday and will finish on Monday, then everything is always red and the real problems become invisible. If it were a warning light in a car that was always on, you would soon learn to ignore the light, and eventually the car would break down without you realizing that this time it was a real problem.
This is where I differentiate the baseline, which is like the big numbers on a tape measure, from the detail plan which includes the smaller increments. If we can move the smaller increments without affecting the larger ones, we can recommit specific schedule dates. If we must move all the measurement points, then we need to strike a new baseline so that everyone is working to the same plan. If we need to reschedule a specific deliverable that is easily recoverable, then we have a plan (or a plan for a plan). If we have no clue what we are going to do, the problem is too big to contain, or we need help from our sponsors, then we raise the red flag so we get the attention it needs. Saving Changes...
