How to Scope a Data Analysis Request With Stakeholders

A stakeholder asks, “Can you build a dashboard showing why deliveries are late?” You can write SQL and build charts, but neither skill tells you what the person intends to do with the answer. Do they need to contact customers, change a warehouse cutoff, compare carriers, or decide whether to add staff?

A useful first meeting turns that request into an analysis brief: the decision, the people responsible for it, the population and measures, the evidence available, and the conditions for calling the work complete. You can do this without arriving as an expert in every business process.

The worked example below is fictional. It shows how to conduct the conversation, capture the agreement, and handle uncertainty before a large query or dashboard commits you to the wrong question.

Find the people who can answer different questions

“The stakeholder” is often several people. A manager can explain the decision and deadline. An operator can show what happens to a difficult shipment. A data owner can explain where the timestamps come from. A metric owner can approve what “late” means.

Those roles may overlap. Identify them by responsibility instead of seniority. A senior sponsor may control the budget while a dispatcher knows why a delivery scan appears two days after the actual event.

Before the meeting, ask for an existing report, a recent example that prompted the request, and the names of people who know the workflow. Use the material to prepare specific questions, not to assume the old report is correct. Share a short purpose: “Agree what next week's delivery review needs to decide, and what evidence would support that decision.”

Open with the action and the deadline

Try this exchange:

Manager: We need a dashboard explaining late deliveries.
Analyst: What decision do you need to make after seeing it?
Manager: Whether to bring the packing cutoff forward at one warehouse.
Analyst: When will that decision happen, and what alternatives are still available?
Manager: Friday's operations review. We could move the cutoff, change a carrier pickup, or investigate further.

That answer changes the scope. You need evidence about where delays occur and which shipments are affected. A general dashboard of every delivery metric may not help before Friday.

Also ask what happens if the analysis is inconclusive. If the manager must make a decision regardless, they need a clearly stated uncertainty and an operational fallback. If the decision can wait, a short data-quality investigation may be the best first deliverable.

Make the initial question precise enough to test: “Among eligible parcels promised for last month, which warehouse and dispatch stage account for the largest number of missed delivery promises?” This is a descriptive investigation. Whether changing the cutoff will improve outcomes is a further question requiring additional evidence.

Walk one normal case and one exception through the process

Ask the operator to describe an actual shipment from order acceptance to delivery confirmation. Write down the stages in their language first: accepted, allocated, packed, handed to carrier, delivered. Beside each stage, record the person or system responsible, the event timestamp, and where the record is stored.

Then ask about an exception: a split order, a failed delivery attempt, a missing scan, or a promised date changed after dispatch. Exceptions expose ambiguity that a diagram of the ideal process misses.

Do not assume the database can reconstruct every stage. If it stores only a parcel's latest status, you may be unable to measure historical time spent in packing. Record that as a feasibility limit and ask whether an event history or retained export exists.

Turn business words into reviewable examples

Rather than asking “How do you define on-time performance?” in isolation, bring three or four concrete cases to classify. For example:

• A parcel delivered on its promised local calendar date: does it meet the promise?
• A parcel delivered after that date: is it a missed promise even if the customer accepted it?
• A parcel still undelivered after its due date: does it count as missed, or as unresolved pending investigation?
• A parcel whose promise was changed after purchase: which promise is the comparison against?

Write the agreed classifications beside the examples. The analyst implements the definition; the accountable business owner settles disputed meanings. If two teams need different definitions, name them separately. Calling both “on-time delivery” will create a reconciliation problem later.

Choose a cohort that matches the question. A report about commitments due in August should generally begin with those commitments, including unresolved outcomes under the agreed policy. Selecting only parcels delivered in August can omit overdue parcels and include parcels promised in another month.

Resolve a tiny parcel dataset before building the report

Use this fictional eight-parcel extract to test whether the meeting produced an implementable agreement. All dates are in America/Los_Angeles; the retained extract is complete through September 3, 2026. Each parcel ID is unique. Original promises are retained, and the dispatcher has confirmed the exception notes below.

The agreed rules are: include original promised dates from August 1 through August 31; exclude pre-dispatch cancellations; compare actual delivery against the original promise; count an undelivered, overdue parcel as a missed promise only when the source confirms it remains in transit. A delivered status without a trustworthy delivery date is insufficient evidence, rather than automatically late.

• P1. West: original promise August 10; delivered August 10. On time.
• P2. West: original promise August 10; revised promise August 12; delivered August 11. Delivered late against the original promise.
• P3. West: original promise August 31; confirmed still in transit at cutoff. Overdue without delivery.
• P4. East: original promise August 15; delivered August 14. On time.
• P5. East: original promise August 16; delivered August 17. Delivered late.
• P6. East: original promise August 20; status says delivered, but the delivery date is unavailable. Insufficient evidence.
• P7. West: original promise August 12; confirmed cancellation before dispatch. Excluded: cancellation.
• P8. East: original promise September 1; delivered August 31. Excluded: outside the promise-date cohort.

The reconciliation is 8 source parcels = 2 exclusions + 6 eligible parcels. Within the eligible population: 2 on time + 2 delivered late + 1 overdue + 1 insufficient evidence = 6. The three confirmed missed promises are P2, P3, and P5.

Do not present 3 / 5 = 60% as the full-cohort missed-promise rate: it removes P6, whose outcome is unresolved. Among the six known eligible parcels, confirmed misses give a lower bound of 3 / 6 = 50%. If P6 also missed its promise, the rate would be 4 / 6 = 66.7%. Report the unresolved count and the 50%–66.7% range until its evidence is recovered. This is an uncertainty bound for this fixture, not a statistical confidence interval.

