The Analytics Workflow: Day-in-the-Life¶

Textbooks describe analytics as a clean, linear process. Real analytics work is messier, more political, and more rewarding than the textbook version. This file shows you what a week actually looks like — how projects start, how scope changes, how you manage competing stakeholders, and how you decide when "good enough" is good enough.

Learning Objectives¶

Translate a vague stakeholder request into a scoped, answerable analytics question
Understand the realistic time breakdown of analytics work (and why cleaning dominates)
Know the deliverable formats for different audiences and how to choose between them
Communicate findings in a way that leads to decisions, not just acknowledgment

How Projects Actually Start¶

Analytics projects almost never start with a clean brief. They start with one of four triggers:

Trigger 1: The Urgent Question¶

"Something is off in the dashboard. Can you look into it?"

This is the most common. Something looks wrong — a number spiked or dropped — and leadership wants an explanation by EOD. You have 4 hours.

What to do immediately: 1. Pull the raw number to confirm the anomaly is real (not a display bug) 2. Check if it is a data pipeline issue (is the underlying table updated?) 3. If the data is valid, start segmenting to find where the anomaly is concentrated 4. Set an expectation: "I'll have a preliminary finding in 2 hours and a full analysis by EOD."

Trigger 2: The Recurring Request¶

"We need the weekly sales report by Monday morning."

This is often the least exciting and most time-consuming work for junior analysts. The goal is to automate it as quickly as possible.

Signs it should be automated: - The same query runs every week - The same data is pasted into the same Excel template - The same email goes to the same distribution list - No one ever asks follow-up questions about it

For mid-level analysts

If you have been manually producing a recurring report for more than 4 weeks, write the automation ticket. Use that time budget to argue for a scheduled query + auto-emailed PDF in your BI tool. Protect your time for work that requires judgment.

Trigger 3: The Strategic Initiative¶

"We're launching a new product segment in Q2. We need a market sizing analysis, a competitive benchmark, and a demand forecast."

This is the most valuable type of project — high impact, longer timeline, real decision attached. It also has the most scope creep risk.

What to do first: Write a project scope document before touching a query.

ANALYTICS PROJECT BRIEF
=======================
Requestor:    [Name, Title]
Date:         [Date]
Due Date:     [Date]

Business Question:
  [One specific, answerable sentence]

Why Now:
  [What decision this analysis enables]

Scope:
  - IN SCOPE: [specific questions this analysis will answer]
  - OUT OF SCOPE: [things that will NOT be covered]

Data Sources:
  [Where the data comes from; any known quality issues]

Deliverable:
  [What they will receive: slide deck, dashboard, spreadsheet]

Key Assumptions:
  [Any assumptions that, if wrong, would change the analysis]

Success Criterion:
  [How stakeholder will know this analysis is complete and useful]

This document takes 30 minutes to write. It prevents 30 hours of rework.

Trigger 4: The Self-Initiated Investigation¶

You noticed something interesting in the data. You pitch it.

This is the mark of a senior analyst — proactive, not reactive. You spotted a pattern no one asked about, scoped it yourself, and brought a finding with a recommendation.

The risk: Spending time on analyses that do not connect to a decision. Before you go deep on a self-initiated investigation, ask: "If my finding is X, what does the business do differently?" If the answer is "nothing," you are doing interesting work, not valuable work.

Scoping: Translating Business Questions into Analytics Questions¶

Scoping is a skill. It is learned through practice. Here are the questions that sharpen a brief:

Scoping Question	Why It Matters
"What decision will you make based on this analysis?"	Prevents building analyses that get filed away unused
"What would you do if the answer is A? What if it's B?"	Reveals whether the decision is actually pre-made
"What timeframe are we looking at?"	Prevents ambiguous comparisons
"Which customer segments / regions / products are in scope?"	Prevents scope creep post-delivery
"How granular does this need to be?"	Determines whether you need summary or detail
"Who else needs to see this output?"	Shapes format and depth
"When do you need it — and what is the hard deadline vs preferred deadline?"	Surfaces the real timeline
"What do you already believe the answer is?"	Surfaces prior hypotheses; lets you challenge or confirm

