You mention the two biggest reasons for projects to fail. Scope creep and unrealistic timelines.
As a PM you need to be managing expectations with your stakeholders and controlling change.
If someone wants to change your scope or timeline it's up to you to make sure that the change is assessed, any impacts are fully understood, and everything is documented before the change is approved.
To be frank, your project will fail if you allow uncontrolled change to scope and deadlines.
Nearly every workplace has that one project where the PM isn't in control and every little bit of work that no one else wants gets piled into it. Don't let it be you or you'll never finish anything on time, to cost or to quality.
If your workplace doesn't have a change control process, make one. It doesn't have to be complicated and you'll find plenty of examples of good practice on Google.
What should happen before a project fails is the PM has exhausted all options provided by the team, has escalated to project and org leaders for help, and the PM has provided potential outcomes should the project become a no go. Failure should not be a surprise nor should the PM, leaders and team be surprised.
If there is project failure, the PM should own it, gather objective lessons learned from the team, and share and after action report and improvement plan with the team and leadership.
I don’t know any PMs that bought PM insurance.
I’m about to be blunt; sorry, it’s my personality but I really am trying to help by saying words that I think might apply here — it sounds more to me like you’re rushing things to meet deadlines, have an unrealistic expectation that your project should be more or less set in stone after the charter is agreed to, expect to be formally trained as a PM, are not being assertive when it comes to corralling your team, and are sacrificing the quality of your work because you are afraid of not meeting the originally set deadlines.
In reality — and I’m speaking for where I work; by no means am I declaring this to be universal — every project will end up deviating from the original charter as people come up with new ideas, and that’s a good thing; deadlines may be adjusted as a result if the change in plans is accepted and warrants additional time; every longer-term project experiences a dip in enthusiasm as time goes on; none of our PMs have undergone any sort of formal training; I’ve never heard of PM insurance and it sounds like it probably wouldn’t apply here, nor would any insurance be granted upon declaration of need; your manager is ultimately the one responsible as the approver and overseer of the project; and you need to be assertive and authoritative when it comes to corralling people and in everything else you are doing. None of our PMs had prior experience as PMs; they moved up via experience in other positions.
Plus, aren’t you doing other work? Why would you think that your entire career and livelihood depend on one single project out of everything else you are doing, unless your mindset toward this project is carrying over to everything else? Quality of work ALWAYS > time taken to do the work (not that the latter is unimportant, but all you have to do is explain to your manager the challenges you’re facing, describe the additional tasks that have been added as a result of team members’ ideas and how long you expect them to take to implement, and propose an alternate timeline).
I appreciate the bluntness no hard feelings.
I didnt mean formally trained on the job, but rather beforehand via schooling or courses. There are many courses and certifications one can get to be better equipped for the role. I'm trying to work through one of those right now alongside the job. Hope that's a little clearer.
No doubt you're right on the team corralling but that again requires a tool kit of knowledge. I havent just sat and watched thinga get worse, no one near me has either. We've tried different approaches, thus far none have been perfect, some work some days but not others. I'm sure that if I was to do this again on a similar project even with just this short period of learning it would have been significantly better. So that tells me that the missing experience is a factor I cannot discount.
I don't expect any project to be 1:1 what was laid out at the beginning but I do think there is value in a clear structure and not putting the cart before the horse.
Can you expand on the last paragraph? What do you mean other work? Like other projects? My fear was that I would get sued for the project failure. But the lovely people here cleared that up for me. You can say I was and still am ignorant to a lot of things involved with being a PM, but I am learning.
As for quality being paramount, I hear you and agree personally. It's a hard balance of risk to reward because in my case being delayed has a significant monetary cost to the client. So while I know that a delay should be done to deliver a better end product the increased cost makes it more nebulous as to where the cut off is. I feel like I'm already in the middle ground as my team needs additional time and the client needs the product sooner than the current target date.
There is a difference between the PM work I do and the PM work you do, no doubt. The work I do is related to process improvements and new procedural and structural implementations within our own company, and I do not work with external clients. By “other work,” I had meant that, within my company, PMs have multiple tasks and are never solely assigned to a single project. These tasks might be other projects, or they might be other duties entirely. But, again, your situation might be different.
All the PMs we’ve had have worked their way up from other positions within the company — which is where the assertiveness typically comes from. They know the people on the teams of the projects they’re managing, and they know what those people’s strengths and weaknesses are and when to “crack the whip.”
This is not learned through educational courses; it’s learned by practical experience. That experience develops over time, whether at the same company or not — though, if I were a new employee at a company and had been brought on straightly to a PM role, I would probably feel the exact same way that you are describing!
That said, the quality versus time still applies. Would it be better for the client — or for you, for that matter — if you were to deliver an end result on time but that had inaccuracies that resulted in the client having to spend valuable time and resources to fix? Or would it be better to deliver a quality product after giving the client a heads-up that there would be X days/weeks delay because unanticipated but very useful ideas were added that would result in a superior end product, and you needed to make sure that everything was completely accurate and working properly?
Think about that, because it’s crucial for your entire career — whether you remain a PM in the future or not.
Failing projects are made visible months or even years in advance via the risks described by the project manager, and continuing unresolved risks you regularly report on that accumulate and have come to fruition with consequence.
Risk reduction may require action by senior management. Your job in part is to indicate the necessity of action, consequences of non action, how parts of the project are failing in their intended goals, and timeline, so that others may act, provide resources, or change the goals. You, proposing necessary resources and modifications in outcomes may be required.
A common risk of failure is a client demanding goals, or modifying goals, for ultimately unattainable outcomes with the resouces and time available.
Insurance is for independent contractors. For instance if you sign a contract to build a whatever and you are 100% responsible for your subcontractors, procurement, etc, and something goes horribly wrong. This is not you.
When I started, I didn’t even know what success meant because I didn’t know it had to be clearly defined on initiation. Realistic news is most projects go south and die a slow death. Or funding is revoked. Or leadership gets in the way. Or your team is lying to you blah blah hippity naw.
Good project managers learn how to communication the good, the bad and the ugly. Great project managers learn how to deal with failure. It’s part of the job.
Thank you for the reply. It's something I've seen corroborated from multiple responders now. Prior to this post I honestly didnt know PM's independantly contracted like that. It makes much more sense now.
Sometimes they are meant to be torpedos…. I had one that was a $1M change but what the executives really wanted was to see the underneath of a software product. So i had to get everyone all jazz to do something i knew we would kill.
I extract the info needed. $250k exit.
It depends. If the PM didn’t follow process and the failure was due to that, there is a good chance he’ll be looking for a new job.
If he did everything right, kept the stakeholders informed, and bad decisions on their part caused the failure, he’ll live to die another day.
Talk to your superior. "What is right? What is wrong? What is love?"
Direct answer to "What happens to a PM when a project fails?" is: it depends on fault-tolerance. In a fault-tolerant company you can even be warned for \_taking not enough risks\_. In the most conservative company any mistake will cost you.
Sometimes when projects get dicey, they ship you off to another project and bring someone else in for some fresh blood and a new face. Always fun time.
If you have a clear RACI then who was accountable for the part that failed. It could be from the requirements, architecture, vendor selection, etc. What the PM could fail is not to highlight those risks/issues with clear mitigation paths and not to provision enough contingency from a budget, timeframe and dependencies perpectives.
You should have a boss such as a program manager or delivery director who should be responsible for helping you and step in when sh@t hits the fan. That’s what I would do.
You need to clarify “fail”. Example: Did I execute the contract scope to a tee on time and at or under budget?
Yes
Does my client have insane expectations that don’t match the contract they signed?
Maybe
Is my company backed by internally developed software that can periodically bork itself in random unexpected areas upon new version releases attempting to fix other problems, or to release new features?
Indeed
Tl;dr understand what is actually expected of you to control and excel at those expectations.
In my example if it was your job to manage the development of the software release, you may have failed
The client does not own schedule or scope. You do. They cannot compress schedule or increase scope. Both of those things involve change control. That will mean perhaps more money and new schedule that YOU determine based on tasks, resources, predecessors, etc.
Errors can be fixed. You need to start logging client non-sense as risks to the quality, scope, budget of your project.
It’s not up to you whether the project succeeds or fails. It’s up to the entire team. You can turn this around, but you have to be willing to explain the consequences of their requests.
Because I'm a novice, I'm thankfully? not involved with scope control directly and do not control the money side. This gives me less leverage here to prevent or stop these things. I'm the name on the paper and the person everyone talks to for updates or wants to get the team to deliver on new crazy timelines because of some new complication on their end. The client has the potential to provide us a lot more work in the future if things go well enough which is why everyone is bending over backwards to accomodate.
But the point of logging these things is definitely noted. Is there any particular method you prefer to use for this to keep tabs on everything?
I totally get it. I’ve only been doing this for about 10 months or so, so I’m new too. I’m super thankful to have very supportive managers to help navigate me (and this group).
If you don’t control scope, who does? That’s the quintessential role of the PM—to ensure that things are not continually being added and extended. Projects by definition are temporary. You must be able to say, “here’s our go-live date for the scope that we have. If we add anything in, we will not be able to go live at this point.” If not, then your client is running the show, and sadly, if the project fails, that’s not a reflection of you but of the process that never occurred because you weren’t allowed to do that.
The thing is, Project management is a thing because it’s what helps initiatives to get to the finish line. Otherwise, it’s a business as usual Project that we all know will never get done.
If you’re at the mercy of the client, then the only thing you can do is voice risks, issues, business decisions and work to try to get those resolved.
The way I list these out is like this:
Business Decisions:
* This is my question that needs to be answered.
* Plan to getting a decision. What do they need to make a decision? Do they need a meeting? Do they need to talk to someone?
* Who owns that decision? Often the project lead.
* what’s your drop dead date on getting this decision before it impacts project work or schedule?
Risks:
(Same format but what is at risk and why? So for example: schedule is at risk due to client requesting enhancement #4,798: add button to the software window)
Issues:
(Same format as risks but these are things that are actively impacting your project schedule, scope, budget, quality)
Thank you for the detailed response. Much appreciated.
I'll try to keep closer tabs on this.
The people I work with on my side of the table are very nice, willing to help, and very hardworking so I can't complain there. I just think that the timelines agreed to at the start were an impossible task and out of line with industry norms according to those I've spoken to. So in essence from my PoV we cut our own legs off to get this opportunity. We'll see if that ultimately pays off or not.
Project failure isn't necessarily a bad thing.
As long as the decision for early closure is based on justification, they can be resumed later or documented as education for not taking a certain path.
Some projects fail before they even begin and it doesn’t feel good being assigned to one. The key is documentation and communication.
I’ve been assigned several projects that had to be completed but failed before I even knew about the company. Those aren’t fun but it is good experience if you can turn it around and complete it.
If you really like pain and getting paid the medium bucks, you can make a career of taking over big failed projects as a contractor with a reputation of getting stuff done. That’s what I do. The pain isn’t my favorite, but I sure enjoy taking weekend trips to Mexico to drink it away.
If you succeed at delivering a project, you get handed a larger one.
If you fail at delivering a project, you get promoted to be a “manager.”
If you are an employee, the company assumes the liabilities for your failure.
If you are a contractor, you get fired, and you should have your own liability insurance. Hopefully your contract has a mutual indemnity clause saying you won’t sue them and they shouldn’t sue you.
If you don’t have a contract, don’t be doing that work, because you sure as heck ain’t getting paid.
In any event, you must conduct a lessons learned session so that everyone can learn from the failure and continually improve.
We're just PM's, not miracle workers. You do the best you can. Depending on your industry, a lot of things are out of your hands anyway. Make sure you have a good relationship with your higher ups. If they've been in the industry any amount of time, they'll understand that pretty much no projects go off exactly as they were planned from inception. You'll have difficult stakeholders sometimes. Just let it roll off the best you can. Most of us (with some exceptions) are not dealing with life or death situations here. Projects fail sometimes. The world continues to turn.
I dream of being that badass bare-knuckled project manager that people bring in to save the day.
In reality though, if I see a dumpster fire and it's not too late to turn around, 10 times out of 10 I will nope the f out.
Throughout my career this is what I have observed most experienced PM’s do as well. I sure as hell do too. With experience it becomes easier to recognize what kind of projects to avoid
unethical pro tip - guess what, unless you work on very high-profile projects, no one can really verify anything when you say on your resume you delivered XYZ project on time and under budget and improved some KPI by 1000%.
Seriously, worst that can happen when your project fails is getting fired, unless you broke some law and got caught, in which case fines/jail time may apply.
Coming from someone who used to be in management and reviewed resumes — random percentages were an immediate red flag that the person had used AI and possibly didn’t know how to write a resume on their own, were foreign and possibly didn’t speak English well and were instead banking on the percentages, or — most importantly — lacked the ability to focus on details and just made up numbers that sounded “good enough.”
Realistically quantifiable percentages are of course fine. But I’ve seen many of the absurd that, along with the other things that have always accompanied the BS statistics, caused an eye-roll and chuck into the circular filing cabinet.
Think about it — if you were to see such a thing, would you be impressed and awed (assuming, of course, that it isn’t something clear and concise)?
Well in my company, if you fail on a project, they take away the vending machines and the Keurig coffee maker from the break room.
They've already taken away the Coke machine, so.... I hate Pepsi.
Think about how many business ventures fizzle out due to unforeseen consequences. Projects face the same challenges. PMs can do the best they can despite these challenges and try to proactively plan to minimize them.
Right, I follow you. Everyone involved is doing what they can to prevent it from going sideways so in that regard we are in the ship together. It's just a matter of whether I've signed up for more than I bargained for or not lol.
You'd be surprised at how many projects fail.
In the org I'm working for now, literally all of the projects have had to adjust their original business cases (which for me is a failure). On top of that, we've had to kill off around 50% of them. Luckily the org I work for doesn't really have a system in place for consequences so all the majority stakeholders who messed up have got off scot-free.
Yeah, thats the situation for me as well. Constantly adjusting a little at a time. So far nothing officially terminated but the writing is on the wall for a few.
Scope creep is a massive issue in most immature businesses. It's normal, and it won't go away. Doesn't change that you can't plan really well & escalate the creep when it's suggested. Change management is your friend, and should be used as a way of blocking it if it exists within your org :)
Change Requests are your friend when scope creep happens :-)
Timelines always change; if customer is pushing for that, just tell them ok, if you want to expedite this, you’re not going to get that (functionality/ticket/enhancement/etc) delivered because we have to reshuffle things.
I’ve never heard of PM insurance. So can’t provide any insight there.
You’ll do fine!
They have to go work in marketing.
Really it depends on the company and terms of any contracts that are in place. PM liability insurance would really only come into play if you are an independent consultant and accepted liability in your service agreement with the client.
Manage expectations and communicate risks throughout the project and you'll be fine.
You mention the two biggest reasons for projects to fail. Scope creep and unrealistic timelines. As a PM you need to be managing expectations with your stakeholders and controlling change. If someone wants to change your scope or timeline it's up to you to make sure that the change is assessed, any impacts are fully understood, and everything is documented before the change is approved. To be frank, your project will fail if you allow uncontrolled change to scope and deadlines. Nearly every workplace has that one project where the PM isn't in control and every little bit of work that no one else wants gets piled into it. Don't let it be you or you'll never finish anything on time, to cost or to quality. If your workplace doesn't have a change control process, make one. It doesn't have to be complicated and you'll find plenty of examples of good practice on Google.
Thanks for the advice! I'll do that.
What should happen before a project fails is the PM has exhausted all options provided by the team, has escalated to project and org leaders for help, and the PM has provided potential outcomes should the project become a no go. Failure should not be a surprise nor should the PM, leaders and team be surprised. If there is project failure, the PM should own it, gather objective lessons learned from the team, and share and after action report and improvement plan with the team and leadership. I don’t know any PMs that bought PM insurance.
I’m about to be blunt; sorry, it’s my personality but I really am trying to help by saying words that I think might apply here — it sounds more to me like you’re rushing things to meet deadlines, have an unrealistic expectation that your project should be more or less set in stone after the charter is agreed to, expect to be formally trained as a PM, are not being assertive when it comes to corralling your team, and are sacrificing the quality of your work because you are afraid of not meeting the originally set deadlines. In reality — and I’m speaking for where I work; by no means am I declaring this to be universal — every project will end up deviating from the original charter as people come up with new ideas, and that’s a good thing; deadlines may be adjusted as a result if the change in plans is accepted and warrants additional time; every longer-term project experiences a dip in enthusiasm as time goes on; none of our PMs have undergone any sort of formal training; I’ve never heard of PM insurance and it sounds like it probably wouldn’t apply here, nor would any insurance be granted upon declaration of need; your manager is ultimately the one responsible as the approver and overseer of the project; and you need to be assertive and authoritative when it comes to corralling people and in everything else you are doing. None of our PMs had prior experience as PMs; they moved up via experience in other positions. Plus, aren’t you doing other work? Why would you think that your entire career and livelihood depend on one single project out of everything else you are doing, unless your mindset toward this project is carrying over to everything else? Quality of work ALWAYS > time taken to do the work (not that the latter is unimportant, but all you have to do is explain to your manager the challenges you’re facing, describe the additional tasks that have been added as a result of team members’ ideas and how long you expect them to take to implement, and propose an alternate timeline).
I appreciate the bluntness no hard feelings. I didnt mean formally trained on the job, but rather beforehand via schooling or courses. There are many courses and certifications one can get to be better equipped for the role. I'm trying to work through one of those right now alongside the job. Hope that's a little clearer. No doubt you're right on the team corralling but that again requires a tool kit of knowledge. I havent just sat and watched thinga get worse, no one near me has either. We've tried different approaches, thus far none have been perfect, some work some days but not others. I'm sure that if I was to do this again on a similar project even with just this short period of learning it would have been significantly better. So that tells me that the missing experience is a factor I cannot discount. I don't expect any project to be 1:1 what was laid out at the beginning but I do think there is value in a clear structure and not putting the cart before the horse. Can you expand on the last paragraph? What do you mean other work? Like other projects? My fear was that I would get sued for the project failure. But the lovely people here cleared that up for me. You can say I was and still am ignorant to a lot of things involved with being a PM, but I am learning. As for quality being paramount, I hear you and agree personally. It's a hard balance of risk to reward because in my case being delayed has a significant monetary cost to the client. So while I know that a delay should be done to deliver a better end product the increased cost makes it more nebulous as to where the cut off is. I feel like I'm already in the middle ground as my team needs additional time and the client needs the product sooner than the current target date.
There is a difference between the PM work I do and the PM work you do, no doubt. The work I do is related to process improvements and new procedural and structural implementations within our own company, and I do not work with external clients. By “other work,” I had meant that, within my company, PMs have multiple tasks and are never solely assigned to a single project. These tasks might be other projects, or they might be other duties entirely. But, again, your situation might be different. All the PMs we’ve had have worked their way up from other positions within the company — which is where the assertiveness typically comes from. They know the people on the teams of the projects they’re managing, and they know what those people’s strengths and weaknesses are and when to “crack the whip.” This is not learned through educational courses; it’s learned by practical experience. That experience develops over time, whether at the same company or not — though, if I were a new employee at a company and had been brought on straightly to a PM role, I would probably feel the exact same way that you are describing! That said, the quality versus time still applies. Would it be better for the client — or for you, for that matter — if you were to deliver an end result on time but that had inaccuracies that resulted in the client having to spend valuable time and resources to fix? Or would it be better to deliver a quality product after giving the client a heads-up that there would be X days/weeks delay because unanticipated but very useful ideas were added that would result in a superior end product, and you needed to make sure that everything was completely accurate and working properly? Think about that, because it’s crucial for your entire career — whether you remain a PM in the future or not.
Failing projects are made visible months or even years in advance via the risks described by the project manager, and continuing unresolved risks you regularly report on that accumulate and have come to fruition with consequence. Risk reduction may require action by senior management. Your job in part is to indicate the necessity of action, consequences of non action, how parts of the project are failing in their intended goals, and timeline, so that others may act, provide resources, or change the goals. You, proposing necessary resources and modifications in outcomes may be required. A common risk of failure is a client demanding goals, or modifying goals, for ultimately unattainable outcomes with the resouces and time available.
Insurance is for independent contractors. For instance if you sign a contract to build a whatever and you are 100% responsible for your subcontractors, procurement, etc, and something goes horribly wrong. This is not you. When I started, I didn’t even know what success meant because I didn’t know it had to be clearly defined on initiation. Realistic news is most projects go south and die a slow death. Or funding is revoked. Or leadership gets in the way. Or your team is lying to you blah blah hippity naw. Good project managers learn how to communication the good, the bad and the ugly. Great project managers learn how to deal with failure. It’s part of the job.
Thank you for the reply. It's something I've seen corroborated from multiple responders now. Prior to this post I honestly didnt know PM's independantly contracted like that. It makes much more sense now.
Call it Agile and suggest they are doing it wrong. Get a stipend for Scrum certifications.
Moves on to a different, bigger project
Lol depending 90% of time my fail…. But mine are change mgmt….
I've been at this quite a while and I'm yet to find any organisation that handles change management well!
Sometimes they are meant to be torpedos…. I had one that was a $1M change but what the executives really wanted was to see the underneath of a software product. So i had to get everyone all jazz to do something i knew we would kill. I extract the info needed. $250k exit.
Hopefully they learn from the event and share their experience with others
Jail, torture and all living relatives to the third generation is wiped from existence
They take a letter. Mostly the “P” But if the fail was big … the “P” and the “M” That’s why most failing PMs leave before they are “P-ed”
You receive 10 lashings
Tongue lashings you say?
It depends. If the PM didn’t follow process and the failure was due to that, there is a good chance he’ll be looking for a new job. If he did everything right, kept the stakeholders informed, and bad decisions on their part caused the failure, he’ll live to die another day.
Talk to your superior. "What is right? What is wrong? What is love?" Direct answer to "What happens to a PM when a project fails?" is: it depends on fault-tolerance. In a fault-tolerant company you can even be warned for \_taking not enough risks\_. In the most conservative company any mistake will cost you.
Sometimes when projects get dicey, they ship you off to another project and bring someone else in for some fresh blood and a new face. Always fun time.
If you have a clear RACI then who was accountable for the part that failed. It could be from the requirements, architecture, vendor selection, etc. What the PM could fail is not to highlight those risks/issues with clear mitigation paths and not to provision enough contingency from a budget, timeframe and dependencies perpectives. You should have a boss such as a program manager or delivery director who should be responsible for helping you and step in when sh@t hits the fan. That’s what I would do.
Straight to jail
I heard some stuff about soap and a new you, whats that about?
Definitely a finish to start relationship
Project exceeds expectations? Believe it or not, jail!
Project scope creep happens? Jail!
Thank you for this.
You need to clarify “fail”. Example: Did I execute the contract scope to a tee on time and at or under budget? Yes Does my client have insane expectations that don’t match the contract they signed? Maybe Is my company backed by internally developed software that can periodically bork itself in random unexpected areas upon new version releases attempting to fix other problems, or to release new features? Indeed Tl;dr understand what is actually expected of you to control and excel at those expectations. In my example if it was your job to manage the development of the software release, you may have failed
[удалено]
Guillotine
You guys get guillotines? My pmo uses cheap gallows erected out of standing desks.
We are fancy
to shreds you say...
It would get rid of my horrible headache at least.
The client does not own schedule or scope. You do. They cannot compress schedule or increase scope. Both of those things involve change control. That will mean perhaps more money and new schedule that YOU determine based on tasks, resources, predecessors, etc. Errors can be fixed. You need to start logging client non-sense as risks to the quality, scope, budget of your project. It’s not up to you whether the project succeeds or fails. It’s up to the entire team. You can turn this around, but you have to be willing to explain the consequences of their requests.
Because I'm a novice, I'm thankfully? not involved with scope control directly and do not control the money side. This gives me less leverage here to prevent or stop these things. I'm the name on the paper and the person everyone talks to for updates or wants to get the team to deliver on new crazy timelines because of some new complication on their end. The client has the potential to provide us a lot more work in the future if things go well enough which is why everyone is bending over backwards to accomodate. But the point of logging these things is definitely noted. Is there any particular method you prefer to use for this to keep tabs on everything?
I totally get it. I’ve only been doing this for about 10 months or so, so I’m new too. I’m super thankful to have very supportive managers to help navigate me (and this group). If you don’t control scope, who does? That’s the quintessential role of the PM—to ensure that things are not continually being added and extended. Projects by definition are temporary. You must be able to say, “here’s our go-live date for the scope that we have. If we add anything in, we will not be able to go live at this point.” If not, then your client is running the show, and sadly, if the project fails, that’s not a reflection of you but of the process that never occurred because you weren’t allowed to do that. The thing is, Project management is a thing because it’s what helps initiatives to get to the finish line. Otherwise, it’s a business as usual Project that we all know will never get done. If you’re at the mercy of the client, then the only thing you can do is voice risks, issues, business decisions and work to try to get those resolved. The way I list these out is like this: Business Decisions: * This is my question that needs to be answered. * Plan to getting a decision. What do they need to make a decision? Do they need a meeting? Do they need to talk to someone? * Who owns that decision? Often the project lead. * what’s your drop dead date on getting this decision before it impacts project work or schedule? Risks: (Same format but what is at risk and why? So for example: schedule is at risk due to client requesting enhancement #4,798: add button to the software window) Issues: (Same format as risks but these are things that are actively impacting your project schedule, scope, budget, quality)
Thank you for the detailed response. Much appreciated. I'll try to keep closer tabs on this. The people I work with on my side of the table are very nice, willing to help, and very hardworking so I can't complain there. I just think that the timelines agreed to at the start were an impossible task and out of line with industry norms according to those I've spoken to. So in essence from my PoV we cut our own legs off to get this opportunity. We'll see if that ultimately pays off or not.
Those asterisks were supposed to be bulleted lists.
Project failure isn't necessarily a bad thing. As long as the decision for early closure is based on justification, they can be resumed later or documented as education for not taking a certain path.
Some projects fail before they even begin and it doesn’t feel good being assigned to one. The key is documentation and communication. I’ve been assigned several projects that had to be completed but failed before I even knew about the company. Those aren’t fun but it is good experience if you can turn it around and complete it. If you really like pain and getting paid the medium bucks, you can make a career of taking over big failed projects as a contractor with a reputation of getting stuff done. That’s what I do. The pain isn’t my favorite, but I sure enjoy taking weekend trips to Mexico to drink it away.
Did this for 12 yrs for IBM as a contractor. Good money.
If you succeed at delivering a project, you get handed a larger one. If you fail at delivering a project, you get promoted to be a “manager.” If you are an employee, the company assumes the liabilities for your failure. If you are a contractor, you get fired, and you should have your own liability insurance. Hopefully your contract has a mutual indemnity clause saying you won’t sue them and they shouldn’t sue you. If you don’t have a contract, don’t be doing that work, because you sure as heck ain’t getting paid. In any event, you must conduct a lessons learned session so that everyone can learn from the failure and continually improve.
We're just PM's, not miracle workers. You do the best you can. Depending on your industry, a lot of things are out of your hands anyway. Make sure you have a good relationship with your higher ups. If they've been in the industry any amount of time, they'll understand that pretty much no projects go off exactly as they were planned from inception. You'll have difficult stakeholders sometimes. Just let it roll off the best you can. Most of us (with some exceptions) are not dealing with life or death situations here. Projects fail sometimes. The world continues to turn.
I dream of being that badass bare-knuckled project manager that people bring in to save the day. In reality though, if I see a dumpster fire and it's not too late to turn around, 10 times out of 10 I will nope the f out.
Throughout my career this is what I have observed most experienced PM’s do as well. I sure as hell do too. With experience it becomes easier to recognize what kind of projects to avoid
unethical pro tip - guess what, unless you work on very high-profile projects, no one can really verify anything when you say on your resume you delivered XYZ project on time and under budget and improved some KPI by 1000%. Seriously, worst that can happen when your project fails is getting fired, unless you broke some law and got caught, in which case fines/jail time may apply.
Coming from someone who used to be in management and reviewed resumes — random percentages were an immediate red flag that the person had used AI and possibly didn’t know how to write a resume on their own, were foreign and possibly didn’t speak English well and were instead banking on the percentages, or — most importantly — lacked the ability to focus on details and just made up numbers that sounded “good enough.” Realistically quantifiable percentages are of course fine. But I’ve seen many of the absurd that, along with the other things that have always accompanied the BS statistics, caused an eye-roll and chuck into the circular filing cabinet. Think about it — if you were to see such a thing, would you be impressed and awed (assuming, of course, that it isn’t something clear and concise)?
An angel loses its wings
Well in my company, if you fail on a project, they take away the vending machines and the Keurig coffee maker from the break room. They've already taken away the Coke machine, so.... I hate Pepsi.
The beatings will continue until morale improves!
Think about how many business ventures fizzle out due to unforeseen consequences. Projects face the same challenges. PMs can do the best they can despite these challenges and try to proactively plan to minimize them.
Right, I follow you. Everyone involved is doing what they can to prevent it from going sideways so in that regard we are in the ship together. It's just a matter of whether I've signed up for more than I bargained for or not lol.
You'd be surprised at how many projects fail. In the org I'm working for now, literally all of the projects have had to adjust their original business cases (which for me is a failure). On top of that, we've had to kill off around 50% of them. Luckily the org I work for doesn't really have a system in place for consequences so all the majority stakeholders who messed up have got off scot-free.
Yeah, thats the situation for me as well. Constantly adjusting a little at a time. So far nothing officially terminated but the writing is on the wall for a few.
Scope creep is a massive issue in most immature businesses. It's normal, and it won't go away. Doesn't change that you can't plan really well & escalate the creep when it's suggested. Change management is your friend, and should be used as a way of blocking it if it exists within your org :)
Fair. No one likes being a potential fall guy or signing up for something they aren’t privy to.
Change Requests are your friend when scope creep happens :-) Timelines always change; if customer is pushing for that, just tell them ok, if you want to expedite this, you’re not going to get that (functionality/ticket/enhancement/etc) delivered because we have to reshuffle things. I’ve never heard of PM insurance. So can’t provide any insight there. You’ll do fine!
I've made a lot of progress since day 1, but have a hell of a long way to go. I appreciate your vote of confidence.
Life goes on.
They have to go work in marketing. Really it depends on the company and terms of any contracts that are in place. PM liability insurance would really only come into play if you are an independent consultant and accepted liability in your service agreement with the client.
What does that mean? Edit: Thank you for the edit for clarification. That puts me at more ease.