The Data Science Workflow

Jr Codex Data Science Notes

Level: Advanced Prerequisites: Module 5: Experimentation & Applied Statistics Time to complete: ~20 minutes

Why a Formal Workflow Matters
CRISP-DM — the Standard Framework
Business Understanding
Data Understanding & Preparation
Modeling & Evaluation
Deployment
The Workflow Is a Loop, Not a Line
Summary & Next Steps

1. Why a Formal Workflow Matters

Every technique across Modules 1-5 — statistics, wrangling, EDA, visualization, experimentation — is a tool. A workflow is the discipline of using those tools in the right order, for the right reasons, on a real project with a deadline and a stakeholder waiting for an answer.

Without a Workflow                    With a Workflow
─────────────────────────────         ─────────────────────────────
  Jump straight to building a           Clarify the actual question FIRST,
  fancy model on whatever data           then gather/clean the RIGHT data,
  is easiest to grab                      then analyze with purpose
  → often solves the WRONG problem        → solves the RIGHT problem, efficiently
─────────────────────────────         ─────────────────────────────

2. CRISP-DM — the Standard Framework

CRISP-DM (Cross-Industry Standard Process for Data Mining) is the most widely used framework for structuring a data science project, dating back decades but still the practical default across the industry.

CRISP-DM — the Six Phases
─────────────────────────────────────────
  1. Business Understanding    → what problem are we ACTUALLY solving?
  2. Data Understanding          → what data do we have, and is it any good? (Module 3)
  3. Data Preparation              → cleaning, wrangling, feature engineering (Module 2)
  4. Modeling                        → building the analysis or model
                                        (the Machine Learning notes, for predictive modeling)
  5. Evaluation                         → does this ACTUALLY answer the business question?
  6. Deployment                           → putting the result into someone's hands, for real use
