The Three Evils of Modern Project Management

May 06, 2026

The lie everyone agrees to

Every team in the world is running on a fiction. The fiction is called "the project plan."

Open any team's tool of choice and you will find the same artifact. A board, a backlog, a roadmap, a tidy hierarchy of tickets. Last updated three weeks ago. Smiling at you. Lying to your face.

The plan was true once. The day it was written. After that it began to drift, the way all plans drift. Tickets got moved, then forgotten. Status fields stopped getting clicked. The same comment got written in two places. Nothing was wrong, exactly. The team was just busy doing the work.

This is the central pathology of modern project management. Every PM tool ever built is a beautiful capture of intent. Almost none of them capture reality. The gap between those two grows every day a team is shipping.

We are not arguing this from theory. Spend an hour reading r/projectmanagement and you will see the same three complaints, in different costumes, on every page. I have no idea what my team is actually doing. Half my updates are in Slack and half are in Jira and the rest are in someone's head. Nobody updates the tickets because they're already in too many tools. The pattern is not subtle. It is the loudest signal coming out of the practitioner community right now.

We tend to talk about all of this as one problem. It isn't. It is three distinct failures, each one common enough on its own, all three reinforcing each other into a flywheel that has been spinning faster every quarter for twenty years.

The three evils of modern project management are these:

Visibility. Fragmentation. Switching.

A three-headed monster. Each head bites independently. None of them can be killed by another PM tool.

Evil #1: Visibility

The plan you wrote is not the work you're doing.

Open the PM tool of your choice. Look at it. Now ask the team what they are actually working on. Compare the two answers. The gap between them is the size of the problem.

This is not laziness, and it is not sloppiness. Every team is conscientious for the first two weeks of every cycle. Then execution kicks in. Meetings stack up. Real work gets in the way of cataloguing the work. By week four the PM tool reflects roughly what the team meant to do. The team is now doing something else.

The result is a class of question that managers ask all day, every day, and that no PM tool will answer:

Who is stuck right now?
What slipped this week?
Is anyone drowning?
Is anyone heads-down and shouldn't be interrupted?
What did we actually ship since Monday?

These are the questions that drive a team. They are not in the PM tool. They cannot be in the PM tool, because the PM tool is built around the plan, not the pulse. The plan is what you intend. The pulse is what's happening. Most days, what's happening is the only thing that matters, and the tool you've trained your team to live in has no opinion about it.

This is the difference between the battle plan and the battlefield. The PM tool is the battle plan. The team is on the battlefield. By the time anyone has time to update the plan, the battlefield has moved.

Evil #2: Fragmentation

The work is not in one place. And one of those places is invisible.

If visibility were the only problem, you could just be more diligent. Update the tool. Hold the line. Many companies have tried this. None have won.

The reason is the second evil. The work is not in one place. In fairness, it isn't in fifteen places either, the way some vendors will tell you. For most teams the work is scattered across three or four tools, five on a busy day. Slack, where the conversation lives. A drive of some kind, Google or Dropbox or SharePoint, where the files live. The PM tool itself, where the plan is supposed to live. The code repo, or for non-engineering teams a design file or a CRM. And almost always a slide deck somewhere, for the parts that had to be presented to someone.

Five tools is not fifteen. It is also not one. And there is now a sixth place no one is talking about yet, which deserves its own paragraph.

The decision your engineer made about the database schema. The customer email your sales rep refined for an hour. The marketing positioning your founder pressure-tested at midnight. Increasingly, all of this happens inside an AI chat session. Buried in someone's personal chat history, sitting somewhere between help me plan my anniversary dinner and explain Kubernetes to me like I'm five. This is the worst kind of fragmentation, because it is invisible even to the team that is doing the fragmenting. Slack and the drive can at least be searched by a teammate. An engineer's chat with Claude or ChatGPT cannot. The reasoning behind half the work your team is shipping this week is sitting in a personal context window no one else will ever see.

The PM tool was supposed to be the layer above all of this, the master ledger of what's happening. In practice it became one more place to forget to update, while a new place quietly got added to the stack every year.

Evil #3: Switching

The friction no one writes white papers about.

The third evil is the one that does the most damage and gets discussed the least.

Every PM tool in the world is built on a quiet assumption. The assumption is that the user will leave whatever they were doing, open the PM tool, find the right ticket, update its status, write a comment, and return. Many millions of dollars of UX investment have gone into making that round-trip take less than thirty seconds.

The user does not make the round trip.

Not because they're lazy, and not because thirty seconds is a lot. The user does not make the round trip because the user was doing something. They were in flow. They were in Figma, or in a Slack thread with a customer, or in a code review, or recording a Loom. The tool they were in was the right tool for what they were doing. Leaving it costs them context, focus, and the small but real social cost of switching tabs in front of someone they're talking to. Multiplied by twenty status updates a day, it is a tax the team will not pay. So they don't.

This is why teams love the tools they live in, even when those tools are wrong for the larger job. A salesperson will live in Slack and HubSpot all day rather than open a PM tool, because the PM tool is not where the customer is. A designer will leave a comment in Figma and never replicate it anywhere else, because the comment was about the pixels and the pixels are in Figma. An engineer will close a ticket in GitHub, write a note in Slack, and never touch the planning tool that the team agreed was supposed to be the source of truth.

The cost of the second hop is the difference between a complete record and a partial one. That cost is universally, predictably, silently paid by leaving the PM tool behind.

You can buy training. You can buy enforcement. You cannot buy your way out of switching cost.

The flywheel that spins the wrong way

Take any one of these three evils on its own and a sufficiently disciplined team can probably manage. Many do. The trouble is, the three evils don't appear alone. They reinforce each other into a flywheel, and the flywheel spins in the wrong direction.

