Owning Failure as a Project Manager

Just about every Project Manager has made mistakes at some point in their career. They may make a poor decision, miss signals, underestimate work, mishandle stakeholder relationships, or even watch a project drift away from what everyone expected without taking action fast enough. For the people doing the work, those mistakes have real consequences. They show up as shifting priorities, wasted effort, unclear direction, mounting pressure, and the frustration of trying to deliver against a plan that no longer reflects reality. Despite those consequences, a mistake does not automatically make someone an ineffective Project Manager. What matters is how the Project Manager responds once they recognize that something has gone wrong. This includes their ability to handle the pressure while making the adjustments necessary to move the project forward.

Another part of that response is taking the right amount of responsibility. A Project Manager can push responsibility onto the team, the client, leadership, or circumstances, but they can also claim responsibility for conditions they did not control and turn accountability into performative self-blame. Neither approach helps the people trying to get the work done. Meaningful accountability requires understanding what actually failed, identifying the Project Manager’s real contribution to it, responding while something can still be done, and changing the way similar situations are handled afterward. A project can eventually succeed and still contain serious management mistakes, just as a failed outcome does not mean every decision leading to it was wrong.

Owning The Mistake

Early in my Project Management career, I moved from work whose technical processes I knew extremely well into a much broader digital publishing program where I suddenly depended on disciplines I did not yet understand firsthand. Because I did not feel sufficiently knowledgeable, I became tentative about establishing delivery leadership, even though that responsibility was already mine. Nothing dramatic happened in a single moment, but things gradually began to unravel as the project progressed. My contribution to that was allowing uncertainty about the domain to weaken clarity around ownership and decision-making.

That experience shows why accountability starts with identifying the failure accurately. A missed deadline may trace back to an unrealistic estimate, a dependency that was recognized too late, a stakeholder decision that kept changing, or a forecast that should have been revised sooner. The Project Manager may have controlled some of those conditions, influenced others, and had no authority over the rest. Treating all of them as personal failure is no more useful to the team than blaming everyone else, because either approach obscures what actually needs to change.

That distinction matters especially when judging decisions after the outcome is known. A reasonable choice made with incomplete information can later prove wrong, while a bad result can expose an assumption or warning sign that should have been challenged earlier. The useful question is what the Project Manager knew at the time, what they reasonably could have known, and what they did as the evidence changed. When a forecast starts moving or a credible risk begins affecting the work, the people involved need that reality surfaced while there are still choices available, not after the original commitment has already become impossible to meet.

From there, the Project Manager has to decide what needs to happen next. That may mean replanning the work, reducing scope, simplifying the solution, securing additional resources, escalating an issue, or acknowledging that the original plan no longer makes sense. Limited authority may prevent a Project Manager from fixing the underlying problem personally, but it does not remove the responsibility to make the consequences and available options visible to the people who can. The harder test comes when the mistake was not primarily somebody else’s constraint but a judgment the Project Manager personally got wrong.

When Your Own Judgment Is the Problem

That was the kind of mistake I made on the large digital publishing program I had joined. It involved disciplines such as Business Analysis, Product, QA, and Architecture, along with engineers and outside vendors working on digitization, metadata, search, and ecommerce deliverables. A Business Analyst had effectively been keeping the work moving before I arrived. Because I was no longer working inside a domain I understood firsthand, I kept treating deeper knowledge of those disciplines as a prerequisite for confidently taking control of the delivery structure. The result was that I became too tentative and administrative at exactly the point when the people doing the work needed clearer project leadership, including clearer ownership and decision rights, along with stronger identification and management of risks and dependencies.

That experience changed how I think about expertise. A Project Manager needs enough understanding to ask good questions, recognize dependencies, challenge assumptions, and know when specialist judgment matters, but delivery leadership cannot wait until the PM becomes the deepest subject-matter expert in the room. On unfamiliar programs now, I establish how decisions will be made, who owns what, what could block the work, and where information needs to come from while learning the domain in parallel. Looking back, the real mistake was letting uncertainty make me hesitant about responsibilities I already owned.

