A small business analytics project should turn one business question into something your team can use: a report, dashboard, analysis, or improved spreadsheet. Expect three broad stages: define the question, build and review drafts, then hand over the finished work with documentation. You will agree on the scope, provide data and access, review progress, check the numbers, and confirm who maintains the result. A good proposal explains what is included, what counts as done, and what happens after handoff. On my Services page, I describe the process as define the question, analyze and iterate, and hand over with clarity.
If you are still deciding whether you need outside help, start with When Should a Small Business Hire a Data Analyst? Here, I assume you have chosen someone, or are close to it, and want to know what happens next.
To make each stage concrete, I will follow a hypothetical project: a service-business owner wants a weekly view of overdue invoices using an invoice export and customer list. The example is an illustration, not a client case study.
What happens at the start of an analytics project?
The first step is agreeing on the question the project will answer and what you will receive. Expect a conversation about the decision you need to make, followed by a short written scope that you approve before building starts.
That conversation should be about your business, not software. What decision will this support? Who will use the output, and how often? Which numbers do you trust? Microsoft’s guidance on planning business intelligence solutions likewise recommends defining the problem collaboratively with the people who will use the result.
The scope that comes out of that conversation should be short. It should name:
- The decision the work supports
- The output: a report, a dashboard, an analysis, or sometimes just a better spreadsheet
- The data sources involved
- What is excluded
- Who is responsible for what, on both sides
- When you will review progress
- What counts as done
Exclusions matter as much as inclusions. They keep a small project small.
In the late-payment example, the scope might say: Decision: whether to change terms for repeat late payers. Output: an analysis with recommendations and a weekly overdue-invoice view. Sources: the invoice export and customer list. Excluded: disputed invoices and cash-flow forecasting. Checkpoint: review the first findings. Done: the owner can act on the analysis, and the office manager can update the weekly view without help.
The output does not have to be a new tool. If the scope can be met with software you already have, that is often the simpler answer. “Do You Need a Data Analyst or Better Spreadsheets?” helps you tell the difference. If you are still comparing consultants, questions 1 and 2 in 12 Questions to Ask Before Hiring a Data Consultant cover what to ask about this stage before you sign.
What data and access will you need to provide?
You will need to supply the data the question depends on, access to the systems it lives in, and someone who knows how the records work. The consultant cannot guess your business rules, such as when an invoice counts as late, so that knowledge is your most important contribution.
Expect to be asked for:
- The reports and spreadsheets you use today, even the messy ones
- Exports from the source systems, or read-only access to them
- A named person who knows how the records are entered and what the odd entries mean
- Your working definitions: what counts as overdue, active, or complete
- Known problems, such as duplicate customers or a system change partway through the year
Access should be the minimum the work requires, and read-only is a sensible default. Question 7 in 12 Questions covers what to ask.
Messy or incomplete data does not necessarily prevent a useful project. If a field is missing or unreliable, record the limitation and work within it, or narrow the question to what the data can support. Data that was never captured cannot be reconstructed as fact.
The late-payment analysis needs the issue, due, and payment dates for each invoice. If older records lack a due date, the team might start where that field becomes reliable and document the limitation rather than inventing history.
To check how usable your data is before the project starts, work through The Small Business Data Audit Checklist. It covers where your data lives, who owns it, and whether it can be exported.
What will you see before the work is finished?
You should see a rough working version early, before it is polished, so wrong assumptions get caught while they are still cheap to fix. Treat it as a draft for review, not the finished deliverable.
Analytics work should move in cycles: build part of the solution, check it, adjust, and repeat. Microsoft’s planning guidance recommends iterative development and validation rather than one long build followed by a reveal. A draft may have rough edges; at this stage, a wrong definition matters more than unfinished formatting.
When a draft arrives, review it against three questions:
- Is the right information included, with nothing important left out?
- Do the definitions match how your team actually talks about the business?
- Can the person who will use it each week understand it without an explanation?
Name one person to collect feedback from your side. Record each agreed change in writing so both sides know what the next version will include.
In the late-payment example, the first draft counts payment-plan invoices as late because they passed their original due date. The owner explains that those invoices follow an approved schedule, so the team records a new rule: exclude payment-plan invoices. This is the kind of business context only the client can supply, and it is easier to correct during review than after handoff.
How long does an analytics project take, and what can change the plan?
It depends on the scope, how ready your data is, and how quickly your side responds, so be cautious about a firm timeline quoted before anyone has seen your data. A sensible start is a short, bounded first phase with named outputs, followed by estimates for the rest based on what that phase finds.
I recommend a bounded two-week paid discovery or audit with named outputs: a data-source inventory, risk and quality findings, a prioritized scope, and a go/no-go decision. That is a starting point, not a prediction of the full project timeline.
After that, ask for estimates tied to milestones in the agreed scope, such as the first draft, the tested version, and handoff, rather than a single end date.
Plans usually change for predictable reasons:
- An export you expected does not exist, or lacks a field
- Two people define the same metric differently, and someone has to decide
- Feedback on a draft takes longer than planned
- New requirements appear partway through
Agree in writing how added requirements affect time and cost. If the owner adds a cash-flow forecast to the late-payment example, it becomes a new request with its own estimate.
How will you know the numbers are right?
Agree how the work will be tested before it starts, then check the numbers against records you already trust. A report is not finished until its figures match an agreed baseline and the person who will use it has tried it for real.
Microsoft’s guidance on validating reports recommends testing data against a known baseline, confirming that features such as refresh work, checking access, and having users test whether the result meets the business need. It also recommends documenting success criteria in advance. For a small business, that becomes four practical tests:
- Accuracy: the key figures match a source you already trust, for the same date and with the same exclusions
- Refresh: new data comes through when it should, without manual repair
- Access: the right people can open it, and nobody else can
- Use: the person who will rely on it completes their real task with it
The last test is often called user acceptance testing. In plain English, the people who will use the output confirm it does the job before you accept it.
In the late-payment example, testing has two parts. The first is the inputs. Check the days-late figure by hand on a handful of invoices, then confirm that the number and value of late invoices for one period match the invoicing system, using the agreed exclusions for disputed and payment-plan invoices.
The second is the assumptions. If the analysis estimates the cost of late payment, document the financing rate and every other input. Recalculate several invoices by hand and confirm that the formula uses the agreed dates and exclusions.
If a figure does not match, investigate it. A difference may be acceptable once its cause is understood, documented, and approved; an unexplained difference is not. Keep the test record so you can show how the number was checked later.
What should you receive at handoff, and who maintains it?
At handoff you should receive the finished output plus everything needed to run it without the consultant: documentation, metric definitions, operating instructions, and access that you control. Who maintains it afterward should be settled in the proposal, not discovered after launch.
A useful handoff checklist:
- The agreed output and its files, stored in accounts your business owns
- Metric definitions, written in plain language
- Documented limitations, such as the date range the data covers
- Operating instructions: how to refresh it, what to check, and what to do if something breaks
- A walkthrough with the person who will run it, not only the owner
- Clear ownership and access, including admin rights where needed
- A support contact, and what support, if any, is included
- The line between a fix and a new request
A fix means the output does not do what was agreed. A new request asks it to do something else. Because they may be handled differently, define the boundary in writing.
Microsoft’s guidance on supporting reports after release calls the period after a major change “hypercare.” It recommends planning for added feedback and clarifying support responsibilities. Your proposal should say who answers questions after handoff and for how long.
In the late-payment example, the handoff includes the findings, the method and assumptions behind them, and the agreed recommendations. It also includes the weekly overdue-invoice view in the owner’s account, a one-page definitions sheet, update instructions, and a walkthrough with the office manager.
The proposal also states who handles a fix if the export format changes.
For the contract side of handoff, including who owns the work, what you keep if the engagement ends, and how post-delivery bugs are handled, see questions 5, 6, and 11 in 12 Questions to Ask Before Hiring a Data Consultant.
How can you prepare for a useful kickoff?
Come to the first meeting with one clear business question and the materials behind it. Before kickoff, gather:
- One business question, written as a decision
- The reports or spreadsheets you use today
- A contact for each data source
- Known data problems
- One named reviewer from your side
- How often the decision is made: weekly, monthly, or quarterly
For the example, bring the question “Which customers pay late, and what does it cost us?”, the current overdue-invoices report, the bookkeeper as source contact, known exceptions such as payment plans, and the office manager as reviewer.
For more thorough preparation, The Small Business Data Audit Checklist goes further. If you are not sure your business is ready, the five-minute Analytics Health Assessment gives you a starting point before any conversation.
A well-run project asks the same things of you at every stage: explain the decision, supply the inputs, review the draft, test the numbers against a baseline, and take ownership at handoff.
Have a reporting problem in mind? Send a short description of the decision you need to make and the systems you use.
Sources
- Microsoft Learn, “Power BI implementation planning: BI solution planning”: https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-bi-strategy-bi-solution-planning
- Microsoft Learn, “Power BI implementation planning: Validate content”: https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-content-lifecycle-management-validate
- Microsoft Learn, “Power BI implementation planning: Support and monitor content”: https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-content-lifecycle-management-support-monitor