Why Projects Go Wrong — And How to Fix Them

Textbooks vs. Reality

PMBOK and other textbooks provide useful guidance, but real projects rarely follow textbook rules. Every project, team, and stakeholder group is unique, so PMs naturally develop their own approaches to solving problems.

What makes projects challenging?

• Communication Issues: This one is tricky. It starts with not fully understanding the problem. You may be misled by different perspectives on the root cause, and information from stakeholders or the team may be incomplete or unclear.
• Team Resistance: Teams grow tired of constant change or experimenting with new approaches and tools, especially when past implementations were abandoned halfway through. Every new idea may be treated with suspicion.
• Stakeholder Disagreement: Different stakeholders have different — and sometimes conflicting — priorities. Without a clear process for resolving them, this easily leads to conflict.
• Constant Change: Priorities shift frequently. Without a backup plan, the team loses sync with the client, and work goes off track.

No matter the issue, identifying the real root cause matters more than rushing to fix the symptom.

Based on PMBOK and my own experience, the main problem in these projects is not execution — it’s sense-making. A PM’s job is to make daily actions meaningful and help teams and stakeholders share a common understanding of what they are trying to achieve. Simple in theory. Hard in practice. Essential either way.

Case 1: Team Pushback on New Initiatives

A couple of years ago, a client wanted to introduce AI to speed up delivery. The initiative was solid. However, during an open discussion with the team, we discovered that developers were not enthusiastic about the idea; they refused to use the suggested tools for coding.

So we listened. We let the team speak openly without reacting to what they said. As a facilitator, the goal is to stay neutral, take notes, and address each concern in the next iteration. Team members need to feel safe sharing their thoughts without fear of judgment.

Several factors were likely at play:

• Initiative Fatigue: Too many “improvements” had been introduced over time. The team wanted stability, not another disruption.
• Low Trust in Leadership Decisions: When a new idea comes from a client or a book without clear reasoning or context, the team may not see the value in it.
• Fear of Hidden Consequences: Being replaced by AI, or ending up with a more complicated workflow, were real concerns, even if unspoken.
• Resistance to Change: Sometimes people simply do not like changes to their routines. That’s human.

As a result of this discussion, we created a team agreement that included four concrete actions:

• Set a limit on the number of new initiatives introduced each year to prevent fatigue.
• Create a clear roadmap with milestones and measurable outcomes. We involved a technical lead to conduct a competitive analysis. After reviewing several tools, we selected Microsoft Copilot. A pilot group of five colleagues tested it for a month. We tracked results using labels, measuring both output and team sentiment.
• Train the team to support better adoption. Before starting the pilot, we held weekly sessions explaining how the tool works, how to install it, and which prompts to use.
• Make early wins visible. Showing results and marking each milestone helped the team see the value of the new tool.

By taking these steps, the resistance faded. The tool didn't just get rolled out — it was successfully adopted.

Case 2: Scope Creep as Small Changes

Imagine you are working with a client who owns flower shops in Kyiv, Paris, and Lisbon. Their core business is selling flowers, bouquets, and indoor plants. Now, they are planning to expand into a new city – London.

Your team has been engaged to create an online catalog showcasing a range of flower products for customers to browse and purchase. The project has a clearly defined goal, agreed scope, and set timeline. The key stakeholder – the business owner based in Lisbon – is also the budget holder, and all major agreements have been aligned with them.

There is, however, a second stakeholder: the person in London who will run the new shop locally.

Once the project kicks off, the London stakeholder starts pushing for a different vision. Not just flowers, but also pots, soil, and other gardening products.

That’s where the problems begin.

Issues:

• Stakeholders avoid prioritization and agreements. Different views are normal, but what is missing is clear communication and alignment on objectives within the client’s team.
• Fear of saying no. From our perspective, it is important not to accept every client request immediately. Instead, requests should be redirected to the person responsible for making the final decision about adding or removing them from scope. Sometimes stakeholders avoid making decisions and call it “collaboration.”
• No process for managing change requests. Clients may approach developers directly with new ideas, and developers may accept them because they want to be helpful.
• Lack of awareness of the cost of change. Small requests can quickly accumulate, increasing the cost and complexity of the originally agreed scope.

Solutions:

• A single prioritization point: Review new requests with the team and avoid promising anything to the client on the spot.
• Clear trade-offs: If something new is added, something else must move down the priority list. Make sure the client understands and agrees with the trade-off.
• A visible, ranked backlog: This becomes the “single source of truth” for what the team is working on. Share it with stakeholders and explain: “We can add your request, but these are the current priorities.”
• Transparency about the cost of switching focus: Interrupting work in progress to start something new is expensive and slows the team down. It is usually better to complete the current task before shifting priorities.

Case 3: When Priorities Change Mid-Quarter

Think of a project that has successfully followed a structured quarterly planning approach for years. The team is now working on the priorities for the current quarter. The work has been analyzed, scoped, and developers have started working on the stories. Suddenly, a stakeholder contacts you to say the agreed priorities are no longer relevant, and the team needs to switch to completely new initiatives.

Issues:

• Strategic misalignment on the client side. A commitment made for the first quarter is pushed aside halfway through, even after significant analysis and some development work have already been completed.
• Shifting focus for the development team. The team’s work is abruptly paused, and their efforts must be redirected to different initiatives.
• No accounting for the cost of the change. Even when priorities must change, the cost of doing so should be considered in the decision-making process.

Solutions:

• Understand the context before reacting. Before responding to the change, make sure you fully understand the reason behind the new priorities. Sometimes a shift is driven by market changes, regulatory pressure, or strategic decisions at the leadership level. Understanding the broader context helps the team accept the change and respond appropriately.
• Logically complete ongoing tasks. Abruptly stopping work mid-task can create unnecessary waste and reduce team motivation, so make sure the work is logically paused and documented.
• Always have a plan B. In dynamic environments, priorities may change unexpectedly. Having alternative work prepared — such as backlog items that are already analyzed and ready to start — helps the team transition more smoothly.
• Explain the reasoning to the team. Sudden changes can create frustration or confusion. Open communication about the decision helps maintain trust and keeps the team aligned.
• Report regularly to all stakeholders. Frequent updates ensure that everyone stays informed about progress, risks, and potential changes. This reduces the likelihood of unexpected shifts later in the process. Clearly demonstrate what has already been completed, what is currently in progress, and the effort already invested.
• Run a post-mortem ceremony to capture lessons learned. After the situation is resolved, review what happened with the team and stakeholders. Identify what could be improved in planning, communication, or decision-making to avoid similar situations in the future.

Conclusion

There is no universal solution to project challenges. Every project is different, and the approach you take will depend on your experience and how you have handled similar situations in the past.

That said, strong PMs should focus on a few key principles:

• Reducing cognitive load by minimizing noise and uncertainty for the team.
• Building trust with both the team and stakeholders.
• Creating clarity so everyone understands what we are doing and why it matters.

PMBOK puts it plainly: Build a culture of accountability and respect. Leadership is not command-and-control; it is about enabling performance.

It sounds straightforward. But in practice, these are exactly the things that separate teams that struggle from teams that deliver.