Y

Stakeholder management · Intermediate

The requirements conversation and the one-page brief

3 min read

Why it matters

Stakeholder management appeared in 78% of the Data Analyst job descriptions we read, more than Excel, Tableau or Python. The reason is simple: analysis that answers the wrong question, or arrives after the decision, is wasted. A short requirements conversation and a one-page brief prevent most of that waste.

The concept

In the first conversation, find out:

  1. The decision. What will you decide or change based on this? If nothing, the request may not need doing.

  2. The audience. Who reads the output, and what do they already know?

  3. The deadline and why. A board meeting on the 15th is a real deadline; "soon" is not.

  4. Definition of done. A number, a dashboard, a recommendation? What does good look like?

  5. Constraints. Data they know is unreliable, sensitivities, people you must involve.

Then write a one-page brief and ask them to confirm it. Written scope turns disagreements later into a quick check instead of an argument.

When priorities change, and they will, restate the trade-off: "I can add the regional split, but the deadline moves to Monday, or I drop the product breakdown. Which do you prefer?".

Worked example: a brief for a churn request

A sales head says: "Can you look at churn?". After a 20-minute conversation:

brief.md
# Brief: customer win-back analysis
Requested by: Head of Sales (Meera). Analyst: Asha. Date: 2 Sep.

Decision: whether to fund a win-back campaign before the September to November peak,
and which customers to target.

Question: Which previously frequent customers have stopped ordering, how much revenue
do they represent, and what did they buy?

Output: one-page memo with a recommendation, plus a list of target customers.
Not in scope: churn prediction model, pricing analysis.

Data: online retail order lines Dec 2010 to Dec 2011. Known issue: 25% of lines lack a customer id.

Definition of "at risk": ordered at least 3 times, but not in the last 60 days. (Agreed with Meera.)

Deadline: 9 Sep, for the 10 Sep planning meeting.
Check-in: draft numbers on 5 Sep.

With the definition agreed up front, nobody argues about "at risk" when the numbers arrive. The check-in on the 5th gives Meera a chance to redirect before the work is finished.

Common mistakes

  • Starting work after a hallway request. Confirm scope in writing, even in three lines.

  • Saying yes to everything. Every new request pushes something else out. Make the trade-off visible.

  • Going silent until the end. Share draft numbers early; surprises at the deadline are expensive.

  • Only talking to the requester. The people who own the data or will run the campaign often know the real constraints.

Interview angle

Behavioural questions such as "tell me about a time requirements changed" or "a stakeholder disagreed with your analysis" test this. Use a real example with the situation, what you did (brief, trade-off, check-in) and the outcome.

Practice task

  1. Write a one-page brief for a project you are doing now, including what is not in scope.

  2. Role-play a requirements conversation with a friend who plays a vague stakeholder. Use the five questions.

Further reading