A stakeholder asked me, partway through a churn analysis, whether I could also break the results out by acquisition channel. It was a Tuesday, the ask took ten seconds to say, and I said yes before I had worked out what it actually meant. Acquisition channel was not a column sitting cleanly in the dataset I already had. It lived in a separate marketing system, joined on a customer ID that turned out to be inconsistently formatted between the two, and the “can you also” that took ten seconds to ask cost the better part of two days to deliver. Nobody was wrong to ask. I was wrong to agree without costing it first, and that gap, between how cheap a scope change sounds and how expensive it actually is, is most of what I want to write about here.
I spent a stretch this year working through formal project management structures, PMBOK among them, expecting the material to feel like overhead layered on top of the technical work I actually cared about. It did not turn out that way. Analysis that never reaches the person who needed it, because the scope wandered, the timeline blew out, or nobody agreed in advance what “done” looked like, is not analysis that helped anyone. Technical skill produces a model or a dashboard. Scope discipline is what gets it in front of the person who asked for it, on a timeline they can plan around.
Why data projects do not fit the SDLC shape
Traditional software delivery, at least the version PMBOK assumes as a starting point, runs roughly linear: gather requirements, design against them, build, test, deploy. Each phase depends on the one before it being reasonably settled, and scope gets locked early because the cost of changing it climbs sharply the further along the timeline you are. That structure works when the thing being built is knowable in advance. A login form has a bounded, describable shape before a single line of code exists.
A data science project does not have that property, and the reason is not a difference in maturity. It is structural. The central activity, exploring what a dataset actually contains, cannot happen before the project starts, because the dataset is the thing being investigated. You cannot fully specify the deliverable before you have looked at the data, because what the data supports is itself one of the open questions. A churn model brief might promise “predict which customers are likely to leave next quarter,” which sounds like a clean, boundable requirement right up until exploration reveals that the field recording contract renewal dates is only populated for sixty percent of customers, which changes what the model can honestly claim to predict, which changes the deliverable, which was supposed to have been fixed before work began.
That loop between exploration, modelling, and evaluation is not a sign of poor planning. It is the actual shape of the work. A model gets built against an initial feature set, evaluation reveals it is weak on a particular segment, that finding sends you back to explore whether an additional data source could help, and the cycle repeats until the result is good enough to act on or the remaining time runs out. PMBOK’s process groups, initiating, planning, executing, monitoring, closing, still apply, but “planning” cannot mean locking the deliverable the way it would for a bounded software build. It has to mean deciding how much iteration the timeline can absorb, and being honest with a stakeholder up front that the exact shape of the answer is one of the unknowns the project exists to resolve.
Scope, time, cost, and the fourth thing nobody draws
The classic project management triangle puts scope, time, and cost on three corners and treats them as a trade space: fix any two, and the third follows. Push scope up without adding time or budget and quality suffers. That framing works reasonably well when uncertainty is low, when the thing being delivered is well understood before work starts. Data projects break that assumption in a specific, measurable way. Uncertainty is highest right at the start, precisely when a traditional plan wants scope locked, because you genuinely do not know yet what the data will support until you have spent time inside it.
The practical consequence is that scope has to be the flexible corner on a data project, not the fixed one. Time and cost are usually the constraints a stakeholder actually cares about protecting, a board update is due on a set date regardless of what the data turns out to show, and if scope is forced to stay fixed against that same deadline while uncertainty is still high, the project either slips the deadline, ships something weaker than promised, or the person running it starts quietly cutting corners nobody agreed to. None of those are good outcomes, and all three are avoidable by naming scope as provisional from the start rather than discovering the mismatch under deadline pressure.
Requirements analysis when the requirement cannot be fully known yet
Ordinary requirements gathering asks a stakeholder what they need and writes it down. That works when the stakeholder can describe the need accurately, which assumes they already understand what the data can plausibly deliver. Most of the time, on a data project, they do not, not because they are unclear thinkers but because knowing what a dataset supports is exactly the specialised knowledge they came to a data analyst for in the first place. Asking “what do you need” and treating the answer as fixed scope skips the step where that need gets translated into something the data can actually answer, and that translation step is where most scope creep quietly gets born.
The fix I settled on was smaller than it sounds: separate the business question, which a stakeholder is well placed to define and which rarely changes, from the analytical approach, which is mine to propose and revise as exploration reveals what is actually feasible. “Which customers are likely to leave next quarter” is a stable business question. “A logistic regression against six months of usage and support-ticket features, refined once we see which are informative” is an analytical approach, and I say it out loud as provisional, subject to revision once the data is in front of me, rather than letting it get treated as a locked spec the way a login form’s field list would be.
That separation also gives a cleaner answer to the acquisition-channel request I opened with. The business question had not changed. The analytical approach had, meaningfully, because a new join across an inconsistent key is a different piece of work to a groupby on a column already sitting in the table. Naming that distinction out loud, in the moment the request lands rather than after the two days were already spent, is the entire difference between an agreed scope change and quiet, absorbed scope creep.
Waterfall instincts, agile reality
None of this is an argument for running data projects as pure agile sprints either, at least not without adaptation. A two-week sprint boundary assumes work chunks into roughly equal, independently deliverable slices, and exploratory data work resists that shape as much as it resists waterfall’s upfront lock. Some weeks produce a working model. Others produce the finding that a promising feature is a leakage artefact and has to be dropped, which looks like zero forward progress on a sprint board while being exactly the information the project needed to avoid shipping something wrong.
What actually worked was closer to fixed-cadence checkpoints with genuinely flexible content: a standing update at a set interval, regardless of what got that far, where the content of the update is allowed to be “here is what we ruled out and why” as legitimately as “here is a working result.” Stakeholders track progress by trusting the cadence rather than needing every checkpoint to show forward momentum in the deliverable itself. That trust has to be built deliberately, because the instinct on the other side of the table is usually still waterfall shaped, a checkpoint that reports “the segmentation feature did not hold up” reads as bad news to someone expecting straightforward progress, when it is often the single most useful thing the checkpoint could have surfaced.
Technical competence is what lets an analysis be correct. It says nothing about whether that analysis reaches the right person, on a timeline that respects their constraints, without the scope silently doubling somewhere in the middle. That second part is a discipline of its own, and it is not one most technical training covers, because it looks like paperwork right up until the week a project without it quietly goes twice over budget and nobody can point to the single decision that caused it.