─────────────────────────────────────────

                ┌─────────────────────────┐
                │  Business Understanding  │◄──────┐
                └───────────┬─────────────┘        │
                            ▼                        │
                ┌─────────────────────────┐          │
                │   Data Understanding     │          │
                └───────────┬─────────────┘          │
                            ▼                          │
                ┌─────────────────────────┐            │
                │   Data Preparation        │            │
                └───────────┬─────────────┘              │
                            ▼                              │
                ┌─────────────────────────┐                │
                │       Modeling            │                │
                └───────────┬─────────────┘                  │
                            ▼                                  │
                ┌─────────────────────────┐                    │
                │      Evaluation           ├────────────────────┘
                └───────────┬─────────────┘   (loops back if the answer
                            ▼                    doesn't hold up — Section 7)
                ┌─────────────────────────┐
                │      Deployment           │
                └─────────────────────────┘

3. Business Understanding

The most frequently skipped, most consequential phase — before touching any data, get precise about the actual question.

Vague Question                        Precise, Actionable Question
─────────────────────────────         ─────────────────────────────
  "Understand our customers"            "Which customer segment has the
                                          highest 12-month churn risk, and
                                          what's the top 3 predictors of it?"

  "Look at sales data"                    "Did the West region's marketing
                                            campaign in Q2 actually cause a
                                            measurable lift in sales, or would
                                            we expect this from seasonality alone?"
─────────────────────────────         ─────────────────────────────

Questions to Ask Stakeholders Before Starting
─────────────────────────────────────────
  - What DECISION will this analysis actually inform?
  - What does "success" look like, concretely?
  - Is there a specific, existing hypothesis to test (Module 5),
    or is this open-ended exploration (Module 3)?
  - Who is the AUDIENCE for the final result? (Module 5, Ch.5)
─────────────────────────────────────────

A vague starting question almost always leads to a vague, unusable answer — no amount of statistical rigor downstream fixes a poorly-framed question upstream.

4. Data Understanding & Preparation

These phases map directly onto Modules 2-3 of this curriculum:

CRISP-DM Phase          Maps To
─────────────────────────────────────────
  Data Understanding    → Module 2, Ch.1 (data sources) + Module 3
                            (EDA workflow, univariate/bivariate analysis)
  Data Preparation        → Module 2, Ch.3-5 (cleaning, missing data,
                              feature engineering)
─────────────────────────────────────────

In practice, these two phases consume the majority of project time — a fact worth setting stakeholder expectations around explicitly, since "why isn't there a chart yet after two weeks?" is a common friction point when this isn't communicated up front.

5. Modeling & Evaluation

"Modeling" in CRISP-DM is broader than machine learning specifically — it includes any structured analysis: a hypothesis test (Module 1, Ch.6), an A/B test (Module 5, Ch.1), a statistical model, or (for predictive tasks) a full ML model, covered in this curriculum's Machine Learning notes.

# The EVALUATION phase always asks: does this answer the ORIGINAL business question?
# Not just: "is the p-value below 0.05?" or "is the model's accuracy high?"
 
# Example: Business Understanding asked "will this checkout change increase REVENUE?"
# A model/test that only shows increased CLICKS, without checking revenue itself,
# has NOT actually answered the business question yet.

Evaluation is where Module 5, Chapter 2's "statistical vs practical significance" distinction gets applied at the project level — a technically valid, statistically significant result that doesn't move the metric the business actually cares about is not yet a finished evaluation.

6. Deployment

The step most technical training under-emphasizes, and the one that actually delivers value — an analysis sitting in a notebook, unread, has not been deployed in any meaningful sense.

What "Deployment" Can Mean, Depending on the Project
─────────────────────────────────────────
  A one-time analysis:    a written report/presentation (Module 5, Ch.5)
  A recurring need:         a dashboard (Module 4, Ch.5) that stakeholders
                              check themselves, on their own schedule
  A decision to make once:    a clear recommendation, delivered directly
                                to the person who needs to act on it
  A predictive system:          an actual deployed model — covered in the
                                  Machine Learning notes' production chapter
─────────────────────────────────────────

The right deployment format depends entirely on how the result will actually be used — building an elaborate real-time dashboard for a one-time strategic decision is often wasted effort; conversely, a one-off report for a question stakeholders will keep re-asking monthly creates unnecessary repeat work.

7. The Workflow Is a Loop, Not a Line

Real projects rarely move cleanly through all six phases once — Evaluation frequently sends you back to earlier phases.

Common Loop-Backs
─────────────────────────────────────────
  Evaluation reveals the data was missing a key variable
    → back to Data Understanding

  Evaluation reveals the ORIGINAL business question was
  slightly wrong, once you saw what the data could actually show
    → back to Business Understanding (this is NORMAL, not a failure)

  A stakeholder sees an early result and realizes they actually
  care about a DIFFERENT segment
    → back to Business Understanding, again
─────────────────────────────────────────

This iterative nature is a feature of doing the work well, not a sign something went wrong — treating CRISP-DM as a strict, one-pass checklist rather than an iterative loop is itself a common project-management mistake.

8. Summary & Next Steps

Key Takeaways

CRISP-DM structures a project into Business Understanding, Data Understanding, Data Preparation, Modeling, Evaluation, and Deployment — a framework that organizes every technique from Modules 1-5 into a coherent whole.
Business Understanding is the most frequently skipped phase, and the one most likely to make everything downstream useless if rushed.
Data Understanding and Preparation typically consume most of a project's actual time — set this expectation with stakeholders explicitly.
Evaluation must check whether the original business question was answered, not just whether a statistical test passed.
The workflow loops — evaluation routinely sends a project back to an earlier phase, and that's normal, healthy iteration, not failure.

Concept Check

Why is "Business Understanding" often described as the most consequential phase, despite involving no data analysis itself?
What's the difference between a model being "statistically valid" and the project's Evaluation phase being complete?
Why might a project legitimately loop back from Evaluation to Business Understanding?

Next Chapter

→ Chapter 2: Working with Data at Scale

Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index