Fragmentation creates switching cost. Switching cost erodes visibility. Lost visibility is patched by adding another tool. The new tool deepens fragmentation. Repeat.

The industry's standard response has been to add another layer on top. A "single source of truth." A "command center." An "operating system for work." Each of these is, in practice, one more tool the team has to remember to update. The proposed fix and the underlying disease are the same shape. This is why nothing sticks for long. This is why the average mid-size company has tried four PM tools in five years and is currently shopping for the fifth.

It is also why "team alignment" has become a permanent line item in every leadership offsite agenda. It is the symptom of the flywheel, not a separate concern.

A discipline, not a tool stack

Here is the part most people miss.

NASA put twelve humans on the moon between 1969 and 1972. They did it with paper. With typewriters. With hand-drawn PERT charts on plotting sheets. With clipboards. The Apollo program is widely considered the most complex coordinated engineering effort in human history, and it was project-managed on stationery.

General Dynamics built the F-16 between 1972 and 1978. They had access to mainframe computers and primitive electronic record keeping. Visicalc, the first commercial spreadsheet, did not ship until 1979. The most successful jet fighter of the late twentieth century was project-managed without spreadsheets.

A team today working with rigorous discipline and nothing but Google Docs and Sheets would outperform a team with no discipline and a five-figure annual PM tool stack. This is not a thought experiment. It is the lived experience of every veteran project manager who has ever joined a company that bought ClickUp and stayed dysfunctional anyway.

Project management is not a tooling problem. It is a coordination discipline, and the discipline is older than any product currently sold under the PM category. Apollo had the three evils. The F-16 program had the three evils. They were tamed with rigid document control, daily face-to-face standups, and a culture in which no one believed the schedule unless they had personally checked it that morning. The tools were less interesting than the practice.

What has changed since 1969 is not the underlying discipline. What has changed is that the tools have multiplied, and the multiplication has made the three evils sharper, not softer. There are more places to fragment work. More places to switch out of. More places where visibility quietly disappears into a personal channel, a DM, an AI chat. We have not gotten worse at project management. We have gotten worse at the conditions under which project management has to operate.

This matters for one reason. If the three evils are about discipline rather than tools, then the fix cannot be another PM tool built around plans. The fix has to be a PM tool built around the discipline itself.

Why every PM tool has failed at this

Here is what most teams do when the three evils start hurting. They go shopping.

They evaluate a new PM tool. They pick one. They migrate. They train the team. They write internal docs about the new way of working. For about six weeks, the new tool feels like a fresh start. Then visibility decays, fragmentation creeps back in, switching cost reasserts itself, and they end up exactly where they started.

The reason has nothing to do with the category. The reason is that every PM tool ever built was organized around the wrong thing. They were built around the plan: the backlog, the sprint, the roadmap, the ticket. The three evils were treated as user error, to be solved by better adoption, more discipline, an extra training session. They were never the design center.

So you don't get a PM tool that surfaces who is stuck. You get a PM tool with a "blocked" status field that nobody clicks. You don't get a PM tool that shows you who shipped what since Monday. You get a PM tool with a filter that returns the answer if you build it correctly. You don't get a PM tool that respects switching cost. You get a PM tool that asks the team to leave their day twenty times a day to update it, and then blames the team when they don't.

Meanwhile, Slack is not going anywhere. GitHub is not going anywhere. Notion, Figma, HubSpot, Intercom, Salesforce, the drive of your choice. None of these are going anywhere. They are all good at what they do. AI chat sessions are growing every quarter and will grow faster in the next two years than they have in the last ten. The fragmentation is permanent. The switching cost is structural. The visibility gap is the natural consequence of the first two.

What you need is not another PM tool built around the plan. What you need is a PM tool built around the three evils.

What "built around the three evils" actually means

A PM tool built around the three evils does not start with the backlog. It starts with the three questions every manager asks every day:

Who is stuck right now?
What slipped this week?
Is anyone drowning?

These are not features bolted onto a planning surface. They are the home screen. The first thing the team sees when they open it.

Visibility stops being a hoped-for byproduct. It becomes the product itself. Who's in, who's out, who's heads-down, who's blocked, what shipped, what slipped, all surfaced in real time, by default, without anyone having to remember to update something.

Fragmentation stops being a problem to consolidate away. The verticals stay where they are. Slack stays. GitHub stays. Figma stays. A PM tool built around the three evils accepts the world and pulls signal from it instead of trying to swallow it.

Switching cost stops being a tax the team is asked to pay. The inputs are tiny and frequent. A standup post is not a status meeting. A blocker flag is not a ticket update. The tool meets the team where their day already is.

That is what sparQ is. Same category as the PM tools you already know. Different organizing principle. Built around the three evils that every other tool in the category has spent twenty years pretending were a discipline problem.

The bottom line

Project management is not broken as a category. Project management is broken as a category that has been organized around plans for twenty years, while the actual job has always been about controlling the three evils that emerge between plan and execution.

NASA controlled them with discipline and paper. The F-16 program controlled them with discipline and primitive computing. Today's teams have to control them under messier conditions: a permanent multi-tool world in which Slack stays, GitHub stays, and AI chats grow.

The three evils, named:

Visibility. The plan is not the work.
Fragmentation. The work is scattered across half a dozen tools, including ones your team can't see into.
Switching. No one will leave the tool they're in to update a sixth one.

Each one is real. Each one has a cost. Together they form a three-headed monster that has been spinning the wrong direction for twenty years, and no PM tool built around the plan has slowed it down.

The fix is a PM tool built around all three.

About sparQ

sparQ is a project management tool built around visibility, fragmentation, and switching cost. Light on planning, heavy on current state. Built for small teams who are tired of pretending the plan and the work are the same thing.

Sign up at gosparq.com →