Only 35% of projects worldwide finish successfully, according to PMI’s 2025 Pulse of the Profession research. The remaining 65% either miss their deadlines, exceed their budgets, or fail to deliver what was promised. That number has barely moved in a decade.

The standard response is more methodology: adopt agile, get certified, buy better software. But after 20+ years in IT operations, running projects ranging from network rollouts to full platform migrations, I can tell you the methodology is rarely the problem. The problem is what happens (or doesn’t happen) in the first week of a project, in the daily communication rhythms, and in the moments when a manager has to make a call with incomplete information.

Project management for managers is not the same discipline as project management for dedicated project managers. You are not building Gantt charts full time. You are running a team, reporting to a boss, handling personnel issues, attending leadership meetings, and also trying to get a project across the finish line. That dual reality is where most project management advice falls apart.

Where Projects Actually Break

Harvard Business Review’s January 2026 issue featured Antonio Nieto-Rodriguez arguing that projects, not operations, are now the primary engines of value creation in organizations. He’s right. But that makes the failure rate even more alarming.

When I look back at the projects I’ve seen fail (and the ones that succeeded despite every reason not to), three patterns account for most of the damage.

Scope that was never actually defined. PMI reports that 55% of projects experience scope creep. But “scope creep” implies something that starts defined and gradually expands. In my experience, at least half of those cases never had clear scope in the first place. The project kicked off with enthusiasm and a vague objective, and every stakeholder filled in their own version of what “done” meant.

Communication that collapsed under load. PMI estimates that $75 million of every $1 billion spent on projects is at risk due to ineffective communication. That number sounds abstract until you’ve been the manager who found out about a three-week delay from a different department’s status email.

Dependencies nobody tracked. Cross-team dependencies are the operational drag that nobody measures until it’s too late. A project can have a perfect internal plan and still fail because it depends on another team’s deliverable that was never formally committed.

Scoping Is a Leadership Act

The most underrated project management skill is the willingness to say “this is what we’re building, this is what we’re not building” and get explicit agreement from the people who will later want to change it.

Scope definition is not a planning exercise. It’s a leadership act. It requires you to push back on ambiguity, force specificity from stakeholders who prefer to stay vague, and make tradeoffs visible before the work begins.

During a platform migration early in my career, we lost three weeks because two directors had completely different definitions of “complete.” One expected a full data migration with historical records. The other expected a clean cutover with an archive accessible separately. Both were reasonable. Neither had been made explicit. That project taught me that the 30 minutes you spend writing exclusions saves weeks of conflict later.

Here’s what effective scope definition looks like in practice. Write down the deliverables in specific, observable terms. “Improve the onboarding experience” is not scope. “Redesign the first-week orientation schedule, create three new training modules, and reduce time to productivity from 90 days to 60 days” is scope. Then write the exclusions: what you are explicitly not doing. This is the part most managers skip, and it’s the part that prevents most scope arguments later.

Get sign-off before any work starts. Not informal agreement in a hallway conversation. Written confirmation from the people who have authority to change the scope later. This creates accountability that holds under pressure.

The Communication Problem

Twenty-nine percent of project failures trace directly back to poor communication and collaboration, according to PMI research. That makes communication the second most common cause of project failure after unclear objectives.

Most managers understand that communication matters. Fewer understand what project communication actually requires. It’s not sending more emails. It’s building a predictable rhythm that surfaces problems before they become crises.

The weekly status update is the minimum viable communication tool for any project longer than two weeks. Keep it simple: what did we accomplish this week, what’s planned for next week, what’s blocked, what risks have emerged. Send it on the same day at the same time to the same list.

That rhythm accomplishes two things. First, it forces you to synthesize progress, which catches drift early. Second, it builds trust with stakeholders, because people who are kept informed don’t fill the silence with worst-case assumptions.

For projects that span multiple teams, add a brief dependency check-in to your weekly rhythm. Fifteen minutes. Which handoffs are on track? Which are slipping? What needs escalation? This single practice would prevent a significant share of the cross-team failures I’ve seen over two decades in operations leadership.

Methodology Is a Tool, Not a Religion

PMI’s 2025 Pulse report shows hybrid project delivery approaches have grown 57% in a single year. Agile adoption in software teams sits at 94%. McKinsey found that projects using agile principles improve delivery speed by 20 to 30%.

