Why Policy Analysis Fails to Change Anything: What Business Analysts Get Right That Policy Teams Often Miss
I’ll say upfront that I’m not a policy analyst by training. My background is business analysis — fifteen years of translating messy organizational reality into requirements, options, and recommendations that stakeholders can actually act on, much of it inside Salesforce implementations. But over the years I’ve worked alongside enough policy teams, in both corporate and public-sector-adjacent contexts, to notice something that keeps surprising me: a genuinely well-researched policy analysis, full of rigorous descriptive and prescriptive modeling, often changes nothing. It gets filed. It gets cited in a follow-up meeting. And then the organization keeps doing exactly what it was doing before.
That’s a strange outcome for work that’s usually more technically sound than most business analysis I’ve reviewed. Policy analysts tend to be excellent at the analytical core of the job — comparing alternatives, modeling outcomes, weighing tradeoffs against defined criteria. What I’ve noticed, watching this from the business analysis side, is that the failure point isn’t usually the analysis itself. It’s almost always what happens on either side of it — how the question got framed before the analysis started, and how the recommendation gets carried into a decision after it’s finished. Those are exactly the two places where business analysis, as a discipline, has spent decades building muscle that a lot of policy work still treats as secondary.
The framing problem: analyzing the wrong question well
In business analysis, one of the first things you learn — usually the hard way, by delivering a technically correct answer to a question nobody actually needed answered — is that requirements gathering isn’t really about collecting a list of what stakeholders say they want. It’s about figuring out what decision they’re actually trying to make, because those two things diverge more often than people expect.
I’ve seen the same pattern show up in policy analysis work more than once. A team is asked to evaluate three alternative approaches to a resource allocation problem, and they do it well — clean comparative modeling, solid data, defensible assumptions. But the underlying disagreement driving the request wasn’t really about which allocation approach performed best on the stated criteria. It was about two departments who fundamentally disagreed on what the criteria should be in the first place, and neither had been willing to say so directly. The analysis answered the question as asked. It didn’t surface the more important question — what are we actually optimizing for, and who gets to decide that — because nobody had been tasked with asking it.
This is where I think business analysts, at their best, add something policy teams sometimes skip: an explicit, upfront step where you interrogate the framing before you touch the modeling. Not “what alternatives should we compare,” but “what decision does this analysis need to support, who’s actually going to act on it, and what would make them trust the answer enough to change course.” That last part especially — trust — gets treated as a soft consideration in a lot of analytical work, when in practice it’s often the entire reason an analysis does or doesn’t lead to action.
Stakeholder consultation as theater versus stakeholder consultation as leverage
Most policy analysis processes include some form of stakeholder consultation, and I don’t doubt the intent behind it is usually genuine. But I’ve sat in enough of these sessions, on the business side, to recognize a version of consultation that functions more like a formality than an actual input into the analysis — stakeholders are informed, their comments are logged, and the analysis proceeds largely as it was already headed.
The business analysis approach I’ve found more effective treats stakeholder input less like a data-gathering exercise and more like a negotiation for future buy-in. If I know, going into a requirements process, that a particular department is going to resist a recommendation regardless of how sound the analysis is, my job isn’t just to document their concern. It’s to understand specifically what would need to be true for them to accept a different outcome, and then to either build that condition into the analysis or be honest, early, that the recommendation is going to require someone with authority to override their resistance directly. I’ve watched policy recommendations die quietly in implementation, months after a well-reasoned report was delivered, because the analysis treated stakeholder disagreement as something to be noted rather than something to be actively resolved or escalated before the recommendation went final.
A useful test I use, and one I think transfers well into policy work: if you can predict, before the analysis is even finished, which stakeholder is going to object and roughly why, you already know where the real work of the project lies. The modeling confirms what’s true. Getting that stakeholder to actually accept the conclusion is a separate task, and it’s usually the one that determines whether anything changes.
Descriptive and prescriptive analysis need different owners
One pattern I’ve noticed, watching policy analysis from the outside, is that descriptive work — what’s happening now, how effective current policy has been — and prescriptive work — what should happen instead — often get produced by the same team, on the same timeline, with the same level of confidence attached to both. In my experience, that’s a mistake, and it’s one business analysis has generally learned to avoid, at least in mature organizations.
Descriptive analysis is largely a matter of data quality and methodological rigor. If you’ve got clean data and sound methods, two competent analysts should land on broadly similar conclusions about what’s currently happening and how well it’s working. Prescriptive analysis is a different kind of claim entirely — it depends on value judgments about which tradeoffs matter more, and those judgments belong, at least partly, to the people with actual authority over the outcome, not solely to the analysts who built the model. When a single team delivers both with equal confidence, it can obscure the fact that the “should” part of the recommendation carries assumptions that were never actually validated with the people who’ll own the consequences.
The fix I’ve found useful, adapted from how I structure recommendation documents in business analysis work, is to separate the two explicitly. Present the descriptive findings as close to fact as the data allows. Then present the prescriptive options as genuinely contingent — “if you prioritize A over B, here’s the recommended path; if you prioritize B over A, here’s a different one” — rather than collapsing that choice into a single recommended answer before decision-makers have had the chance to weigh in on which priority actually reflects the organization’s values. This does more than improve intellectual honesty. It gives the people who have to defend the decision later a clear paper trail showing they made an actual choice, rather than simply approving whatever the analysts happened to prefer.
Scenario modeling without an owner is just an interesting document
Scenario modeling is one of the more genuinely valuable tools in policy analysis, and I don’t want to undersell it — done well, it forces an organization to think through consequences it would otherwise avoid confronting until they happen. But I’ve seen a consistent failure mode where a well-built scenario model gets delivered as a standalone artifact, with no clear owner responsible for revisiting it as conditions change, and it slowly becomes a historical document rather than a living decision tool.
In business analysis work, we generally don’t consider a deliverable finished until someone specific owns what happens to it after delivery — who updates the assumptions, who’s accountable for flagging when reality has diverged from the model enough to warrant revisiting the recommendation. I’d argue policy analysis benefits from the same discipline. A scenario model without a named owner and a defined trigger for reassessment isn’t really a decision-support tool. It’s a snapshot of a moment that will quietly stop being accurate, often without anyone noticing until the gap has become expensive.
What I’d actually change
If I were advising a policy team on process rather than content, I wouldn’t tell them to model differently or gather more data. I’d tell them to spend more deliberate time on three things that business analysis treats as core discipline and that policy work sometimes treats as peripheral: interrogating the framing of the question before analysis starts, treating stakeholder consultation as active negotiation rather than a documentation step, and separating descriptive fact from prescriptive judgment so the actual decision-makers are forced to own the value tradeoffs rather than inheriting them silently from the analysts.
None of that requires better technical modeling. It requires treating the human and organizational parts of the process — the parts that don’t show up cleanly in a report — with the same rigor as the analytical parts. In my experience, that’s usually the difference between a policy analysis that gets cited once in a meeting and quietly shelved, and one that actually changes what an organization does next.
Disclaimer: Client scenarios described in this article are illustrative composites drawn from common patterns seen across business analysis and requirements work, not references to any specific identifiable client or engagement.