Project management is on the rise: in the US alone, there are almost a million such jobs, with a projected growth of 7% over the next decade and a median annual salary of more than $100K. In the tech industry, the figures are even more impressive: job numbers are expected to grow by 17%, and the median salary exceeds $171K per year. It’s no surprise that this profession keeps drawing people in. But newcomers, beware: project management is a demanding field that requires a specific skill set and cannot be fully mastered through textbooks or online courses. Real-world experience is the best teacher. Today, we explore some of the most serious mistakes a PM can make with Danila Vasilyev, Senior Project Manager at Broadridge. With 13 years in the international tech sector, he knows all the pitfalls and how to avoid them.
The advantages of a project manager’s job are clear: solid pay, strong career prospects, and the lifestyle that comes with both. But those benefits often come at the cost of mistakes and hard-earned lessons. So, what are the most common failures a PM can make?
The first that comes to mind is overreliance on formal procedures. Companies typically have well established processes, which can create the illusion that, if followed correctly, secure success. You might think you can sit back, relax, and enjoy the results. This is not true. You follow the process, the illusion of control takes hold, but in reality, certain elements fall through the cracks or remain incomplete. Unexpected problems arise and go unnoticed at the stage when they could have been resolved quickly and inexpensively. Instead, they are discovered too late, at a point when everyone is expecting the final results, and the outcome can be surprising in a negative way.
Although processes are essential, they don’t ensure success. That’s why any leader, especially a project manager, besides following the process should constantly question what’s going on, keep an eye on the progress, and talk to people involved to learn their concerns. They need not only to track whether the steps outlined in the plan are being executed, but make sure it’s done in a consistent and a reasonable way serving the project goal. It may sound obvious – even trivial – but year after year, project after project, in different companies, this same point is being lost. A fundamental trait of a good manager is to remain aware of this risk, continually double-check and question everything.
Processes only give you a framework, even if they are excellent and time-tested. No process can cover every possible scenario, none is that comprehensive. If a perfect process could exist, an algorithmic AI would already be doing a project manager’s job for years. Perhaps the new generation of AI will pose a challenge at some point, but the old one, which simply followed algorithms, certainly didn’t.
Here’s a real-life example. I took over a project from a seasoned manager who approached the project with a solid process and carefully tracked that all the check points outlined were followed. But he ignored people. He pushed hard to сomply with the metrics, generated reports demonstrating the progress, but never questioned and didn’t really talk properly to either the project team or the customer. Everything looked fine on paper… until development was complete and the solution passed over to user acceptance testing. Suddenly, it turned out that the users brought in to validate it were deeply dissatisfied. What they got was not meeting their expectations set before the project started and never revised. Their verdict was blunt: “What you’ve built is garbage. It’s just useless.”
He pointed to the documentation: everything had been done exactly as specified. But since the requirements had been gathered and signed off in a purely formal manner, it didn’t reflect the real user needs. That project manager pushed the team hard to sign off the documents on time rather than to consider their value. Then the team spent time and effort on implementation, but no one talked to future users, because why slow down the requirements approval. Unsurprisingly, the result was a disaster.
What could the manager have done differently? He could have spent less energy pushing to meet formal milestones and more time listening to people’s concerns and applying common sense to realize that requirements signed off under pressure are not equal to requirements truly heard.
That brings us to the question: who actually influences your project?
Exactly. This is the second trap a PM may fall into. Here’s another example: imagine a customer, a large company, with two departments: one is the Technical department and one is IT. A vendor wins the contract. Since it’s a software development project, it’s commissioned by the IT department, and the actual solution is going to be used by the Technical department, which had little involvement in the contract negotiations, but has its strong opinion. The vendor’s initial contacts are all from IT. The formal decision maker is IT. You work with them, deliver the project, it’s formally accepted, but the Tech department sidelined will likely ignore or undermine the solution in response. The door for future opportunities is closed.
The mistake? Not knowing your stakeholders. The solution? Get to know them. Understand their decision-making structure. There might be internal politics or competition between departments. There might be an in-house solution you compete with and you’d better know that to choose the right approach. Decisions are sometimes made by people who aren’t obviously in charge. The way to not only deliver the contracted scope, but also make it viable and establish a basis for future partnership, is to look beyond the formal agreements, understand the underlying needs, and recognize the influence of all actual stakeholders.
There are tools to help with this that any project manager knows: communication plans, responsibility matrices, stakeholder diagrams, and so on. But again, you can either use this toolkit formally or use it properly. If you take time to do the latter, these tools may reveal things that aren’t immediately obvious. Political awareness, informal feedback loop is a managerial skill in its own right and there’s no tool that can replace it.
Political awareness is certainly helpful for a PM, as they often find themselves caught between the customer and the vendor. Which side should they take?
Taking sides is, in fact, another common mistake. People naturally identify with whoever pays their salary. But som
etimes it’s driven by something like Stockholm syndrome. As a result, a project manager ends up aligning with one party, formally or emotionally. If they side with a vendor, they become overly protective of their team, treating every concession as a loss. If they side with a customer, they tend to become overly aggressive trying to get the most out of the other party. And while this feels natural and acceptable to a point it becomes a problem when it turns into a “zero-sum” mindset: the belief that the only way to gain something for your side is to take something away from the other. That’s a dangerous mental trap. Once someone slips into that mindset, they begin to emotionally reinforce it themselves.
There are so many examples, let’s pick the very simple one. A customer comes saying “We messed up: we didn’t manage to get our testing team together on time.” If the PM is stuck in that mindset, their response will be, “Great, we’ll document that the customer failed in their obligation,” compose a list of dependencies, justify the future delays and added costs, and feel satisfied. The PM’s team gets a breather, and probably more money. But is that really a win? It might feel like one but in reality, the project remains unfinished, future cooperation is in jeopardy.
My advice to a project manager in such situation: take a step back and take a fresh look. To ensure project success, you need to think of something the customer might not know or be experienced enough to consider. A better response could be: “Let’s revise the test plan to start with what your business users can test now,” or “Let’s start with testing technical components by our team,” or “Let’s rearrange the schedule, shift phases, reprioritize the test scenarios and overlap activities so we don’t fall behind.” Yes, it’s important to document the issues and have your counterpart sign it off, but at the same time, help them find a way forward.
If you approach it with a “win-win” mindset, if both sides support each other, the actual project budget will end up being lower, the timeline shorter. And with a reputation of a trusted and supportive partner, you will secure the next contracts for your company on better terms.
Is there any advice for newcomers to this profession on how to succeed and avoid all these pitfalls?
First, know the theory. It helps you understand all the range of tools available. You will never use the entire toolkit in every single project but you do need to know what’s out there.
Second: learn the case studies, read the books. Take the classic examples cited in introductory PM courses, like construction of the Empire State Building. Read how Valve developed their sort of teal organization to consider a completely different approach. Listen to the stories – among the co-workers, in biographies, interviews. Apply your imagination to consider non-work related events as someone’s projects, think of who was a project manager and what that person or organization did right or wrong. Be curious!