These numbers paint a picture of an industry moving toward flexibility, which is the right instinct. But managers often get trapped in methodology debates when the real question is simpler: do you have a consistent process for starting, running, and finishing work?

Waterfall works when requirements are stable and well understood, dependencies are linear, and the cost of rework is high. Infrastructure projects, compliance implementations, and physical builds often fit this model.

Agile works when requirements will evolve based on feedback, the work can be delivered incrementally, and speed of learning matters more than upfront certainty. Product development, process improvement experiments, and customer-facing projects often benefit from iteration.

Hybrid approaches (waterfall planning for the overall arc, agile iteration within each phase) are what most managers actually end up doing, whether they call it that or not. The PMI data confirms this is now the dominant delivery model.

The methodology matters less than whether you actually follow it. The manager who runs a simple, consistent process (weekly check-ins, clear task ownership, documented decisions, regular retrospectives) will outperform the manager who selected the “right” methodology but executes it inconsistently.

Remote and Distributed Projects

Gallup’s 2026 data shows that manager engagement has dropped nine percentage points since 2022, with the average number of direct reports climbing from 10.9 to 12.1. Managers are overloaded, and many of their projects now span teams that don’t share an office.

Running projects across distributed teams changes the coordination model. Three adjustments make the biggest difference.

Default to written artifacts over verbal agreements. In a co-located team, you can align on scope in a hallway. Distributed teams need written scope documents, decision logs, and status updates because there is no ambient information flow. What feels like overhead in an office is infrastructure when your team is spread across time zones.

Shorten the feedback loop. When you can’t see the work happening, you need earlier signals that things are on or off track. Move from weekly to mid-week check-ins if the project is moving fast. Use asynchronous standup formats (a shared document or channel post with three prompts: done, doing, blocked) to maintain visibility without adding another meeting to an already crowded calendar.

Over-invest in kickoffs. The project kickoff is more important for remote teams than for co-located ones. When people won’t bump into each other at the coffee machine, the kickoff is your chance to build shared understanding of scope, roles, decision authority, and communication norms. Spend twice the time you think you need.

When Projects Go Sideways

McKinsey’s research on large IT projects found that projects over $15 million run an average of 45% over budget and 7% over time while delivering 56% less value than predicted. Smaller projects perform better, but no project is immune to going off track.

The manager’s job when a project goes sideways is diagnosis before intervention. Too many managers jump straight to solutions (extend the deadline, add people, cut features) without understanding why the project is off track.

Three diagnostic questions clarify most situations.

Is this a scope problem? Did the work grow beyond what was planned? If yes, the conversation is about prioritization and tradeoffs, not about working harder.

Is this a capacity problem? Does the team have too much work for the time available? If yes, you need to either reduce scope, extend the timeline, or redistribute work. Adding people to a late project almost always makes it later. Brooks’s Law remains as true as when Fred Brooks wrote it in 1975.

Is this a dependency problem? Is the team waiting on someone or something outside their control? If yes, the fix is escalation and negotiation, not internal optimization.

The worst response to a troubled project is silence. Surface the problem early, present the diagnosis and your recommended path, and let stakeholders make informed tradeoffs. Managers who hide problems until they become crises destroy their credibility. Managers who surface problems early and propose solutions build it.

The Compound Effect of Learning From Every Project

The Standish Group’s CHAOS data shows that high-performing organizations complete 89% of their projects successfully, compared to 34% for underperformers. That gap doesn’t come from better tools or bigger budgets. It comes from organizations that systematically learn from their project experience.

The after-action review (or retrospective, or post-mortem, whatever your organization calls it) is the single most underused practice in management. It takes 30 to 60 minutes. It answers four questions: what did we plan to do, what actually happened, why was there a difference, and what will we do differently next time?

Most managers skip it because the project is over and the next one is already starting. That’s exactly the pattern that keeps teams at 34% instead of 89%.

Run the retrospective within a week of project completion. Document three specific changes (not aspirational goals, specific process changes). Follow through on at least one of them in the next project. Over time, this practice builds a team that gets measurably better at delivering work without rework, not because they adopted a new methodology, but because they stopped making the same mistakes twice.

The difference between managers who consistently ship and managers who consistently spin is not talent or training. It’s whether they built the discipline of scoping clearly, communicating proactively, diagnosing problems honestly, and learning from every project they close.