THE PROJECT PLAYBOOK — PART 9

Decision Points: How to Know When to Push Forward, Pivot, or Stop

Most owners make their hardest decisions in the moment, under pressure, with no preparation. The best ones made the decision weeks earlier, before the pressure existed.

July 22, 202610 min read
1Idea2Case3Risk4Plan5Launch

In 1996, Intel held one of the most studied strategic decisions in modern business history, though at the time it did not feel historic to the people making it. The company's memory chip business, the foundation on which Intel had been built, was being steadily outcompeted by Japanese manufacturers who could produce memory chips more cheaply. Andy Grove, then president, asked his CEO a question that has since become a case study in decision making under pressure: if the board brought in a new CEO tomorrow, what would that person do?

The answer was obvious and uncomfortable. A new CEO with no emotional attachment to the memory business would exit it immediately and focus entirely on microprocessors, a smaller but more defensible part of the business at the time. Grove and his CEO then did something difficult: they walked out of the room, walked back in, and did exactly what the hypothetical outsider would have done. Intel exited the memory chip business that had defined the company's identity and became the dominant microprocessor company of the next two decades.

What makes this story useful is not the specific decision. It is the mechanism Grove used to make it. He did not wait for a moment of clarity to arrive on its own. He built a deliberate structure for recognizing when a hard decision needed to be made, and he made it before the pressure of declining performance made clear thinking harder rather than easier.

What a Decision Point Actually Is

A decision point is a predefined moment in a project where specific evidence will trigger a deliberate choice between continuing as planned, adjusting course, or stopping. It is built into the plan in advance, before the moment arrives, while thinking is still calm and unclouded by the emotional weight of being in the middle of a struggling situation.

This distinguishes a decision point from an ordinary milestone. A milestone marks progress. A decision point marks a moment where the plan itself might need to change, and it specifies in advance what evidence would justify that change.

Most small business project plans have plenty of milestones and almost no decision points. This asymmetry is worth examining, because the absence of decision points is not a neutral gap. It has a specific, predictable cost.

Why This Gets Skipped

Building decision points into a plan requires confronting, in advance, the possibility that the plan will not work. This is psychologically uncomfortable in a way that building a roadmap is not. A roadmap is an act of construction. A decision point is an act of acknowledging uncertainty, and acknowledging uncertainty while you are excited about a new project runs against the grain of the optimism that got the project started in the first place.

There is also a practical reason decision points get skipped. They require specificity about thresholds, and specificity feels presumptuous before you have any real data. How can you know in advance what level of underperformance should trigger a strategy review, before the project has even started?

The answer is that you cannot know with certainty, but an imprecise threshold defined calmly in advance is more useful than no threshold at all, defined under pressure in the moment. The Grove technique of asking what a hypothetical clear-eyed outsider would do is precisely valuable because it removes the emotional attachment that makes in-the-moment thresholds so unreliable.

The Three Components of a Useful Decision Point

A decision point that actually functions when the moment arrives has three specific components. Vague versions of any of these components produce a decision point that exists on paper but provides no real guidance when it is needed.

A Specific Trigger Condition

The trigger must be a measurable, observable fact, not a feeling. "If things are not going well by month two" is not a trigger. "If unit sales in month two are below 600, representing 60 percent of the projected 1,000 unit target" is a trigger.

The specificity matters because vague triggers are infinitely negotiable in the moment. An owner experiencing disappointing results can always find a reason why the current situation does not quite meet the bar of "not going well," particularly when the alternative is confronting a difficult decision. A specific number is much harder to negotiate away.

A Predefined Set of Response Options

A decision point without predefined options is just a moment of anxiety with a date attached. The useful version specifies, in advance, what the actual choices are when the trigger condition is met.

This does not mean deciding in advance which option will be chosen. It means doing the harder work of identifying what the realistic options actually are, before the emotional pressure of the moment narrows your thinking to the options that feel most urgent rather than the options that are actually available.

For a product launch underperforming its month one target, the predefined options might include: extend the marketing investment with a revised channel strategy, adjust pricing to test demand elasticity, pause additional spend and gather more diagnostic information before committing further, or wind down the specific initiative while preserving the underlying business.

Having these options named in advance, even loosely, means the decision moment becomes a selection among known alternatives rather than an open-ended scramble to invent options under stress.

A Clear Owner of the Decision

In a small business, this is often less obvious than it sounds. If the founder has a co-founder, a spouse who is a financial partner, or a small advisory group, who actually makes the call when a decision point is triggered? Defining this in advance prevents the diffusion of responsibility that often allows a clear decision point to pass unaddressed because everyone assumed someone else was tracking it.

Where Decision Points Belong in Your Plan

Decision points are not evenly distributed throughout a project. They cluster at specific, predictable moments: shortly after launch when early market data first becomes available, at any point where a significant additional investment is being considered, and at any point where a critical dependency identified during risk assessment could plausibly fail.

The financial risk brief discussed earlier in this series touched on one of the most important decision points any project has: the point at which actual revenue performance against the break-even calculation tells you whether the financial structure is working as planned. This is rarely framed explicitly as a decision point in small business planning, but it should be one of the most carefully defined moments in the entire project.

A Decision Point in Practice

Consider a small business owner launching a new service line with a three-month plan and a goal of five new client engagements by the end of month one to validate market demand before scaling marketing investment further.

A vague version of this plan simply hopes for five clients and reacts to whatever number actually materializes. A version with a real decision point specifies: if five or more engagements are signed by day 30, proceed with the planned marketing scale-up. If between two and four engagements are signed, pause additional spend and conduct structured conversations with prospects who did not convert to understand the specific objection before committing further resources. If fewer than two engagements are signed, treat this as a signal that the core offer or pricing needs fundamental reconsideration before any further marketing investment, and schedule a full business case review.

Notice that none of these thresholds are precise predictions of what will happen. They are predefined responses to ranges of outcomes, built while thinking was calm, ready to be applied the moment real data arrives.

What Comes Next

A project with a confirmed team, a sound financial structure, and clearly defined decision points has done the work that distinguishes deliberate execution from reactive improvisation. What remains is the question of how all of this translates into the actual moment of launch, and what specifically needs to be true on day one for the launch itself to go well.

That is the final piece of project planning, and it deserves its own careful treatment, because the gap between a plan that looks complete on paper and a launch that actually goes smoothly is almost always found in details that feel too small to plan for in advance, right up until the moment they turn out to matter enormously.

That is where this series turns next, into the territory of launch itself.

SBwiser logo

Enjoyed this article?

The Wiser Way publishes every Tuesday. Subscribe free and get the next article delivered to your inbox.

By subscribing you agree to receive The Wiser Way newsletter from SBwiser. Unsubscribe anytime.