The Quiet Cost of Unmade Decisions

That was when another realization clicked for me: consensus and ownership are not the same thing. Executive sponsors expected project leadership and workstream owners to make decisions. Leadership wanted broad agreement before committing. Teams wanted confidence before execution. Everyone had input, but nobody felt empowered. And when everyone has a voice but nobody owns the outcome, decisions never actually happen.

There is an art to delivery. Make decisions early enough to preserve momentum and stay flexible enough to adjust later. Do not wait until every unknown disappears, because uncertainty never fully disappears. Projects are not built on perfect information. They are built on informed judgment. Sometimes the most important question a Project Manager asks is not, “What do we think?” It is, “What decision must be made now to protect the timeline?”

One of the most important responsibilities a Project Manager has is not building plans, running status meetings, or updating trackers. It is tracking decisions. More importantly, it is tracking the decisions that have not been made yet. When people think about project controls, they usually think about risks, issues, schedules, budgets, and action items. Those things matter, but over time I have become convinced that one of the strongest predictors of delivery success is something much simpler: can the team clearly answer what decisions have been made, what decisions remain open, who owns them, and by when?

One of the clearest examples of this for me came during a data initiative I managed. On paper, the project had everything required to move forward. We had executive sponsorship, project leadership, workstreams, meetings, and alignment sessions. But there was one foundational dependency that remained unresolved: we needed a Data Architect. Everyone agreed the role was necessary. Nobody challenged the value of having architectural leadership. And that turned out to be the problem, because agreeing that something is important is not the same thing as deciding to act on it.

Agreeing something is important is not the same thing as deciding to act on it.

Projects rarely fail because one person made the wrong decision.

They fail because nobody made one at all.

Weeks passed while vendors were explored, options were discussed, and additional information was requested. Conversations reopened and meetings continued, but the project kept moving while one of the most foundational delivery decisions remained unresolved. Eventually we passed the intended launch timeline. Then another month passed. By the time we were more than two months beyond the original project start expectations, we still had not brought on a Data Architect.

At that point, I changed my approach. Instead of continuing abstract discussions around architecture support, I tried to force the decision into something tangible. I gathered resumes and put candidate profiles directly in front of executive leadership with a simple objective: interview, evaluate, and select. Leadership interviewed three candidates. Each brought strengths and each was viable. Yet no one wanted to move forward. No single leader wanted to own the decision. Everyone wanted broader agreement, more confidence, and more validation before committing.

At first, this felt responsible. Nobody wants to make the wrong decision and nobody wants unnecessary risk. But eventually I realized the issue was not a lack of information. It was a lack of ownership. And that was when I learned something I have carried into every project since: decisions do not stay unmade forever. Eventually they become decisions, not because someone formally approves them, but because the organization starts behaving as though a decision has already been made.

The project did not pause while we waited. The work reorganized itself around the absence of a decision.

In our case, the decision quietly became that we were moving forward without a Data Architect. Nobody announced it. Nobody approved it. But it became the operating reality. The project continued, deliverables remained active, and because architecture leadership never materialized, execution teams started absorbing the gap. Data Engineers began participating in conversations that extended beyond implementation and into architectural direction. Data models were revisited repeatedly, foundational assumptions reopened, and design sessions became larger and more collaborative because ownership of architectural decisions was unclear.

None of this happened because the team lacked capability. The engineers adapted, which is exactly what good teams do. But adaptation carries a cost. Time spent creating alignment is time not spent building. Time spent revisiting foundational decisions is time not spent delivering. Questions take longer, iterations increase, and momentum slows. Eventually, the timeline starts paying for decisions nobody realized had already been made.

Decisions do not stay unmade forever.

Eventually, the absence of a decision becomes the decision.

That experience changed the way I manage projects. I stopped only tracking action items and started tracking decisions. Not just decisions that were made, but decisions that were pending. I started documenting what decision needed to happen, what information remained outstanding, who owned the call, what delivery dependency existed, and by what date the decision was required. Over time another pattern emerged. Once decisions were documented, someone would eventually say they were not present for the conversation or that more alignment was needed before moving forward.

Consensus and ownership are not the same thing.

Stay in the Loop

Occasional thoughts on project leadership, Salesforce implementations, books, and the people side of tech.