Two deliberate changes reveal why the brief matters. Using P2's revised promise incorrectly removes one miss. Selecting parcels by delivery month incorrectly excludes overdue P3 and admits September-promise P8. Ask reviewers to explain those differences before approving the production metric.

The acceptance check is specific: the implementation must reproduce these eight classifications and the reconciliation totals. Then test the actual source's completeness, uniqueness, and history separately. Matching a teaching fixture alone does not prove the live data is trustworthy.

Leave with a completed analysis brief

Here is a filled example after the fictional meeting. Each entry is an agreement to confirm, not a default to copy into another organization.

The brief also needs named people and actual review times in a real project. Assign an owner and due date to each unresolved item, such as whether the original promise is retained. If that field is unavailable, agree whether an alternative measure is useful before building the comparison.

Agree what the first useful result looks like

Sketch the output with invented numbers before spending hours implementing it. Label the sketch clearly as illustrative. The aim is to test the decision flow: can the reader find the affected population, understand the comparison, and identify a next step?

Suppose the sketch shows 60 missed promises out of 1,000 eligible parcels at Warehouse West and 20 out of 100 at Warehouse East. West has more missed parcels; East has the higher rate. The right prioritization depends on the action, cost, and affected customers. A single “worst warehouse” ranking would conceal that choice.

Ask, “If the real result looked like this, what would you investigate first?” If the answer is “I still need the carrier split,” add that requirement now. If the answer is “I need individual staff performance,” discuss whether the data and assignment process support that use; do not quietly broaden the analysis.

Set acceptance conditions that can be checked: parcel IDs are unique after preparation; source and output totals reconcile with exclusions explained; unknown outcomes are visible; reviewed example parcels match the agreed classifications; the comparison includes counts as well as rates. Keep approval of business meaning separate from technical test results.

Make uncertainty and scope changes visible

Three common situations need different responses.

The stakeholder is unavailable. Send the brief for review through the team's normal process, highlight the few decisions that block progress, and ask who can delegate those decisions. Continue with reversible work such as source discovery or an explicitly provisional sketch. Silence does not confirm a metric definition.

Two teams disagree. Write each definition and show one example where the answers differ. Ask the person accountable for the decision to choose or retain both under distinct names. Avoid resolving a business dispute by picking whichever SQL is easier.

The request grows. Explain the tradeoff concretely: “Adding international parcels requires another promise calendar and carrier feed. We can keep Friday's domestic analysis, or move the deadline and expand the scope.” Record the decision and update the brief rather than allowing invisible changes to accumulate.

If the data cannot support the question, make that the finding. For example, “We can compare outcomes by warehouse, but cannot isolate packing delay because historical packing timestamps are absent.” Propose the smallest useful alternative and a way to collect the missing evidence for a future decision.

Close the meeting with a read-back

A concise closing statement might be:

For Friday, I will compare August delivery promises at parcel level, show warehouse, carrier, and service-tier differences, and investigate recorded delay stages. This will identify where to look, not establish that the cutoff caused the problem. The dispatcher will review sample classifications on Wednesday, and the data owner will confirm whether original promises are available. A permanent dashboard is a later decision.

Capture corrections and share the revised brief. At the review, lead with what the evidence supports, what remains uncertain, and the next action. A concentration of delays at one warehouse could reflect service mix, geography, or recording practices; an observed association alone does not prove an operational cause.

For a portfolio exercise, role-play this meeting and label every business assumption as fictional. Have another person challenge the promise definition or request a new breakdown. Producing a coherent brief after those challenges is useful practice for the part of analyst work that syntax exercises leave out.

Copy this brief for your next request

Copy the fields below into the team's normal document or ticket. Fill in what is known, assign unresolved items, and keep the status as draft until the accountable people confirm it. The blank fields are intentional for reuse.

# Analysis brief

Status: [draft / agreed, with date and approver]
Decision owner:
Decision and available actions:
Decision deadline:
Question this analysis will answer:
Population and exclusions:
Observation unit and unique key:
Metric definitions, numerators, and denominators:
Reporting period, time zone, and source cutoff:
Source owner and retained input identity:
Normal example and agreed classification:
Exception examples and agreed classifications:
Missing data / unresolved outcome policy:
Required breakdowns:
First deliverable and intended audience:
Acceptance checks and reviewers:
Out of scope:
Unresolved decisions — owner — due date:
Next review:
Changes agreed since the previous version:

Keep the normal and exception examples beside the definitions. When a rule changes, record the agreed change and update its expected examples so the brief and the implementation describe the same decision.

FAQ

How many questions should I ask in the first meeting?

Ask enough to establish the decision, scope, definitions, feasibility, and next review. Use a real case to keep the conversation concrete. Move unresolved details into a short list with owners rather than turning the meeting into an exhaustive interrogation.

What if they insist they only want a dashboard?

Ask who will use it, what they will decide, and how often that decision occurs. Demonstrate the proposed output with a sketch. A recurring dashboard may be appropriate, but its measures and intended use still need agreement.

Can I start querying before the brief is approved?

Exploratory queries can establish whether sources and fields exist, using your approved access. Keep their results provisional. Do not distribute an unconfirmed metric as an agreed business answer, and do not let exploratory work silently expand the commitment.

How does this connect to SQL practice?

Once the brief is clear, use the guide to building a SQL query from scratch. For related concepts, read business domain knowledge, metric reconciliation, and operating a recurring report.