In the spring of 2012, a small software company in Austin, Texas made a decision that its founders would later describe as the most important thing they did not do. They had a working product, early customers, and genuine enthusiasm from everyone they showed it to. They had, in other words, exactly the conditions that typically produce a sprint toward full commitment.
Instead, they spent three weeks writing a business case.
Not a business plan. Not a pitch deck. Not a document designed to impress anyone outside the room. A structured internal argument for why the product they had built was worth the next two years of their lives and the capital they would need to deploy. They examined the market opportunity with specificity. They stress-tested their revenue assumptions. They named the three things that had to be true for the business to work and asked, honestly, whether those things were true.
One of them was not. The customer acquisition cost they had been assuming was based on a channel that, when examined carefully, would not scale the way they needed it to. The product was real. The market was real. The path they had planned was not.
They rebuilt the path before they committed to it. The company went on to grow steadily for the next decade.
The business case did not make their project successful. But it almost certainly prevented the version of the project that would have failed.
What a Business Case Is, and What It Is Not
The phrase carries institutional baggage. In large organizations, a business case is often a lengthy document produced by a team of analysts, reviewed by committees, and filed somewhere before being largely ignored. It is associated with bureaucracy, with justifying decisions already made, with the particular theater of corporate governance.
This is not what we are talking about.
A business case for a small business project is a structured thinking exercise that forces the owner to articulate, in plain language, the argument for why the project makes sense. It is written for an audience of one. It asks uncomfortable questions and insists on honest answers. It takes the optimism that drives good entrepreneurs and subjects it to the scrutiny that good projects require.
The distinction between a business case and a business plan is worth holding clearly. A business plan is typically written for external audiences. Banks want to see financial projections. Investors want to see market analysis and competitive positioning. Partners want to see operational details. The business plan is shaped, at least in part, by what those audiences expect to find.
A business case is shaped entirely by what the project needs you to know before you commit to it.
The Six Arguments Your Business Case Must Make
Experienced project practitioners, whether they use the language of PMI, PRINCE2, or any other methodology, tend to converge on a similar set of questions when evaluating whether a project is worth pursuing. The frameworks differ in their terminology and their formality, but the underlying inquiries are remarkably consistent.
For a small business owner, those inquiries resolve into six arguments that a solid business case must make convincingly.
The opportunity is real and the timing is right
This is where validation work feeds directly into business case thinking. The business case does not repeat the validation process. It synthesizes its conclusions. It states, with evidence rather than assertion, that a genuine market opportunity exists, that the timing favors action, and that the conditions which make the opportunity available are not temporary or illusory.
The timing question deserves particular attention. Markets have windows. The restaurant owner who identified unmet demand for corporate catering in her area is looking at a window that could close if a well-capitalized competitor moves first, or if the corporate clients she is targeting shift their behavior in response to remote work patterns, or if a broader economic contraction reduces discretionary business spending.
Naming the window, and the conditions that could close it, is not pessimism. It is precision. A business case that does not acknowledge the temporal dimension of an opportunity is incomplete.
The revenue model is clear and defensible
How does this project make money? Not in general terms, but specifically. What is being sold, to whom, at what price, with what frequency, through what channel?
These questions seem basic. They are consistently underspecified in the planning stages of small business projects, and that underspecification consistently creates problems downstream. A project that launches with a vague revenue model tends to make pricing decisions reactively, discount under competitive pressure, and struggle to understand why it is not generating the returns that seemed obvious at the outset.
The business case forces specificity. It insists on a number. Not a range. Not "somewhere between X and Y depending on how things go." A specific price, a specific volume assumption, and a specific calculation of what those assumptions produce in revenue over a defined period.
The calculation will almost certainly be wrong in its specifics. That is not the point. The point is that the act of making it reveals the assumptions baked into it, and those assumptions can be examined, challenged, and stress-tested while they are still just numbers on a page rather than losses on a balance sheet.
The costs are understood, not estimated
There is a pattern so common in small business project planning that it has acquired its own informal name among project managers: the optimism bias in cost estimation. Projects almost universally cost more than their initial estimates, and the gap between estimate and reality tends to be larger the less structured the planning process was.
The reasons are well documented. People systematically underestimate the time required for tasks they have not done before. They forget to account for the costs of coordination, compliance, and the inevitable unexpected complications. They anchor on best-case scenarios rather than most-likely scenarios.
A business case does not eliminate cost uncertainty. It does require that the owner identify every meaningful cost category, assign a realistic figure to each one, and build in a contingency for the things they cannot yet see. The process of doing this work tends to surface costs that were not visible during the initial enthusiasm of idea generation, and surfacing them early is always preferable to discovering them after commitments have been made.
The strategic advantage is real and defensible over time
This argument builds directly on the validation question about whether you are the right person to pursue the project. The business case goes further by asking not just whether you have an advantage now, but whether that advantage is durable.
Advantages erode. A unique relationship becomes less unique when competitors develop their own relationships. A proprietary process gets reverse-engineered or superseded by new technology. A geographic advantage gets competed away when a well-funded new entrant decides the market is worth entering.
The business case asks what happens to the project's competitive position in twelve months, in twenty-four months, in three years. Not with the expectation of a precise answer, but with the goal of identifying which elements of the advantage are structural and which are temporary. Temporary advantages can still be valuable, but they require a different kind of strategic response than durable ones.
The critical assumptions are named and tested
Every project rests on a set of assumptions that, if wrong, would materially change its viability. The business case exists, in part, to make those assumptions visible.
This is harder than it sounds. Assumptions that are deeply held tend to be invisible. They are the water the project swims in, present everywhere and noticed nowhere. Surfacing them requires a deliberate effort to ask, for every element of the project's logic, what has to be true for this to work the way I am imagining?
The restaurant owner's catering business rests on the assumption that corporate clients in her area will switch from their existing providers for the specific advantages she offers. That assumption can be tested before she invests in equipment and staffing. The software consultant's productized methodology rests on the assumption that companies will pay for a workshop version of knowledge they could theoretically acquire through consulting engagements. That assumption can be tested before she builds the curriculum.
Named assumptions can be investigated. Unnamed assumptions become surprises.
The definition of success is specific and measurable
The business case closes the loop opened in the project definition phase. If the first article in this series argued that projects fail when their goals are not clearly defined, the business case is where that definition gets made concrete and binding.
What does this project look like when it has succeeded? Not in the abstract, not in the language of general positive outcomes, but in specific observable terms. Revenue reached. Customers served. Market share achieved. Operational milestones cleared. A date by which these things will have happened.
The specificity is not about rigidity. Projects evolve, and a business case written at the outset will need to be revisited as new information arrives. The specificity is about creating a reference point against which decisions can be made. Without it, every decision is made in a vacuum. With it, the project has a compass.
The Document That Changes the Conversation
There is a secondary benefit to writing a business case that rarely gets discussed in planning frameworks, perhaps because it is harder to quantify than the analytical value of the exercise itself.
The act of writing a business case changes the quality of every conversation you have about the project afterward.
When you have done the work of articulating the opportunity, the revenue model, the costs, the advantage, the assumptions, and the definition of success, you bring a different kind of clarity to conversations with potential partners, suppliers, employees, and advisors. You are not selling an idea. You are presenting an argument. And arguments, unlike ideas, invite productive challenge.
The partner who pushes back on your customer acquisition assumptions is giving you something valuable. The supplier who questions your cost projections is helping you. The advisor who asks about your competitive advantage and is not satisfied with a vague answer is doing the work that the business case was designed to prompt.
This is the document that nobody writes and everybody needs. Not because the document itself is the point, but because the thinking it requires produces a clarity that no amount of enthusiasm can substitute for.
What Comes Next
A solid business case tells you that the project is worth pursuing. It does not tell you what could go wrong.
That is a separate conversation, and it is one that most owners approach with a mix of reluctance and optimism that works against them. Risk assessment has a reputation for being the part of project planning where cautious people slow things down by imagining improbable disasters.
That reputation is undeserved and costly. Done well, risk assessment is not about imagining disasters. It is about identifying the specific, plausible, often mundane things that could derail the project you have just made a compelling case for pursuing, and deciding in advance what you would do about them.
That conversation is coming next. And it starts with an observation that tends to surprise people: the risks most likely to affect your project are almost certainly not the ones you are most worried about.