How to plan a data analysis project: question, scope and acceptance

You have a free weekend, open a dataset and start building a dashboard. A few hours later, you have three tabs, a map and a chart that changes colour beautifully. Then someone asks what you actually learned. Suddenly, the hardest part of the project is answering in one sentence.

I prefer to establish the purpose of that sentence earlier. It cannot contain a finished conclusion, because I do not know the result yet. It should explain which question I am investigating, who needs the answer and how I will know the work is complete. That lets me choose data and tools according to the task instead of inventing a task around a function I have just learned.

I will use a fictional project about shipment timeliness. Every number, role and agreement below is synthetic. This is an educational scenario, not a description of a client or a measured implementation outcome. You can adapt the approach to a portfolio, a small assignment at your current job or a conversation with someone requesting a report.

Name the use of the result

“I want to analyse orders” names an area. It could cover sales, inventory, complaints, deliveries and customer behaviour. That scope can grow very quickly. I would narrow it to a question: which groups of orders deserve further investigation to understand late shipments? The intended reader would be the person planning warehouse operations.

The use is specific: choose an area to investigate. At this stage, I am not promising to identify who is responsible or to reduce costs. The report might reveal where delays concentrate, but it cannot by itself establish whether staffing, stock availability, a system change or a different order mix caused them. I put that boundary into the plan.

IBM’s Business Understanding overview for CRISP-DM emphasises understanding organisational expectations, involving key people and recording the discussion before producing the project plan. For a small analysis, I use a lightweight version of that principle: a few agreed sentences rather than an enormous document nobody will reopen.

Find out who will use the answer

The same dataset can serve different audiences. A warehouse manager needs to recognise an operational problem. Customer support wants to know which orders might miss their deadline. Leadership may ask about a longer-term trend. Those are three different assignments, even if they all begin with an orders table and look similar in a request queue.

I ask when the result will be used. Will someone open it during a weekly meeting? Will it help select orders for intervention every morning? Is a one-off answer sufficient? Frequency changes the requirements for freshness, automation and presentation. A one-off investigation does not automatically need to become a permanent reporting system.

In a portfolio, you do not need a real requester. You can explicitly adopt the perspective of a hypothetical reader. The important part is consistency. If your report serves a warehouse manager, its conclusion should relate to an action that person could consider. A count of every customer in the database is unlikely to help with the question we have chosen.

Write a question that allows an inconvenient answer

A useful question allows a result you did not expect. “How can I prove that the new process made shipping faster?” assumes success before examining the evidence. I prefer: “How did the share of late shipments change among comparable orders?” Possible answers include improvement, deterioration, no clear difference and insufficient data for a meaningful comparison.

If you have a hypothesis, record it separately. In this example, it might be that orders containing products from multiple warehouse zones miss their deadline more often. That is something to investigate, rather than an established fact. I need information about zones, deadlines and order composition. Finding a difference alone would still leave the mechanism unresolved.

I also note what could undermine the interpretation. Perhaps larger orders are more likely to involve several zones. Perhaps one group has a different promised turnaround time. This list need not prevent an initial analysis. It helps describe its reach honestly and plan a next step. Otherwise, the project can become a competition for the most confident caption under a chart.

Establish what one row represents

Before choosing a visual, I establish the unit of observation. Here, I count orders. One order might have several product lines, several status changes and more than one parcel. Joining those tables without checking their relationships can produce many rows describing the same order. A delay rate calculated over those rows could answer a different question entirely.

For this exercise, an order must be shipped completely before its recorded deadline. Its shipment timestamp is when the final parcel is dispatched. Each order identifier appears once in the analytical table. A business measuring parcel-level timeliness would need a different definition. A convenient column name cannot settle that choice for us.

The brief also records the timezone and how deadlines are compared. Does “by Tuesday” mean a specific time, the end of the day or a business day according to the company’s calendar? You do not need elaborate code to recognise that ambiguity. You need an agreement, or an explicit assumption in an educational project. Resolving it early prevents several perfectly executed calculations from measuring different things.

