Project managers — aspiring and experienced alike — tend to fail in one of three areas: career mistakes (how they manage their professional trajectory), work mistakes (how they manage relationships and communication on the project), and technical mistakes (how they handle the mechanics of planning, risk and control). The most damaging mistakes are rarely the technical ones. Most failed projects fail for people and career reasons — poor communication, misread politics, ignored stakeholders and stalled professional development. The technical errors are easier to spot and fix. The people errors are the ones that end careers.
Project management is one of those professions where the gap between knowing what to do and actually doing it under pressure is enormous. Most PMs could pass a written test on stakeholder communication, risk management and change control. Far fewer apply those principles consistently when a project is in crisis, when a sponsor is difficult, or when the team is already stretched thin.
The ten mistakes below are drawn from the patterns that separate PMs who advance steadily from those who plateau — or derail. They are organised into three categories because the fix for a career mistake looks different from the fix for a planning error. Read each category honestly and ask where you currently sit.
One of the most common patterns among aspiring PMs is the belief that certification should come after sufficient experience — once you know enough, once the project calms down, once things are less busy. This thinking inverts the actual relationship between certification and career progression. Professional certification does not validate experience you already have; it opens doors to the experience you have not yet had.
In the UK job market, PMs without APM PMQ or PRINCE2 Practitioner are increasingly excluded from shortlists for senior roles — not because they lack ability but because automated screening and job requirements filter them out. In international markets, the same applies to PMP. The PM who waits until they are ready is waiting for a door that requires a key to open in the first place.
Project management has a chartered professional body in the UK (APM), a global professional institute (PMI), published competency frameworks, a body of knowledge, CPD requirements and career pathways that lead all the way to Chartered Project Professional status. PMs who treat their role as a job — showing up, delivering the project, going home — miss the professional development layer entirely.
The consequences are slow and invisible until they are not: the PM who has not kept up with how the profession is evolving (Agile integration, AI tools, hybrid delivery, sustainability in PM) finds themselves at a disadvantage not in a single moment but progressively over several years. By the time they notice, the gap is wide.
Most PM CVs list the projects managed: "Managed a £2M ERP implementation. Led a team of 12. Delivered on time." This is the output. What experienced hiring managers actually want to know is the outcome: what changed because of this project? What business value was delivered? What problem was solved? A CV full of delivery descriptions and empty of business outcomes signals a coordinator, not a strategic PM.
The shift from output-thinking to outcome-thinking is also the shift from junior PM to senior PM. PMs who manage projects as a series of tasks to complete, rather than as a mechanism for delivering business change, rarely progress beyond mid-level roles.
There is a meaningful difference between sending a status report and managing a stakeholder. Sending a status report is information distribution. Managing a stakeholder is understanding what they actually care about, what concerns they are not expressing in formal meetings, what political dynamics are affecting their support for the project, and proactively addressing those realities. Many PMs do the former and assume they have done the latter.
Projects fail because of stakeholder dynamics far more often than they fail because of schedule slippage. A powerful sponsor who withdraws support, a resistant business owner who undermines adoption, a silent sceptic who raises doubts at board level — none of these risks appear in a risk register, but all of them can kill a project that is technically on track.
New PMs often confuse escalation with failure. They believe that raising a problem to a sponsor or steering group signals that they cannot handle their project — so they absorb issues, attempt to resolve everything within the team, and escalate only when something is already a crisis. This is exactly backwards. Escalation is not a failure mode. It is the mechanism by which project governance works. Project boards and sponsors exist specifically to make decisions that are beyond the PM's authority to resolve alone.
The PM who escalates a resource conflict early, before it affects the critical path, is doing their job correctly. The PM who absorbs it, improvises a workaround and eventually delivers late is managing poorly — regardless of how hard they worked.
Project management generates an enormous volume of activity — meetings, emails, updates, reviews, reports. It is entirely possible to spend every hour of the working day on project activity and make no meaningful progress on the actual project. PMs who mistake busyness for productivity — who fill diaries with status calls, chase every action, attend every meeting — often produce the most administrative output and the least strategic value.
The question that separates effective PMs from busy ones is not "what did I do today?" but "what moved the project forward today?" Every week, the PM should be able to identify the two or three things that actually mattered — the decision that unblocked delivery, the conversation that resolved a stakeholder concern, the risk that was mitigated. If you cannot identify them, you have been busy rather than effective.
Every project operates inside an organisational context with history, competing interests, departmental rivalries, budget pressures and personal agendas. PMs who treat this context as irrelevant — who believe the project should stand or fall on its merits alone — regularly find themselves blindsided by opposition they did not see coming. The technically perfect project plan, presented to a steering group with unresolved political undercurrents, can fail at the first gate review.
Reading organisational politics is not cynicism. It is professional intelligence. Understanding why a particular director is resistant to a change, what the history is between two departments whose cooperation the project needs, and who has informal influence over the formal decision-makers — this knowledge directly affects whether the project succeeds.
Most project plans are optimism documents. They show the sequence of tasks, the dependencies, the milestones — and they assume that things will broadly go as planned. They do not. Every project encounters unexpected events, and the plans that fail catastrophically are usually those where no thought was given to what happens when they do. Risk management that produces a list of risks with RAG ratings is not risk management. It is administrative compliance.
Effective risk management asks: "Which of these risks, if they materialise, would genuinely threaten the project?" and "What have we done in advance to reduce the probability or impact of those threats?" The difference between a project that absorbs a significant setback and recovers and one that collapses under the same setback is almost always the quality of advance risk thinking.
Scope creep is almost never sudden. It accumulates through dozens of small, seemingly reasonable accommodations: "It would only take a couple of days to add that feature." "The business really needs this — let's just include it." "It was always implied in the requirements." Each individual change feels minor and manageable. Collectively, they add weeks to the schedule, thousands to the budget and significant complexity to delivery — none of which was approved or resourced.
The PM who says yes to small changes without a change control process is not being helpful. They are borrowing time and money from future stages without authority. The formal change control process is not bureaucracy — it is the mechanism that makes the business case remain valid and gives the project board visibility of what they are actually authorising.
The closing stage of a project is almost always the most compressed and most neglected. The team is being redeployed, the business is focused on transition, and the PM is already thinking about the next project. Lessons learned sessions get shortened, skipped or reduced to a perfunctory list that no one reads. This is one of the most expensive mistakes in project management — not immediately, but compounded across a career.
The PM who consistently closes projects with structured lessons learned — identifying what worked, what did not, what would be done differently, and why — builds a personal and organisational knowledge base that directly improves future project performance. The PM who does not makes the same mistakes repeatedly across different projects and different organisations, never quite understanding why similar issues keep arising.
The 10 Mistakes at a Glance
| # | Mistake | Category | Core Fix |
|---|---|---|---|
| 01 | Waiting to get certified | Career | Set a 12-month certification target now |
| 02 | Treating PM as a job not a profession | Career | Join APM or PMI. Track CPD actively. |
| 03 | CV of deliveries, not outcomes | Career | Rewrite in business outcome language |
| 04 | Status reports instead of stakeholder management | Work | Manage relationships, not just communications |
| 05 | Absorbing problems instead of escalating | Work | Define escalation thresholds at initiation |
| 06 | Confusing busy with progress | Work | Identify 3 priority actions at the start of each week |
| 07 | Ignoring organisational politics | Work | Map informal influence, not just formal hierarchy |
| 08 | Planning without real risk thinking | Technical | Identify the 3 risks that could kill the project |
| 09 | Allowing scope creep | Technical | Apply change control to every change, however small |
| 10 | Skipping lessons learned | Technical | Schedule lessons learned as non-negotiable at close |
Build the Skills That Prevent These Mistakes
Certification builds the knowledge foundation. The PMP and APM PMQ are the two most respected credentials for UK project managers — see which is right for your stage and sector.