Scope a Data Project End to End Before Touching the Data
Get a sharpened question, a decision rule, a data spec, the simplest defensible method and an hour-by-hour checklist.
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 callMore 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.