Inspect a small sample before promising delivery

I check whether the necessary fields exist: order identifier, promised deadline, actual complete-shipment timestamp and the chosen grouping variable. I inspect individual records and basic completeness summaries. I look for repeated identifiers, missing dates, unfamiliar statuses and values that contradict the expected sequence of events.

Having access to a file does not mean it can answer the question. It might contain only the current status, with no history. The promised deadline might have been overwritten after a delay. That makes it difficult to evaluate whether the original promise was kept. Identifying this gap is a useful audit result, even if it postpones the chart.

For each problem, I record the consequence. A missing warehouse-zone field prevents the proposed breakdown but may not prevent an overall comparison. Missing promised deadlines affect the metric itself. This distinction shows what can continue independently and what requires a different question. A general complaint that “the data is bad” does not provide the same guidance.

Define the metric and its exclusions together

For a simple version, I divide late orders by orders with complete information included in the analysis. An order is late when its complete-shipment timestamp exceeds its promised deadline. I choose closed groups of completed orders and explicitly state that this does not measure the current backlog of unshipped orders.

That qualification matters. If I excluded unshipped orders while claiming to measure every order, the picture could be overly optimistic. Open orders already past their deadline need a separate view. In the initial project, I can include their count and state the limitation, then consider a separate analysis of waiting time in a later version.

I show records excluded for missing information separately. I do not automatically classify them as on time. Missing evidence and a successful outcome are different states. That is why the definition includes the numerator, denominator, period and exclusion rules. Without those details, even a correctly executed division can lead the reader towards a misleading conclusion.

Work through the numbers on a small example

In the synthetic summary, group A contains 500 completed orders with complete information. Of those, 40 were shipped late. Group B contains 600 comparable records, of which 72 were late. The corresponding shares are 8% and 12%. The difference is 4 percentage points. Relative to the first share, the second is 50% higher.

Alongside that result, I show 20 orders with a missing date in group A and 60 in group B. Before exclusion, there were therefore 520 and 660 completed orders. The missing-date shares are approximately 3.85% and 9.09%. I do not quietly add these records to the timeliness denominator, because their outcome is unknown under the definition we selected.

First, I reproduce this calculation on paper or in a simple worksheet. Then I compare it with the tool’s output. If the basic sample disagrees, automation will merely produce incorrect numbers more quickly. I do not yet need an advanced model to check totals, denominators and the meaning of a published percentage.

Plan a comparison that exposes differences

Groups A and B could represent two periods. Before interpreting them, I check whether they cover similar activity. One period might contain more large orders or more products requiring replenishment from suppliers. The completeness of date recording could also have changed, which is already visible in the missing-data summary.

I do not try to resolve every issue in one chart. In the initial version, I describe the difference and propose one justified breakdown, such as order size. I check the counts in the resulting groups. A very small group can produce a dramatic percentage based on only a handful of cases. Dashboard colours will not explain that instability to the reader.

My conclusion would be that, among completed orders with complete information, group B has a higher late-shipment share and more missing records. Before recommending a process change, we need to examine group composition and the missing information. That is less dramatic than declaring a single cause, but it gives the reader an honest basis for the next action.

Limit the first version

The first version covers one question, two periods, a timeliness definition, completeness checks and one supporting breakdown. The deliverable is a short summary with commentary. Delay prediction, employee assessment, warehouse-system integration and daily notifications remain outside the scope. Any of those ideas might be useful, but each requires additional work and decisions.

When a new question appears, I record it for later. I ask whether it should replace part of the current assignment or belong to the next version. I avoid adding it indefinitely to the “just one more thing” list. This is particularly useful in a portfolio, where the absence of an external deadline can turn a small project into an endless renovation.

