The Workflow of a Data Science Project

A data science project looks superficially similar and ends somewhere completely different. Machine learning ends with software running. Data science ends with a human making a better decision.

The stages

📅 Timeline

1. Collect dataAssemble whatever is relevant to the question. Often the same raw material a machine learning project would use.

2. Analyse the dataExplore, visualise, test hypotheses. Highly iterative — most hypotheses fail, and that is the work rather than a failure of it.

3. Suggest hypotheses and actionsTurn findings into recommendations, present them, and — the part that actually matters — get a decision made and implemented.

Stage 2 loops even more than in machine learning. An analyst forms a hypothesis, tests it, finds nothing, forms another. Dozens of dead ends per useful finding is normal. Sponsors who expect a steady march of insights will conclude the analyst is unproductive when they are doing exactly the right thing.

When you need analysis and not a model

The most useful thing in this lesson is the ability to tell these apart early, because picking the wrong one wastes a quarter.

🔗 Match the Pairs

Why did returns increase 18% last quarter?Drop here

Which of these 40,000 orders is likely fraudulent?Drop here

Should we open a second location, and where?Drop here

Which support tickets should be escalated automatically?Drop here

What kinds of customer churn, and what do they have in common?Drop here

Estimate the delivery time for each new orderDrop here

The pattern: if the answer is needed once, it is analysis. If the same kind of judgement is needed thousands of times, it is machine learning.

There is a second cue. If the question starts with why, it is almost always analysis. Models are very good at what will happen and very poor at why it happened.

Why this matters to every job function

You do not need to become an analyst. You do need enough fluency to do three things, and they apply whether you work in marketing, finance, operations or HR.

1. Ask a question that can actually be answered. "Is our marketing working?" cannot be answered. "Did customers acquired through the March campaign have a lower six-month retention rate than those from February?" can be.

2. Recognise when a number is being oversold. The most common problems are a sample too small to conclude anything, a comparison between groups that differ in ways nobody controlled for, and — endlessly — a correlation presented as a cause. Ice cream sales and drowning deaths rise together; neither causes the other.

3. Know what data your own function produces, and how good it is. You are the person who knows that the "lead source" field is filled in properly by two salespeople and guessed by the rest. That knowledge is invaluable to an analyst and invisible to them. Volunteering it early prevents a confident, wrong analysis.

An operations director asks: "Can we use AI to reduce warehouse picking errors?"

An inexperienced team hears a machine learning request and starts scoping a computer vision system to verify picks.

A better first move costs a week and no technology. Look at the errors that already happened, and count them by cause. In a real warehouse that analysis usually finds something like: a third of errors concentrate on a small number of SKUs with near-identical packaging; another chunk cluster in the final hour of a shift; another are one supplier whose cartons are mislabelled on arrival.

Now the picture has changed completely. The near-identical packaging is fixed by changing bin locations or adding a colour band — no AI required, and it can be done next week. The end-of-shift cluster is a staffing or fatigue question. The supplier problem is a procurement conversation.

Perhaps a quarter of the errors remain as genuinely random human slips, and that residue might justify a verification system — now with a realistic estimate of the benefit, because you know exactly how many errors it could catch.

The generalisable move: before building a model to predict or prevent something, analyse the something. It frequently turns out that most of the problem has a cheaper cause, and you find out what the AI project would actually be worth. Analysis is also far cheaper and faster than modelling, which makes it the right first step even when a model is eventually the answer.

❓ Knowledge Check

A marketing director asks, "Why did our conversion rate drop last month?" What kind of project is this?

📚 Flashcards1 / 5

Term

Data science workflow

Click to flip

Definition

Collect data, analyse it iteratively, then suggest hypotheses and actions. The deliverable is a decision that gets made and implemented, not a running system.

Click to flip back

💡Key Takeaway

Data science ends in a decision; machine learning ends in a deployed system. Tell them apart by asking whether the answer is needed once or thousands of times, and whether the question begins with "why". You do not need to run the analysis yourself, but every function benefits from three habits: ask questions specific enough to answer, notice when a correlation is being sold as a cause, and speak up about how reliable your own data really is.