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.
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
Apr 02, 2020 2:49 PM
Replying to 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.
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! Saving Changes...
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?
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. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Re-costing, re-scheduling and re-scoping is a slippery slope. Governments do it all the time. Every project is a success because every project is redefined just before completion to reflect the actual.
You do not want to make it easier to re-schedule (push deliverables forward) than to find ways to recover. Essentially that means there is no plan - we'll complete when we complete.
A run away project is like a gas escaping into an open space - it consumes all the time and money available yet does not increase in substance (and just as difficult to recapture).
Don't fake success by redefining it. Take your lumps.
...
1 reply by Thomas Walenta
Apr 03, 2020 9:08 AM
Thomas Walenta
...
Peter,
isn't this the agile way of running projects: fix cost and schedule and see what we can get out of it. And, most importantly, never look back at what we initially thought the scope would be, but look forward to deliver ever more value?
I think if more 'predictive' projects would handle changes stringently, it would come to more project success. Re-base-lining occurs when a change indeed alters a baseline, after approval of key stakeholders. It should occur only if there still is a valid business case, new funds are available, resources available, deadlines can be shifted, and inter-dependencies are solved.
Keys changes, e.g. to schedules and scope, maybe less to cost, must be communicated to all to ensure aligned working and manage expectations. This alone is a valuable result of a formal change request. Honesty pays.
To be efficient with change management, it is useful to have several levels of change boards, that approve changes. Some authority should be given to the experienced project manager, as judgement comes from experience.
Regarding schedule slippages, the baseline should NOT be full detailed schedule, but a high/medium level that is not so vulnerable to changes, but sufficient enough to align all stakeholders. Besides that, and probably in a rolling wave mode, a detailed schedule should be published for the next 3-4 periods ahead. This does not affect the baseline but provides flexibility for slight slippages.
Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
If slippage is due to a scope change then yes, if it due to work in scope not being delivered when it was due then no. A CR should never be used to justify missing a milestone if it is not associated with scope change.
...
1 reply by Thomas Walenta
Apr 03, 2020 9:18 AM
Thomas Walenta
...
HI Anton,
it is a human bias to underestimate timelines and cost. We are optimistic and may even be persuaded to come to a competitive cost and timeline. If we find this being wrong in the middle of the project, this is basically positive, it is learning and should be dealt with in an appropriate way (as a change request and/or a risk response) and not being put as an additional burden and challenge on the project manager. The project manager might feel forced to cut corners and voila, the next disaster looms that could have been avoided. You get into the swamp one step after the other.
"[...] 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."
You can hear many executives, managers and project managers claiming that they deliver on time and on budget but in reality they do these kind of things in order to appear that they are on track. If these kind of tricks hadn't been used maybe 99% of the projects would have been over budget and late.
This does not happen only in project management. I once worked in operations (support) with SLAs. If an incident could not be resolved in the time imposed by the SLA then we were closing it and we were creating a problem issue for it that did not have a SLA. Officially were were not breaching the SLA but in reality we were. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Apr 02, 2020 7:45 PM
Replying to Peter Rapin
...
Re-costing, re-scheduling and re-scoping is a slippery slope. Governments do it all the time. Every project is a success because every project is redefined just before completion to reflect the actual.
You do not want to make it easier to re-schedule (push deliverables forward) than to find ways to recover. Essentially that means there is no plan - we'll complete when we complete.
A run away project is like a gas escaping into an open space - it consumes all the time and money available yet does not increase in substance (and just as difficult to recapture).
Don't fake success by redefining it. Take your lumps.
Peter,
isn't this the agile way of running projects: fix cost and schedule and see what we can get out of it. And, most importantly, never look back at what we initially thought the scope would be, but look forward to deliver ever more value?
I think if more 'predictive' projects would handle changes stringently, it would come to more project success. Re-base-lining occurs when a change indeed alters a baseline, after approval of key stakeholders. It should occur only if there still is a valid business case, new funds are available, resources available, deadlines can be shifted, and inter-dependencies are solved.
Keys changes, e.g. to schedules and scope, maybe less to cost, must be communicated to all to ensure aligned working and manage expectations. This alone is a valuable result of a formal change request. Honesty pays.
To be efficient with change management, it is useful to have several levels of change boards, that approve changes. Some authority should be given to the experienced project manager, as judgement comes from experience.
Regarding schedule slippages, the baseline should NOT be full detailed schedule, but a high/medium level that is not so vulnerable to changes, but sufficient enough to align all stakeholders. Besides that, and probably in a rolling wave mode, a detailed schedule should be published for the next 3-4 periods ahead. This does not affect the baseline but provides flexibility for slight slippages. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Apr 03, 2020 2:51 AM
Replying to Anton Oosthuizen
...
If slippage is due to a scope change then yes, if it due to work in scope not being delivered when it was due then no. A CR should never be used to justify missing a milestone if it is not associated with scope change.
HI Anton,
it is a human bias to underestimate timelines and cost. We are optimistic and may even be persuaded to come to a competitive cost and timeline. If we find this being wrong in the middle of the project, this is basically positive, it is learning and should be dealt with in an appropriate way (as a change request and/or a risk response) and not being put as an additional burden and challenge on the project manager. The project manager might feel forced to cut corners and voila, the next disaster looms that could have been avoided. You get into the swamp one step after the other.
...
1 reply by Peter Rapin
Apr 03, 2020 9:56 AM
Peter Rapin
...
And thus you perpetuate the initial mistake - overly optimistic cost and time estimate - by not having to take responsibility. Next project opportunity - "don't worry about the estimate, we'll fix it later like we always do."
Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
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.
...
1 reply by Andrew Soswa
Apr 03, 2020 11:01 AM
Andrew Soswa
...
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...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Apr 03, 2020 9:18 AM
Replying to Thomas Walenta
...
HI Anton,
it is a human bias to underestimate timelines and cost. We are optimistic and may even be persuaded to come to a competitive cost and timeline. If we find this being wrong in the middle of the project, this is basically positive, it is learning and should be dealt with in an appropriate way (as a change request and/or a risk response) and not being put as an additional burden and challenge on the project manager. The project manager might feel forced to cut corners and voila, the next disaster looms that could have been avoided. You get into the swamp one step after the other.
And thus you perpetuate the initial mistake - overly optimistic cost and time estimate - by not having to take responsibility. Next project opportunity - "don't worry about the estimate, we'll fix it later like we always do."
...
1 reply by Thomas Walenta
Apr 03, 2020 10:11 AM
Thomas Walenta
...
Well, Peter,
yes, the bias will always be there, but you might become better aware of it. And in any case, if you learn, if you assess your initial assumptions again, you are able to estimate better (until the project end when your estimate equals reality).
Another problem is, if you were in a competitive sales situation and promised something, how to get out of this? Been there for 30 years and can tell stories about how to solve this and how not.
For example, when sales guys get their bonus for selling a solution, the task of the PM starts. So, who estimated? When does the PM blow up the lie? What is the role of ethics and honesty in that game. And do not underestimate the cleverness of the client.
Even delivery management is not interested in trying to solve the issue since they are payed annually, e.g. for resource utilization. I had a manager quit the company in the last year of my project and I was just not fired because I escalated the situation right after project handover from sales, in writing.
And yes, you are right, this is indeed a business model for some.
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Apr 03, 2020 9:56 AM
Replying to Peter Rapin
...
And thus you perpetuate the initial mistake - overly optimistic cost and time estimate - by not having to take responsibility. Next project opportunity - "don't worry about the estimate, we'll fix it later like we always do."
Well, Peter,
yes, the bias will always be there, but you might become better aware of it. And in any case, if you learn, if you assess your initial assumptions again, you are able to estimate better (until the project end when your estimate equals reality).
Another problem is, if you were in a competitive sales situation and promised something, how to get out of this? Been there for 30 years and can tell stories about how to solve this and how not.
For example, when sales guys get their bonus for selling a solution, the task of the PM starts. So, who estimated? When does the PM blow up the lie? What is the role of ethics and honesty in that game. And do not underestimate the cleverness of the client.
Even delivery management is not interested in trying to solve the issue since they are payed annually, e.g. for resource utilization. I had a manager quit the company in the last year of my project and I was just not fired because I escalated the situation right after project handover from sales, in writing.
And yes, you are right, this is indeed a business model for some. Saving Changes...