Limiting the scope also helps choose a tool. If a worksheet and a few transparent calculations are sufficient, I do not build a warehouse just to list more technologies in the write-up. If practising SQL is an educational objective, I state it separately. The project then has an analytical question and a deliberately chosen skill to practise.

Set acceptance criteria before building

“The dashboard looks professional” is too vague to verify. I want to check whether every number has a definition and period, whether the result preserves one order per row, whether exclusions are counted and whether the control sample produces the expected answer. The reader should find the answer without searching every tab or guessing what abbreviations mean.

I include reproducibility. Someone with the same synthetic input file should be able to repeat the calculation. I describe the sequence of steps, the required tool and the meaning of the columns. This does not promise an identical result after the data changes. It allows another person to understand the process and verify the same version of the material.

Finally, I add an interpretation criterion: observations, hypotheses and the proposed next step must be distinguishable. If the question remains unanswered, the explanation must identify the missing information. The project can then finish with a useful account of its limitations. A conclusive answer should not be manufactured merely because the final slide has space for a recommendation.

Schedule work around uncertainty

Instead of writing “Monday: dashboard”, I start with the risk that could invalidate the entire idea. Here, that means checking the original promised deadline and establishing one row per order. Only then do I spend substantial time cleaning the whole dataset and designing the presentation. The order of work should reflect what could force a change of direction.

An example plan has five short sessions: brief and sample, data audit, calculation and checks, interpretation and first review, then revisions and reproduction instructions. This is a suggested structure for an exercise, not a guaranteed number of hours. If the audit reveals a missing essential field, I revisit the scope and update the plan openly.

I reserve time for feedback. Showing one draft table before polishing the design can expose a misunderstood question. I request comments on something specific: whether the definition fits the need, whether the breakdown is useful or whether the limitations are understandable. “Do you like it?” rarely resolves the most important uncertainty in an analytical project.

What if an interesting dataset comes first?

An exploratory project can be useful too. You can inspect an available dataset, learn its structure and identify questions it might answer. You do not need to invent a company requesting the analysis to justify learning. I would state an exploratory objective: examine the data’s coverage and quality, then identify three possible directions for further analysis.

I still put a boundary around exploration. After the initial inspection, I choose one question or finish with a short explanation of why the data cannot support the intended use. Otherwise, a week can disappear into producing charts without any stopping criterion. Curiosity is a reasonable starting point; a plan helps turn it into a result you can show and evaluate.

Put the brief on one page

My example brief would begin: “I compare complete-shipment timeliness for completed orders across two periods. The result helps the warehouse manager choose an area for further investigation. I calculate the metric for orders with complete dates and show missing records and overdue open orders separately. I do not attribute the difference to a cause on the basis of this comparison alone.”

I then add the source file, field definitions, unit-of-observation rule, acceptance criteria and first review date. A separate sentence names what is outside the scope. This document should be quick to read and correct. If several conflicting versions of the agreement appear, I identify the current version and record what changed following the discussion.

The brief is a working tool. When you discover that the data does not fit the question, revise it explicitly. Do not pretend that whatever you managed to calculate was the original plan. In a portfolio, explaining that decision can reveal more analytical thinking than another visual. The reader sees the problem you recognised and why you chose a particular route.

Decide what to show at handover

I present the answer, evidence and limitations in an order that suits the reader. First comes a sentence about the result, then the table with counts, the definition and the quality checks. Code and transformation details can follow. Someone interested in the decision should not have to begin with an inventory of every function I used.

In a portfolio description, I separate completed work from business outcomes. I can say that I created a repeatable comparison and identified unequal data completeness. I cannot claim savings I did not measure or a process improvement nobody implemented. A synthetic project remains synthetic even when its presentation looks convincing. For more on working through an initial analysis, see the guide to a project using your own data.

To start today, choose one question and write five sentences describing the brief. Then inspect a small set of records. Check whether the selected data can answer the question at all. Only after that trial should you decide what to build. This gives you a clear direction and an honest point at which you can say that the project is finished.