How I Think About Scoping a Data Project for a Small Business

The hardest part of working with a small business on a data project is not the build. It is deciding what to build first. The owner knows things are inefficient. They know their spreadsheets are a mess, their reporting is inconsistent, and their decision-making relies too heavily on gut feel. What they usually cannot do is translate that frustration into a specific, buildable deliverable. That translation is what scoping is, and it is where most of the value lives in a project like this.

Start with the decision, not the data

I covered this in an earlier post, but it is worth repeating because it is the foundation of every scoping conversation I have. The first question is never "what data do you have?" It is "what decision do you need to make this week or this month that you are currently making without good information?"

That question cuts through the noise immediately. Owners tend to describe their problems in terms of tools ("my spreadsheet is broken") or feelings ("I never know where we stand"). The decision question forces specificity. It turns "I never know where we stand" into "I do not know whether we can afford to hire another technician, because I cannot see labor cost as a percentage of revenue in anything close to real time."

Once you have the decision, the scope starts to define itself. The deliverable is whatever gives the owner the information they need to make that decision with confidence, delivered on a cadence that matches when the decision actually gets made.

Work backward from the output

After identifying the decision, I work backward. What does the owner need to see on their screen to make that decision? Usually it is a small number of metrics, presented clearly, updated at a frequency that matches the decision cycle.

From there, I ask where the data for those metrics currently lives. Is it in a spreadsheet? A POS system? A stack of invoices? An accounting tool? The answer determines how much structural work is needed before the dashboard or report can function. If the data is already digital and reasonably organized, the build is mostly about consolidation and presentation. If the data is scattered across physical records, shared folders, and someone's memory, there is a data structuring step that needs to happen first.

This backward mapping, from decision to metric to data source, is what keeps the scope tight. Without it, the instinct is to build a comprehensive solution that addresses everything. And comprehensive solutions for small businesses tend to be expensive, slow to deliver, and difficult to maintain.

Size the project by effort, not by value

One trap I have learned to avoid is pricing or scoping based on how valuable the insight is to the client. If an owner is losing $3,000 a month because they cannot see a margin problem, the temptation is to scope a $5,000 project because the ROI justifies it. But the actual build might only require two days of work and a few hundred dollars worth of effort.

I scope based on what the build requires: how many data sources, how much cleanup, how complex the calculations, how many revision cycles are likely, and how much documentation the client will need to maintain the tool after delivery. That is what determines the price and the timeline. The value to the client is their return on that investment, and it is almost always a multiple of the cost, but the cost should reflect the work, not the outcome.

One deliverable at a time

The most important scoping discipline is limiting the first project to one deliverable. Not a system. Not a suite of tools. One workbook, one dashboard, one report. Something the owner can see working within a week or two and immediately recognize as useful.

This serves two purposes. First, it reduces risk for the client. A small fixed-price project with a defined deliverable is a low-commitment way to evaluate whether working together makes sense. If the build is good, the relationship continues. If it is not, the client has lost very little.

Second, it produces a better result. A single deliverable built with full attention is always stronger than a multi-tool project where attention is split across several outputs. And once the first deliverable is working, it becomes much easier to scope the second one, because the owner now has a concrete example of what "good" looks like and can articulate what they want next with much more precision.

The questions I actually ask

The scoping conversation usually takes 20 to 30 minutes and follows a consistent structure. The questions are not complicated, but the sequence matters.

What does your business do, and who is involved in the day-to-day operations? This gives me the landscape. I need to understand the cast of characters and the basic workflow before I can assess where data fits in.

What decision do you make on a recurring basis that you feel like you are making without enough information? This is the core question, and sometimes it takes a few tries to get a specific answer. The owner might start broad, but with a little follow-up, we usually land on something concrete.

Where does the data for that decision currently live? This tells me what I am working with and how much structural work is ahead.

What have you tried so far, and why did it not work? This is where I learn about the platform subscriptions that did not fit, the spreadsheets that got too complicated, the reports that nobody read. It saves time and prevents me from proposing something the owner has already rejected.

What tool are you most comfortable working in? If the owner lives in Excel, I build in Excel. If they prefer Google Sheets, I build there. The best tool is the one the owner will actually use.

By the end of that conversation, I know enough to propose a specific deliverable with a defined scope, a fixed price, and a timeline. The owner knows what they are getting, what it costs, and when it will be done.

Scope is the strategy

The scoping process is not administrative overhead before the real work begins. It is the most strategic part of the engagement, because it determines whether the deliverable will actually change how the business operates or just add another file to the pile. Getting the scope right means the build has a purpose, the client has a clear expectation, and the deliverable has a direct line to a decision that matters.