The pre-decided analysis trap

Sometimes a stakeholder already knows what they want the data to say. They are looking for confirmation, not insight. The tell: "We believe X — can you show that in the data?"

Your job is to be intellectually honest, not to produce confirmation. Pull the data. If it confirms X, great. If it does not, you say so — diplomatically, clearly, and with evidence. An analyst who produces what the stakeholder wants to hear loses credibility fast when decisions based on that analysis fail.

For senior analysts

When stakeholders have strong priors, try: "I'll test that hypothesis and also look for alternative explanations — that way we have the full picture for the meeting." This frames you as thorough rather than adversarial, while preserving your analytical independence.

The 80/20 Reality of Analytics Work¶

Here is an honest breakdown of how analyst time is actually spent:

Typical analytics project time allocation:

┌─────────────────────────────────────────────────────────┐
│  Data discovery & access (10%)                          │
│  Finding where data lives, getting permissions,         │
│  understanding table schemas, talking to engineers      │
├─────────────────────────────────────────────────────────┤
│  Data cleaning & preparation (55–65%)                   │
│  Deduplication, standardization, joins, handling        │
│  nulls, validating numbers against source of truth      │
├─────────────────────────────────────────────────────────┤
│  Analysis & modeling (15–20%)                           │
│  Running queries, computing metrics, building the       │
│  model, interpreting outputs                            │
├─────────────────────────────────────────────────────────┤
│  Visualization & communication (10–15%)                 │
│  Building the chart, writing the narrative,             │
│  preparing for the stakeholder conversation             │
└─────────────────────────────────────────────────────────┘

This is not a sign of inefficiency. This is the nature of the work. Data is generated by humans using imperfect systems. Cleaning it requires judgment, documentation, and domain knowledge — all things that take time.

What good looks like

A senior analyst who produces a clean, well-documented analysis in 3 days is more valuable than a junior analyst who produces an undocumented analysis in 1 day. Speed matters, but reproducibility and trust matter more. An analysis you cannot explain in a stakeholder meeting is an analysis that will not change anything.

Deliverable Formats: Choosing the Right Output¶

The same analysis can be delivered in radically different formats depending on the audience. Choosing the wrong format is the analyst equivalent of giving a speech in the wrong language.

Format 1: Executive Summary (slide deck, 3–5 slides)¶

Use when: The audience is VP-level or above. The decision is strategic. The audience has 15 minutes.

Structure: - Slide 1: The finding in one sentence + the recommendation - Slide 2: The key evidence (2–3 charts maximum) - Slide 3: Implications and next steps - Backup slides: Detail, methodology, caveats

Tone: Confident. Lead with conclusions. No methodology unless asked.

Format 2: Operational Dashboard¶

Use when: The same metrics need to be monitored regularly. The audience is operational (sales manager, operations lead, finance team). Decisions are frequent and tactical.

Design rules: - Maximum 6–8 KPIs visible without scrolling - Traffic light indicators (green/yellow/red) for target vs actual - Trend line for every KPI, not just current value - Filters by segment, date range, and region - Auto-refresh cadence matched to decision cycle (daily for ops, weekly for sales, monthly for finance)

Format 3: Analytical Deep Dive (spreadsheet or notebook)¶

Use when: The audience is analytical (finance team, a fellow analyst, an engineer). They want to see the work. They will audit it. The decision has high stakes.

Design rules: - Separate tabs: Raw data / Cleaned data / Analysis / Summary - Every number should be traceable back to a source - Document assumptions in a dedicated section - Color-code inputs (blue) vs calculations (black) per Excel convention - Version control: include a change log tab

Format 4: Ad-hoc Query Results¶

Use when: A stakeholder needs a specific number quickly. There is no recurring need. A table or quick email summary is sufficient.

Mistake to avoid: Over-engineering ad-hoc requests. Not everything needs a dashboard. Sometimes the right deliverable is a screenshot of a SQL result with two sentences of context.