“Every mistake should change something about how you manage once you understand what went wrong.”

A different early-career mistake exposed another kind of assumption. At an advertising agency where I worked, I was asked to lead an internal technical exploration for a smartphone camera-based effect tied to a major film opportunity, where a person’s face would visually transform into different characters. Comparable consumer face-filter functionality was not an established reference point for us at the time, and I assumed our developers had to create the solution from scratch with the resources already available. We kept working at the bespoke approach even though the results were not reaching the necessary visual quality. Because the proof-of-concept window was short, by the time a senior stakeholder on the opportunity pointed out an existing paid framework we could have explored, we had already lost too much time to deliver what was needed. He asked why I had not considered that route, and that exposed the assumption I had been making all along. I had never realized that using an outside framework, even an expensive one, was an option available to us. We ultimately missed the opportunity.

The important mistake there was treating an assumed constraint as though somebody had actually imposed it. I had carried assumptions from my previous, more constrained working environments into an agency that gave teams more room to explore outside tools, spending, and alternative approaches, but I never tested whether those options were available. That is a different form of underestimation, one that has less to do with the technical estimate than with failing to question what solutions were actually available. When an approach keeps producing unacceptable results, persistence alone stops being useful. The better question is whether the assumptions defining the approach are still valid.

When Stakeholder Behavior Starts Affecting the Team

Those examples are relatively clean because the mistake can be traced back to my own judgment. The harder ownership questions show up when the Project Manager did not create the original problem but still had responsibility for managing what happened next. On a branding and website build project I managed at a digital agency, repeated review and approval cycles gradually pushed the work away from the original plan. At one point, nearly all of the planned schedule had elapsed while only about two-fifths of the scope was complete, and substantial development still remained. The client’s delays and reopened decisions were real contributors, but once that pattern was visible, they also became a management problem I had to address.

The stakeholder dynamic made the situation much more difficult than a normal schedule variance. Direction the team believed had already been agreed would sometimes be reopened, contradicted, or treated as though it had never been settled at all. Work would be produced against an approved direction only for the team to be met with surprise or disagreement when it was presented back. That created repeated revisions, wasted effort, and growing frustration among the people doing the work. As the pattern continued, I could see the budget being consumed, the schedule slipping, and the scope continuing to shift away from what the team believed had already been agreed.

I remained personally unaffected by those interactions and kept focusing on scope, budget, schedule, and getting the work completed. But because I was not experiencing the stakeholder behavior with the same level of frustration as the team, I was slower to recognize how much the pattern itself was affecting the people doing the work and making the project harder to manage predictably.

Once it was clear that the original schedule and budget no longer matched the work that remained, I needed to take action to get the project back under control. I reforecasted the remaining work, tightened revision and change control, simplified parts of the implementation approach, and secured approval for additional project budget. We did not meet the original schedule, but the project was re-scoped and moved forward against a more realistic plan. Recovery meant replacing a baseline that no longer reflected the work rather than pretending the first commitment had somehow been preserved.

What I would handle differently now is how quickly I respond to the effect that kind of stakeholder behavior is having on the team. I corrected the mechanics of the project in terms of scope, schedule, and budget, but I was slower to recognize how much the repeated reversals were frustrating the people doing the work and making the client relationship harder for them to manage. That was the part I did not address well enough. Once a stakeholder pattern begins affecting team morale, confidence, and the team’s ability to work effectively, the Project Manager has to treat that as a problem in its own right rather than assuming the delivery mechanics are the only thing that need fixing.

Act While There Are Still Useful Choices

