Skip to content

Kevin McGowan

Writer | Speaker | Project Leader

Menu
  • Kevin Who?
  • Project Management Blog
  • Music Blog
Menu

That Which Should Not Have Been

Posted on February 1, 2026 by Kevin

When reflecting back on some rougher projects I’ve seen over the years, it’s easy to blame a Project Manager, or a team or an organization when things go wrong. But ultimately, it’s none of those. Sometimes, it’s a simple lack of process that can send a team or a project into a painful death spiral. 

I can only speak from my own experiences, of course. But I’ve been around long enough, and spoken to enough peers in my network, to know that the patterns I’ve seen are not unique. They recur with remarkable consistency. Not everywhere, and not always. But often enough that they’re worth naming. 

Today, I’m thinking about my experience in the non-profit sector in particular, though I’ve seen similar issues in technology industries. No, this isn’t an attack on non-profits. Quite the opposite. I care deeply about the sector. I’ve worked alongside people who are mission-driven, underpaid, overextended, and still show up every day trying to make the world marginally better than they found it. That context matters.

But good intentions do not inoculate organizations against chaos. In some cases, they actively enable it.

One particular example came back to mind recently. A real-life scenario, with names and details changed to protect the innocent ( and, frankly, the embarrassed).

This is the tale of the Guidebook. Ironically, a project that needed a guide of its own.

The Birth of an Idea (and the Immediate Abdication of Responsibility)

The organization in question had many stakeholders. Internal ones, external ones, funders, partners, advisory groups, all with overlapping interests and varying degrees of influence. As is often the case, a significant amount of leadership energy was spent attempting to keep everyone reasonably happy.

In that environment, ideas floated in constantly. Some were thoughtful. Some were half-formed. Some were little more than “wouldn’t it be nice if…” statements lobbed into meetings and never interrogated again.

The Guidebook began its life as one of those.

A stakeholder suggested that creating a guidebook would be a great idea. Someone else (well-meaning, helpful, eager) said, “Yes, let’s do it.” And just like that, the idea crossed an invisible threshold. It was no longer a suggestion. It was a project.

No one quite noticed this moment, which is part of the problem.

The project was “approved.” It was “resourced.” And by resourced, I mean it was placed on the edge of a few interns’ desks, each of whom already had higher-priority, clearly defined work that actually mattered to someone.

The Guidebook began its long, unglamorous journey: desk to desk, intern to intern, quietly accumulating dust. It was nobody’s job, no one’s responsibility, and therefore no one’s problem — until it was.

Fourteen Months Later

The Guidebook landed on my desk after approximately fourteen months of flailing.

At first glance, it looked like something had happened. Writers had been identified. A table of contents existed. A contract for writing and editing had been signed. Money had changed hands. Emails had presumably been sent.

But when I started asking basic questions (the kind that feel rude only because no one asked them earlier) the whole thing collapsed into fog.

There was no historical documentation. No project charter. No decision log. No emails explaining why this existed, who it was for, or what problem it was meant to solve. No meeting minutes. Not even a tentative publication date.

When I asked who was running the project, I was told, “You are now.”

That is a sentence I’ve heard more than once in my career, and it has never preceded good news.

I went back to anyone who had previously touched the file. The origins of the project were lost somewhere between staff turnover, reorganizations, and the quiet disappearance of institutional memory. A few key people were no longer with the organization. Others vaguely remembered “something about a guide,” but not enough to be useful.

Meanwhile, authors were emailing asking when they would be paid. They had submitted chapters. No one had reviewed them. No feedback had been given. One chapter, inexplicably, had already been sent out for professional layout and editing, despite the fact that no other chapters were complete, and no one could articulate what the final product was supposed to be.

Money had been spent. Time had been spent. Credibility had been quietly eroded.

At some point, I reached out to the original stakeholder (awkwardly, sheepishly) fourteen months after the initial conversation.

They had no idea what I was talking about. No recollection. My God, what had we been working on?

How This Happens (Because It Happens a Lot)

This is where it’s tempting to blame incompetence, laziness, or bureaucracy. But that’s too easy, and mostly wrong.

What actually happened here was far more mundane.

No one wanted to say no.

Non-profits are particularly vulnerable to this. Stakeholders are often donors, partners, board members, or influential advocates. Ideas come wrapped in good intentions and moral weight. Declining them can feel like rejecting the mission itself, rather than a specific execution of it.

So instead of a clear “this doesn’t align with our goals right now,” the organization offered a soft yes. A polite yes. A yes that was really “maybe later,” but without the courage to say so explicitly.

And once something has been “yes’d” into existence, it gains momentum simply by occupying space. It becomes harder to kill the longer it lingers, even as it fails quietly in the background.

