How to Track Project Decisions So Nothing Gets Lost

I once spent the better part of a Tuesday morning trying to remember why we'd killed a feature.

Not whether we'd killed it. That part was clear. The thing was gone, the tickets were closed, and the team had moved on. What I couldn't recall was the reasoning. Was it a cost call? Was it a major technical blocker? A timeline call? Did a customer tell us they didn't want it, or did we just assume? Three people had been in that meeting. We got three different versions of the story, and all of them sounded plausible.

That morning cost us about two hours and ended with a shrug. A month later it cost us a lot more, because we re-litigated the entire thing from scratch and landed right back where we started. The decision was never lost in some dramatic way. Nobody deleted it. It just quietly evaporated, the way most decisions do, into the gap between what got said and what got written down.

If you manage projects, you know this feeling. But here's the thing I've come to believe after years of it: losing the record of a decision is only half the problem. The bigger half is that almost nobody is paying attention to how their decisions get made, when they get made, and what that pattern is doing to the project underneath them. So let me talk about that, because it turns out the data on it is pretty striking.

Decisions are the project, not the paperwork around it

It's easy to think of decisions as a byproduct of running a project. You do the real work, and decisions are the little forks along the way. I'd argue it's the reverse. The decisions are the project. Everything else is execution of choices already made.

And the research backs up just how much those choices weigh. The Institute of Project Management has pointed to findings that projects with robust decision-making processes are 2.5 times more likely to achieve success than those with ad hoc approaches. That's not a small edge. That's the difference between a process and a coin flip.

It also tracks with what McKinsey has found at the organizational level. In their work on decision making in the age of urgency, the quality and speed of decision making are both strongly associated with overall company performance. Decisions aren't downstream of how a company performs. They're a leading cause of it. The same is true of a single project: the way you decide is the way you'll perform.

I made this case in a broader way in why your projects keep failing (and how AI changes that), but it's worth saying plainly here. If decisions are this central, then having no real handle on how yours are being made is flying half-blind.

The "when" matters more than people think

Here's the part I find most useful, and the part almost nobody tracks: when decisions happen tells you an enormous amount about whether a project is healthy.

Think about a project that starts strong. What does that actually look like? It looks like a cluster of clear calls made early. The team resolves the big unknowns up front, commits to a direction, and builds momentum on a foundation it can trust. Now picture the opposite: a project three weeks in that still hasn't made a single real decision. Everything is "let's circle back." Every meeting reopens the same questions. That project is in trouble, and the trouble is visible in the decision timeline long before it shows up in the deliverables. These were the projects (often customer onboarding) that scared the life out of me and had the time-to-value alarms ringing way too soon.

There's good reason to take the early front-loading seriously. One of the more counterintuitive findings from McKinsey's decision research is that speed and quality aren't actually a trade-off. They found that faster decisions tend to be higher quality, suggesting that speed does not undercut the merit of a given decision, and that the organizations that win on both were twice as likely to say their most recent decisions delivered financial returns of at least 20 percent. A team that decides early and decides well isn't being reckless. It's exhibiting the exact pattern that correlates with the best outcomes.

The flip side is just as real. When decisions stall, the cost compounds. Drawing on McKinsey's work on making faster, better decisions, companies able to make rapid, high-quality decisions are twice as likely to outperform their peers in terms of profitability. And the causes of the slowdown are rarely about the actual problem being hard. One striking figure: Gartner research indicates that 70% of executives attribute decision delays to political maneuvering rather than strategic logic. The decisions aren't slow because they're difficult. They're slow because of everything around them.

This is exactly the kind of early signal I wrote about in how to predict project risks before they derail your work. A decision that should take one meeting and is now on its fourth is a risk indicator, plain and simple. You just can't see it unless you're tracking the shape of decisions over time.

What a tracked decision actually needs

Before any of that pattern-level insight is possible, you have to capture the decisions themselves, and capture them properly. A decision you can rely on later has a specific shape. If you're doing this by hand, this is the bar.

You need the decision itself, stated plainly. Not "discussed pricing" but "we're moving to three tiers and dropping the free plan."

You need the owner. McKinsey's research repeatedly comes back to clear accountability as a driver of both speed and quality, finding that empowered, clearly-responsible decision-makers produce faster, better, and more efficiently executed outcomes. If you can't say whose call it was, you've already lost something.

