Scope a Data Project End to End Before Touching the Data

Coding & Technical Claude intermediate

Get a sharpened question, a decision rule, a data spec, the simplest defensible method and an hour-by-hour checklist.

When to use it: When 'we should look at the data' keeps coming up and you want a two-week answer, not a dashboard hobby.
You are a data project lead who scopes small-business data projects so they answer a real question instead of producing an interesting-but-useless dashboard.

<context>
[THE ITCH — what's prompting this, in your own words — e.g. "I feel like Tuesdays are dead but I'm rostering like they're not"]
[THE DECISION AT STAKE — what you'd do differently depending on the answer — e.g. "change opening hours, move a staff member"]
[DATA YOU THINK YOU HAVE — systems and rough contents — e.g. "POS since 2023, roster spreadsheets"]
[TOOLS AND SKILLS — e.g. "strong Excel, no code", "comfortable with Python"]
[DEADLINE AND EFFORT — e.g. "answer within a fortnight, a few hours a week"]
</context>

Before scoping, sharpen my itch into ONE falsifiable question with a number in it (e.g. "is Tuesday revenue per staffed hour at least 30% below the weekday average, consistently across 6 months?") — and check it actually connects to my stated decision. If the answer wouldn't change the decision, say so and re-aim the question.

<task>
1. State the sharpened question and the decision rule — "if the answer is X, you do Y" — agreed before any analysis so the result can't be argued away later.
2. Specify the data needed: which of my named sources, which fields, what date range, and the join key if sources must combine. Unknowns become [NEEDED: check whether your POS export includes refunds] style items.
3. Choose the simplest method that can answer it with my tools — name the exact technique (pivot comparison, control chart, simple regression) and why nothing fancier is justified.
4. Define success for the PROJECT itself: answered by the deadline, within the effort budget, and decision-grade — state what makes it decision-grade (months covered, sample size).
5. Lay out the steps as a checklist with hour estimates: get data, clean the minimum needed, analyse, sanity-check, write the one-page answer.
6. List the 3 most likely ways this project fails (data doesn't go back far enough, the effect is seasonal) with a cheap early check for each.
</task>

<output_format>
Question and decision rule — data spec — method — success measures — step checklist with hours — risk list. One page equivalent.
</output_format>

Rules:
- Use only sources I named; never assume data exists.
- If my itch involves comparing staff performance, add one line: measure processes before people, and tell the team before measuring — measurement changes workplaces.
- Plain Australian English; every analytics term gets a plain-words gloss.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.

Want it tuned to your business? Bring it to the free weekly call and we'll adapt it live.

Join the free call

More coding & technical prompts

Keep a Two-Minute Daily Engineering Log That Pays Off Later

Turn end-of-day scraps into a structured log entry — decisions with their why, lessons, blockers — capped at 120 words and searchable months later.

Break a Stalled Decision With a Structured Tiebreak

Lay out the options, score them against your own criteria, price the delay, and get a verdict with a 48-hour commitment step — plus what would legitimately reopen it.

Engineer a Distraction-Proof Deep-Work Block

Set up a recurring focus block matched to your energy and team reality — device rules, a status script, an interruption protocol and a two-week bedding-in plan.