The Role of Business Tasks in Data Analysis#

🌱 Foundations 🧰 Tools, Applications & Ethics Lesson 025

Important

✨ AI-generated content. This page was written with the assistance of an AI language model and is provided as a learning aid. Despite careful review, it may still contain mistakes, omissions, or out-of-date information. Whether you are new to the topic, a team lead, or a senior practitioner, treat it as a starting point rather than an authoritative reference: read it critically and independently verify anything you act on (code, commands, figures, and factual claims) against official documentation and primary sources before relying on it.

The question behind the work#

A business task is the question or problem that a data analysis answers for a business. It is the anchor of the entire six-phase process: the Ask phase exists to define it, every later phase is judged against it, and an analysis without one is activity without purpose. This short lesson makes the concept precise, because “we analysed the data” means nothing until you can say which task the analysis served.

From situation to task#

Business tasks rarely arrive well-formed. They arrive as situations — “sales are down”, “customers are complaining”, “we’re launching in a new city” — and the analyst’s first job is converting the situation into a task: specific, answerable with data, and attached to a decision.

Situation: afternoon sales feel weak. Task: identify which stores’ 2–5 pm sales fall below their own trailing average, and what distinguishes them — feeding a staffing and promotion decision.
Situation: we want more members. Task: determine how casual riders and members use the service differently — feeding a marketing decision.
Situation: the warehouse seems slow. Task: measure where time is spent between order and shipment — feeding a process decision.

The pattern: a task names the comparison or measurement to perform and the decision waiting on it. If you cannot state both, the Ask phase is not finished.

Why the task governs everything#

Each phase consults the task. Prepare asks: what data bears on this question? Process asks: clean to what standard this decision needs? Analyze asks: does this computation move this question forward? Share asks: what does the decision-maker need to understand? Scope creep, rabbit holes, and beautiful-but-irrelevant charts are all, at bottom, moments when work detached from the task. The cheapest project-management tool an analyst owns is rereading the task statement.

The caveat#

Tasks can be wrong. Sometimes honest work reveals that the stated task misdiagnoses the situation — sales are not “down”, they moved channels — and the analyst’s duty is to surface that, not to answer the broken question faithfully. A business task is the anchor of the analysis, not a gag order on what the data actually shows.

Hint