14.1 Defining the Business Problem

Before any data is loaded, before any code is written, we need to know exactly what we have been asked to do. The HR director’s initial email read, in full:

“We’ve had a lot more unplanned absences over the last couple of years. Can you take a look at the data and tell us what’s going on? Bonus points if you can flag the people most likely to become a problem so we can do something about it.”

This is a typical first contact. It is short, well-meaning, and dangerously underspecified. Three different analysts could read this email and produce three completely different projects: one might build an interactive dashboard, another a regression model, a third a clustering analysis to segment employees. None of these would be wrong, exactly — but at most one of them is what HR actually needs.

The first job of a spec-driven analyst is therefore not to start writing code. It is to ask questions until the request becomes a problem statement. A useful set of starter questions, drawn from the spec components introduced in Chapter 13:

  1. Who decides whether the project is done? Identify the primary stakeholder and any reviewers who will sign off on deliverables.
  2. What decision will this analysis support? Wellness program design, staffing changes, and disciplinary policy each imply a different deliverable.
  3. What does “a problem” employee mean? Is high absenteeism defined by total hours, frequency, or unplanned absence only?
  4. Who is the audience for the results, and how technical are they? This determines whether deliverables are notebooks, slide decks, or a one-page summary.
  5. What are the constraints? Data access windows, timeline, and ethical limits on which variables may be used as predictors.

After a fifteen-minute conversation with the HR director, the analyst leaves with a much sharper picture. The HR team is designing a wellness program for the upcoming fiscal year and needs (a) a defensible explanation of which employee characteristics drive chronic absenteeism, and (b) a ranked list of current employees most at risk. They define “chronic” as more than 40 hours of absenteeism in a quarter — a threshold borrowed from a previous internal report. The audience is a mix of HR managers and senior leadership, so deliverables must be readable without statistical training. Protected characteristics — gender, ethnicity, religion — must not be used as predictors. The analysis is due in two weeks, with an interim check-in at the end of week one.

This narrative is now concrete enough to write down. In the next section we capture it formally as a Business Requirements Specification.