Most project management mistakes fall into three groups: career mistakes (how you grow as a PM), work mistakes (how you handle people and communication) and technical mistakes (planning, risk and change control). The technical ones are the easiest to spot and fix. The people mistakes do the most damage: poor communication, ignored stakeholders, problems hidden too long. Each mistake below comes with a simple fix you can start this week.
Knowing the right thing and doing it under pressure are two different skills. Most PMs could pass a test on stakeholder engagement, risk and change control. Far fewer do it every week when the sponsor is difficult, the client is pushing and the team is already stretched.
I have seen every mistake on this list, on real projects and in the PMP students I coach. Some of them I made myself. They are grouped in three categories because the fix for a career mistake looks very different from the fix for a planning mistake. Read each one honestly and ask where you sit today.
This page is a practical list of mistakes I have seen on real projects and in my PMP classes, each with a fix you can use. It is not theory: every item comes with what to do differently on Monday morning.
Many aspiring PMs think certification should wait until they have "enough" experience, or until the project calms down. The project never calms down. A certification does not just confirm what you already know. It often opens the door to the bigger projects that give you the experience.
Many job adverts list a certification such as the PMP, PRINCE2 or APM PMQ as required or preferred, and online screening often filters on it. If you wait until you feel ready, you may never get past the first shortlist.
Project management has professional bodies (PMI worldwide, APM in the UK), a body of knowledge, competence frameworks and CPD. APM even offers Chartered Project Professional status. If you treat PM as "turn up, deliver, go home", you miss all of that.
The cost shows up slowly. Agile, hybrid delivery and AI tools have changed the job in only a few years. The PM who stopped learning does not notice on any single day, but after a few years the gap is wide.
Most PM CVs list what was delivered: "Managed an ERP rollout. Led a team of 12. Delivered on time." That is output. Hiring managers want the outcome: what changed for the business because of your project? A CV with only delivery lines reads like a coordinator's CV.
Moving from output thinking to outcome thinking is also the move from junior to senior PM. Senior PMs see a project as a way to deliver business change, not a list of tasks.
Sending a status report is not the same as managing a stakeholder. A report shares information. Managing a stakeholder means knowing what they really care about, what they will not say in a formal meeting and what pressure they are under. Many PMs do the first and think they have done the second.
Projects fail because of people far more often than because of the schedule. A sponsor who quietly loses interest, a business owner who resists the change, a sceptic who raises doubts at board level: these rarely sit in the risk register, but each one can sink a project that is technically on track.
New PMs often think escalation means failure. They try to solve everything inside the team and only escalate when it is already a crisis. That is backwards. Sponsors and project boards exist to make the decisions that are above the PM's authority.
The PM who escalates a resource clash early, before it hits the critical path, is doing the job right. The PM who hides it, improvises and then delivers late has managed badly, however hard they worked.
Project management creates a lot of activity: meetings, emails, updates, reports. You can fill every hour with it and still not move the project forward. The PM who chases every action and attends every meeting often produces the most admin and the least value.
The useful question is not "what did I do today?" but "what moved the project forward today?" Each week you should be able to name the two or three things that mattered: a decision that unblocked the team, a conversation that settled a stakeholder, a risk you closed. If you cannot name them, you were busy, not effective.
Every project sits inside an organisation with its own history, rivalries, budget pressures and personal agendas. PMs who ignore this and expect the project to succeed on its merits are often surprised by opposition they never saw coming. A perfect plan can still fail at the first gate review.
Reading the politics is not being cynical. It is part of the job. Why is this director resisting? What happened last time these two departments worked together? Who influences the decision makers behind the scenes? These answers decide whether your project gets support.
Many project plans are optimism documents. They show the tasks, links and milestones, and assume it will all go to plan. It never does. A risk register full of red, amber and green ratings that nobody acts on is paperwork, not risk management.
Good risk management asks two questions: "Which risks would really hurt this project?" and "What have we done about them already?" Two projects can hit the same setback. The one that recovers is usually the one that thought about it in advance.
Scope creep is rarely sudden. It builds up through many small, reasonable-sounding requests: "It is only a couple of days of work." "The business really needs this." "It was always implied." Each one feels minor. Together they add weeks and cost that nobody approved or funded.
Saying yes to small changes without change control is not being helpful. You are spending future time and money without authority. Change control is not bureaucracy. It keeps the business case valid and shows the sponsor what they are really agreeing to.
Closing is usually the most rushed part of a project. The team is moving on, the business is focused on handover, and the PM is already thinking about the next job. Lessons learned get cut short, skipped or turned into a list nobody reads. Over a career, this becomes very expensive.
The PM who closes every project with a proper lessons learned session (what worked, what did not, what to change next time) builds knowledge that makes every later project easier. The PM who skips it keeps meeting the same problems on different projects and never quite knows why.
Mistakes I see most in PMP students
Students make their own set of mistakes, and they show up both in exam answers and in their first PM roles:
- Escalating too early on the exam. In situational questions, the PM should first assess the situation and act within their own authority. Going straight to the sponsor is usually wrong. Fix: ask "what can I do first?"
- Choosing the predictive answer in an agile scenario. A change request form is rarely the right answer for an agile team. Fix: check the delivery approach in the question before you answer.
- Memorising instead of understanding. The current exam is built on scenarios, not definitions. Fix: for every concept, ask "when would I use this on a real project?"
- Treating the plan as fixed once approved. On real projects, the plan is a living document. Fix: review risks and the schedule on a regular rhythm, not only when things go wrong.
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 |
Project management mistakes: common questions
What is the most common mistake new project managers make?
Saying yes to every request. Without a clear change process, small additions pile up into scope creep that breaks the schedule and budget.
Why do most projects fail?
Most projects fail for people and communication reasons rather than technical ones: unclear objectives, weak sponsor support and stakeholders who were not kept informed.
How can a project manager avoid scope creep?
Agree the scope in writing, route every change through a change request, and show the cost and time impact before anything is approved.
Should project managers admit mistakes to stakeholders?
Yes, early and with a recovery plan. Hiding a problem almost always makes it more expensive to fix and damages trust.
Build the Skills That Prevent These Mistakes
Certification gives you the knowledge base that helps you avoid many of these mistakes. The PMP and APM PMQ are two of the most respected credentials. See which one fits your stage and sector.