That is where accountability turns into action. Once a problem is visible, the first step is establishing what is actually happening before deciding how to respond, which means separating evidence from assumption, distinguishing personal responsibility from team or stakeholder actions, revisiting the information that supported the original plan, and paying attention to how the situation is affecting the people doing the work. An isolated problem may require a local correction, while a recurring pattern of slipping forecasts, reopened decisions, unstable expectations, unresolved dependencies, or growing frustration within the team usually points to something larger.

The earlier those patterns are recognized, the more options remain available. A Project Manager should keep watching for changes in schedule forecasts, estimation uncertainty, dependencies, stakeholder expectations, team conditions, and signs that frustration or uncertainty are beginning to affect how people are working. From there, the consequences should be made clear across scope, budget, quality, workload, timing, and the team’s ability to work effectively. That does not mean presenting every emerging risk as a confirmed failure. It means giving the people with the relevant authority enough information to decide while the project can still be changed.

“Meaningful accountability requires understanding what actually failed, identifying the Project Manager’s real contribution to it, responding while something can still be done, and changing the way similar situations are handled afterward.”

That is also why I now treat uncertainty differently than I did earlier in my career. On unfamiliar work, I no longer wait until I understand every discipline before establishing ownership, decision paths, risks, and the people I need information from. I also pay closer attention to how uncertainty is affecting the people doing the work, not just the plan itself. The same principle applies when a delivery baseline stops matching reality. On the branding project, continuing to manage against the original plan would have created less clarity, not more, so the work had to be reforecast, simplified, and escalated once the existing approach was no longer credible. 

Sometimes the appropriate response is a revised schedule. In other situations, it may mean reducing scope, changing the solution, securing more resources, escalating a decision, or acknowledging that the current plan should no longer be preserved. Project Managers do not always have the authority to make those choices themselves, but they are often responsible for showing what has changed, what the consequences are, and where a decision is now required. That also means considering how the situation is affecting the people doing the work. The real value of that response becomes clearer later, when you can see whether it actually improved how the next problem was recognized and managed.

Applying the Lessons You Learn

That is ultimately how I judge whether a lesson actually changed anything. The clearest evidence usually appears before the next failure happens, when forecasts get questioned earlier, uncertain estimates are treated as uncertain, dependencies receive attention sooner, and recurring stakeholder problems are recognized before they consume the schedule or exhaust the team. After the mistake I made on the publishing program, for example, I changed how I enter unfamiliar work. I now establish ownership, decision paths, risks, and sources of expertise while I am still learning the domain, rather than waiting until I feel fully knowledgeable enough to lead.

Project outcomes still matter, but they do not tell the whole story. On the branding project, we did not meet the original schedule, but once it became clear that the baseline no longer reflected the remaining work, I reforecasted the project, adjusted the plan, and moved forward against a more credible schedule. Missing the original commitment was a real variance that required correction, but replanning is also a normal part of managing projects when conditions materially change. The more important failure in my own management was recognizing too late that the recurring stakeholder dynamic itself had become a delivery and team-health risk that required stronger intervention. The useful measure is whether the problem was recognized, communicated while choices remained, corrected responsibly, and handled differently when a similar pattern appeared again.

What You Carry Forward

Project Managers are going to get things wrong. Sometimes the mistake will be obvious and entirely their own. Other times it will be mixed into bad assumptions, difficult stakeholders, changing conditions, or decisions made with incomplete information. What matters is being able to look at what happened clearly enough to understand your part in it without either avoiding responsibility or claiming more of it than belongs to you.

Every mistake should change something about how you manage once you understand what went wrong. I learned not to wait until I feel like the expert before taking leadership of the work. I learned to question assumptions about what options are actually available. And I learned that keeping a project moving is not enough if I am missing what the situation is doing to the people trying to deliver it.

I still do not expect to make every decision correctly. What I expect from myself is to recognize sooner when something is going wrong, understand my contribution to it, and be willing to change course when the evidence says I should. That, more than pretending mistakes can be eliminated entirely, is what I now think responsible Project Management looks like.