Winning on Luck: How Successful Projects Conceal the Habits That Will Eventually Break You

There is a particular kind of organizational blindness that only success can produce. When a project lands on time, within budget, and earns praise from the executive suite, the instinct is to celebrate and move on. What rarely happens—and what should—is a rigorous examination of why it succeeded and whether the team's habits had anything to do with it.

The uncomfortable truth is that many projects succeed in spite of their teams, not because of them. Favorable market conditions, a forgiving client, an experienced vendor who quietly compensated for internal gaps, a timeline that happened to have more float than anyone realized—these are the invisible scaffolding that holds up a surprising number of "successful" initiatives. And when that scaffolding disappears on the next project, the habits that were merely inefficient become genuinely catastrophic.

The Anatomy of a Lucky Win

Consider how often a project debrief sounds something like this: the team shipped late in one phase but recovered time in another; a key dependency resolved itself right when it was needed; a stakeholder who had been difficult suddenly became cooperative in the final stretch. Leaders nod along, log the project as a success, and draw the lesson that the team is resilient and capable.

What they rarely log is the list of practices that could have derailed the project but didn't. The requirements document that was vague but happened to match what the client wanted anyway. The testing phase that was compressed but didn't surface a critical defect—this time. The resource conflict that was never formally resolved because one team lead informally absorbed the extra work without being asked.

These are not success factors. They are deferred risks. And organizations that fail to name them are simply banking on the same luck holding next quarter.

Why Retrospectives on Wins Get Shortchanged

Post-mortems on failed projects are painful, but they have a built-in motivation: something went wrong and people want to understand why. Retrospectives on successful projects suffer from the opposite problem. Nobody is under pressure to find fault. The meeting is often shorter, the conversation more congratulatory, and the action items fewer.

This is a structural problem, not a personal failing. Leaders are busy. Political capital is scarce. Telling a team that just delivered a win that they need to examine their vulnerabilities can feel like ingratitude. In many corporate cultures, it reads as exactly that.

But the cost of this avoidance compounds. Every project that succeeds without a genuine process audit becomes a reference point for how the organization operates. "That's how we do it here" calcifies around practices that were never actually validated—they were simply never tested under real pressure.

Running a Vulnerability Audit on a Winning Project

The goal is not to manufacture problems where none exist. It is to distinguish between earned success and fortunate success—and to identify which habits belong in which category.

A practical starting point is a structured retrospective that asks teams to answer three questions honestly:

1. What did we get away with? This question surfaces the corners that were cut, the risks that were accepted informally, and the moments where the team proceeded without full information. Framing it as "getting away with" rather than "mistakes we made" reduces defensiveness and invites candor.

2. What resolved itself without our intervention? External dependencies that worked out, client decisions that aligned with internal assumptions, vendor performance that exceeded contract terms—these are not team achievements. Naming them explicitly prevents them from being mistaken for repeatable process strengths.

3. Where were we one decision away from a different outcome? This is the most valuable question, and the most uncomfortable. It asks teams to identify the branch points where a single different variable—a delayed approval, a missed communication, a resource pulled for another priority—would have changed the trajectory significantly.

The output of this exercise is not a failure report. It is a risk register for the team's operating habits: the practices that need to be strengthened before the next project removes the slack that made them survivable.

The Complexity Threshold Problem

Project leaders often discover their habits are inadequate not gradually, but all at once—when a new initiative exceeds what might be called the complexity threshold of their current practices.

Below that threshold, informal communication works. Undocumented decisions stay retrievable. Loosely defined roles don't create overlap that matters. Above it, every one of those informal workarounds becomes a failure point simultaneously.

The problem is that organizations tend to assign more complex projects to leaders with strong track records. That track record, built on projects that stayed below the threshold, says nothing about whether the leader's habits are ready for what comes next. In fact, it may actively mislead both the leader and the organization about the level of rigor actually required.

Building the Habit of Honest Retrospection

The organizations that avoid this trap share a common practice: they treat retrospectives on successful projects as equally mandatory—and equally structured—as those on failed ones. They resist the cultural pull toward celebration-only debriefs and institutionalize the discipline of asking hard questions when the pressure to do so is lowest.

For individual project leaders, the discipline is more personal. It requires developing a genuine curiosity about which of your practices are skills and which are superstitions—habits you've never had to test because the conditions haven't demanded it yet.

The most dangerous moment in a project leader's career is not a high-profile failure. It is a long run of easy wins that builds confidence in habits that have never been validated. When the harder project arrives—and it always does—the gap between perceived capability and actual readiness can be wide enough to end careers.

Smart leaders close that gap deliberately, before the stakes demand it.