You need the reasoning. This is the part everyone skips and the part that matters most. Why did we decide this? What were we weighing? A decision without its reasoning is just an instruction, and instructions are exactly what teams overturn the second conditions shift, because nobody remembers what the original conditions were.

You need the context and the timing. What stage was the project in, what constraint were we under, when did this happen relative to everything else. This is the difference between a flat record and a real source of project intelligence.

And you need it to be findable. A decision buried in a 40-line meeting recap that nobody opens is not tracked. It's just stored.

I went deeper on the discipline of capturing all of this in post-meeting discipline: the most underrated skill in project management. The short version: doing it well, every time, across every meeting, is the exception, not the rule.

The honest problem with doing this manually

I've run the disciplined version of this. I've been the person taking careful notes, writing the clean recap, tagging the decisions. And here's the truth: even when you do it well, you're only capturing what you noticed.

You're one person, paying attention to a fast conversation, deciding in real time what counts as a decision worth recording. You'll catch the big obvious ones. You'll miss the quiet ones, the half-decisions that get confirmed later, the call someone made in passing that turns out to matter enormously three weeks down the line. And you'll definitely miss the ones in the meetings you weren't in.

It doesn't help that decision-making already eats your day. McKinsey found that executives on average spend almost 40 percent of their time making decisions and believe most of that time is poorly used. Now layer the job of meticulously documenting each of those decisions on top, across every project you're running, and you can see why the careful decision log is the first thing that quietly falls off the back of the truck.

So the real answer to "how do I track decisions so nothing gets lost" is uncomfortable: as long as a busy human is the capture mechanism, things will get lost. Not because anyone failed. Because the method has a ceiling.

Letting the capture happen on its own

This is the problem we built Superdone to solve, and decision tracking sits right at the center of it.

Superdone sits in your meetings and listens the way a great note-taker would, except it never gets tired, never gets pulled into the next thread, and never has to choose between participating and recording. When a decision gets made, it captures it: the call, who made it, the reasoning around it, the context and the timing it lived in. Not a transcript dump. A structured decision, pulled out of the conversation and set aside as its own thing. The same way it automates meeting notes and action items, it treats decisions as first-class objects instead of stray lines in a recap.

That solves the capture problem. But the part I genuinely didn't expect to care about as much as I do is what becomes possible once you have all of them.

When your decisions become something you can actually look at

A single tracked decision saves you a bad Tuesday morning. Every tracked decision, aggregated, becomes a different kind of tool entirely.

Because Superdone holds the full picture of a project, every decision is recallable at any time. The "why did we kill that feature" question stops being a group memory exercise and becomes a lookup. That alone would have been worth it to me.

But sitting on top of all those decisions, the patterns I described earlier finally become visible instead of intuited. You can see whether a project front-loaded its decisions and started from strength, or whether it's drifting because the early calls never got made. You can see which decisions keep reopening. You can see the ones that took four meetings when they should have taken one, which, per the research, is usually a sign of friction that has nothing to do with the decision itself.

And then there's the organizational view, which I'll admit I didn't fully see coming. When you can look across every project at once, you start to see how your organization actually makes decisions. Where they get made fast and where they stall. Which kinds of calls reliably bog down. What keeps re-opening, and whether the same few bottlenecks show up project after project. Given that McKinsey ties this directly to performance and that the majority of delays trace back to organizational friction rather than the hard part of the problem, being able to see your own decision patterns is genuinely valuable. Most companies have no way to do it. Aggregate your decisions and suddenly you can. It's the same instinct behind getting real-time project status without more meetings, pointed at how the work gets decided rather than how it's progressing.

Where this leaves you

Tracking decisions well, by hand, comes down to the same advice it always has: capture the call, the owner, the reasoning, the context, and the timing, and put it somewhere you'll actually find it again. Do that consistently and you'll lose far less than most teams do. That's real, and it's worth doing.

But I'd be lying if I told you discipline alone was enough, because I lived the version where it wasn't. The decisions that hurt you most are the ones you didn't notice were decisions, made in a meeting you didn't get to, captured by no one. And the patterns that would actually tell you whether a project is healthy stay invisible, because no human is sitting there charting when and how every call gets made.

The fix is to stop relying on a tired human to catch all of it in the moment, and let the capture happen automatically, so every decision is there when you need it, and so the shape of your decision-making finally becomes something you can look at instead of something you only feel.

Nothing gets lost when nobody has to remember to write it down.

If you want to see what it looks like when your decisions track themselves, request early access to Superdone.