Add to this a culture where documentation is treated as optional, where ownership is fluid, and where projects are handed off rather than deliberately transferred, and you get exactly this outcome.

No villain. No mastermind. Just entropy.

The Project Management Lens (Without the Jargon)

This is the part where a project manager is supposed to swoop in with a framework, a template, and a tidy resolution.

But the truth is less exciting.

A competent PM approach would not have “saved” the Guidebook. It would have prevented it from ever existing.

Step one would have been integration management. Though I hesitate to use the term because it sounds more impressive than it is. In plain language: someone should have asked, early on, whether this thing made sense at all.

A simple project charter (even a single page) would have forced a few uncomfortable but necessary conversations:

  • What problem are we trying to solve?
  • Who is this for?
  • How does it support our strategic goals?
  • What resources do we actually have?
  • Who owns this, end to end?
  • What happens if we don’t do it?

The answers, in this case, would have been deeply inconvenient.

It didn’t align cleanly with organizational priorities. There was no clear audience. There was no capacity to manage it properly. The expertise required didn’t exist internally. And the opportunity cost (the work that wouldn’t get done if this proceeded) was significant.

A mature response would have been a polite, professional no. “We’ve looked at the idea and don’t see it as feasible right now.”

That’s it. No drama. No apology tour. Just a simple chat would have made all the difference. .

Instead, someone felt beholden to a stakeholder. Someone mistook politeness for commitment. Someone didn’t want to be the person who shut down a “good idea.”

And so a throwaway comment metastasized into nearly two years of confusion, frustration, and quiet panic.

This Wasn’t a Process Failure. It Was a Communication Failure.

It’s tempting to frame this as a failure of process. And yes, the process would have helped. A project charter. A decision log. Clear ownership. Any one of those might have slowed things down enough for someone to notice the problem forming.

But none of those tools matter if people aren’t willing to say honest things out loud.

The real failure here was communication. Specifically, the refusal to communicate clearly at the moments when it mattered most.

No one said, “This doesn’t align with our priorities.”
No one said, “We don’t actually have capacity for this.”
No one said, “This idea is interesting, but we’re not the right organization to execute it.”

Instead, the organization offered a soft yes. A polite yes. A yes that was really “we’ll deal with this later,” which quietly turned into “we’re already dealing with this, whether we like it or not.”

That single moment (the failure to be honest with a stakeholder early) created nearly two years of downstream confusion.

Better communication would not have required heroics. It would not have required confrontation or conflict. It would have required a short, mildly uncomfortable conversation at the beginning, instead of dozens of awkward ones later.

What makes this especially frustrating is how common it is. Non-profits are full of people who care deeply about their work and the people connected to it. That care often shows up as accommodation or as flexibility, or as a reluctance to say no.

But clarity is kinder than politeness.

Clear communication would have protected the writers who were left waiting for feedback and payment. It would have protected staff who inherited a mess they didn’t create. It would have protected the organization’s credibility. It would even have protected the stakeholder, who was embarrassed to be asked about a project they barely remembered.

Instead, the lack of clarity allowed the project to exist in a strange limbo — approved but unsupported, resourced but unmanaged, alive but going nowhere.

The Guidebook didn’t fail because it was poorly executed. It failed because no one ever clearly articulated whether it should exist at all.

And that’s the real lesson of this case study.

Most organizational chaos doesn’t come from bad people or bad intentions. It comes from vague agreements, unspoken assumptions, and the collective hope that things will somehow sort themselves out.

They rarely do.

Sometimes the most valuable thing you can do for a project (and for the people around it) is to have one honest conversation early, and accept a small amount of discomfort in exchange for a great deal of avoided pain.

That conversation never happened here. And what followed was unnecessary, wasteful, and entirely predictable.

1 thought on “That Which Should Not Have Been”

  1. Monica Peck says:
    February 3, 2026 at 1:24 am

    Well said Kevin! Most project failures aren’t about effort—they’re about what wasn’t clearly said. If it doesn’t make sense, saying
    “This doesn’t align with our priorities.”
    “We don’t actually have capacity for this.”
    “This idea is interesting, but we’re not the right organization to execute it.”
    …are all great ways of saying No without using the word itself.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • Why I Got My PMP After Years of Figuring It Out
  • This CD Smells Like Bleach
  • Beyond Technical Expertise: Why Leadership and Adaptability Define Senior Project Managers
  • Choose Your Own Truth: Hendrix at Woodstock
  • That Which Should Not Have Been
  • LinkedIn
© 2026 Kevin McGowan | Powered by Minimalist Blog WordPress Theme