Stakeholder Communication: When to Push Back and How¶

Communication is a core analyst skill. You will spend as much time talking about data as analyzing it.

When to push back on a request¶

Push back when: - The timeline is impossible and rushing will produce a wrong answer - The scope is so broad that no meaningful answer is possible - The data needed does not exist or is not trustworthy - The analysis is designed to confirm a decision already made (and would be used to mislead) - The question being asked is the wrong question for the actual business problem

How to push back without being difficult:

Instead of: "That's not possible in 2 days." Say: "To do this rigorously, I need 4 days. I can give you a preliminary read in 2 days — but I want to flag that it won't have the full data validation. Should I proceed on that basis?"

Instead of: "That data is garbage." Say: "I found some data quality issues that will affect the analysis. Before I proceed, I want to walk you through what I found — it may change what question we're actually answering."

Instead of: "That's the wrong question." Say: "The question you've asked will give us X. I want to make sure that's actually what you need for the decision — can you tell me more about what's driving this?"

Managing competing priorities¶

When multiple stakeholders need things simultaneously:

Triage by decision impact — which analysis will change a larger decision? That one goes first.
Set expectations explicitly — email stakeholders with your queue and expected completion dates. Silence creates anxiety.
Negotiate, do not disappear — "I can get you the full analysis on Thursday, or a rough cut on Tuesday — which serves you better?"
Escalate when the queue is truly impossible — your manager should know when the workload is unsustainable. Document requests you could not complete.

For senior analysts

Build a simple intake process — even a shared spreadsheet or Jira board — where stakeholders log analytics requests. It creates visibility, allows you to prioritize systematically, and gives leadership data on demand vs capacity. This is the foundation for making the case to grow the analytics team.

Quality Checks Before You Deliver¶

Every analysis should pass this checklist before it goes to a stakeholder:

Pre-delivery checklist:
□ Does the total match a known benchmark (e.g., total revenue matches finance's actuals)?
□ Does the trend directionally make sense (e.g., Q4 should be higher than Q3 for this business)?
□ Have you checked for and handled NULLs and zeros?
□ Does the denominator in your percentage calculations handle zeros?
□ Have you excluded test records, internal users, and refunds (if applicable)?
□ Does the date range include the right start and end?
□ If you joined tables, have you checked for unexpected row multiplication (fan-out)?
□ Have you spot-checked 5–10 individual records against the source system?
□ Have you written down the caveats and limitations?
□ Is your naming consistent (same metric called the same thing everywhere)?

The join fan-out check is the one most often missed:

-- Check for fan-out after a join
-- If this count is higher than the count of your starting table, you have a problem
SELECT COUNT(*) AS row_count
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id;

-- Compare to:
SELECT COUNT(*) FROM orders;  -- should be equal or orders count is lower

The fan-out bug

Joining a one-to-many relationship without aggregating first is one of the most common and hardest-to-detect bugs in analytics. If customer A has 3 rows in the addresses table and you join orders to customers_addresses without handling the cardinality, every order for customer A now appears 3 times. Your revenue total is 3x actual.

End-of-Day Habits for Senior Analysts¶

What separates a good analyst from a great one is not intelligence — it is habits:

Document your work — every query that answered a business question should be saved somewhere retrievable. You will get that question again in 6 months.
Communicate progress, not just completion — a mid-project "here is what I've found so far, here is what I'm still investigating" builds trust and surfaces misalignments early.
Keep a decision log — for every project, note what the business decided and what they actually did. This feedback loop is how you calibrate your own analysis quality.
Know your numbers — know the top-line KPIs for your domain cold. Revenue, customers, conversion rate, churn rate. When leadership asks "how are we doing?" in the hallway, you should not need to look it up.
Build for the person who comes after you — name your queries and dashboards clearly. Write a one-paragraph README for any analysis that took more than a day. Someone will need to rerun this after you change roles.

Previous: 03-business-use-cases | Next: 05-real-world-case-studies