Selling Federated Analytics for Resource Allocation

Federated analytics is often framed as a structural decision: Should we centralize or distribute? In our earlier blogs, we explored how to avoid the “oscillation trap” that comes from swinging between models without solving root causes, and laid out key design principles for standing up a federated analytics operating model that actually works in practice.

But structure alone won’t carry the model forward. For federation to take hold—and for central teams to avoid becoming overloaded and undervalued—you need to solve a more fundamental issue: how work gets funded.

This is where many analytics organizations get stuck. They shift to product or program-based models, redesign their intake process, and decentralize delivery. But without a clear framework for what kinds of work exist and how each type is resourced, the model breaks under its own weight. Enabler work crowds out utility work. Requests pile up. Business segments get frustrated. The central team becomes reactive and overextended.

In this blog, I’ll share the mental models and funding strategies that have helped enterprise analytics leaders move from reactive firefighting to scalable, sustainable operations. If you’re building a federated model, this is the case you need to sell before you restructure your org chart.

You Can’t Scale What You Can’t Fund

One of the clearest signs your analytics team is under strain is when business partners start calling you the "segment of no." This a common refrain I hear from our clients. They aren’t trying to be difficult. They are trying to survive.

Here’s an all-too-common scenario: The analytics team has implemented a formal intake process. Requests are coming in through a project management tool, prioritized using a weighted framework based on things like value, alignment, and urgency. But no matter how clean the process looks on paper, only the top few items are ever touched. Everything else sits in backlog limbo.

The issue isn’t demand. It isn’t even intake. The issue is funding. Specifically, the absence of a coherent model for allocating resources across the kinds of work analytics teams are asked to do.

Let’s say the team is funded centrally, out of a single cost center. And they also receive funding from partner segments for specific projects, and occasionally from the enterprise PMO. That might sound like a healthy mix, but in practice, the inconsistency makes it difficult to plan beyond a few weeks at a time. Project-based work gets attention because it’s funded. Day-to-day operational needs—like adding three columns to an HR dashboard—goes untouched. Not because they lack value, but because they lack budget.

Without a clear structure to tie funding to work type, the default is to prioritize what is visible and well-financed. The rest, no matter how legitimate, fades into the background.

This is the core challenge we see in organizations attempting to modernize their analytics operating model. They want to shift from a centralized team doing everything to a federated model where business segments take on more ownership. But the shift won’t stick without a shared understanding of what work needs to get done and how that work gets funded.

You can’t scale what you can’t fund. And you can’t fund what you haven’t defined.

Utility, Enabler, Driver: A More Useful Taxonomy

When we talk about analytics work, we often lump everything into one stream—projects, ad hoc asks, dashboard tweaks, machine learning models. But not all work is created equal. One of the most useful mental models I’ve found (courtesy of IIA Expert Frank Mendoza) is to split analytics work into three distinct categories: utility, enabler, and driver.

Utility work is what keeps the lights on. These are the daily and weekly reports, the dashboard enhancements, the new data columns that need to be added to existing tables. When this work is done well, no one notices. When it’s delayed or dropped, the business feels it immediately.

Enabler work helps the business make smarter decisions. These are the insights projects, the diagnostic analyses, the predictive models. Someone misses their quarterly target, and the analytics team is asked to help explain why—and to forecast how to avoid the same miss next quarter.

Driver work is future-facing. It’s where analytics pushes the business to think differently or pursue new value altogether. These are the “moonshot” projects—applying GenAI to a new customer experience, spinning up a new product line informed by predictive insights, or automating a key decision process across a business unit.

When we apply this taxonomy with clients, we often ask them to estimate how much of their time falls into each category. In most cases, the answer is skewed. One team estimated they were spending 70–75% of their time on enabler work—project-based insights, funded by specific segments—and only 25–30% on utility. Driver work was essentially nonexistent. That imbalance created organizational tension. Utility requests piled up. Teams supporting HR or finance found themselves waiting indefinitely for small but necessary changes. There was simply no mechanism to resource that work, because it hadn’t been named, scoped, or funded properly.

Understanding these three categories is a first step. The real breakthrough happens when organizations begin to resource against them differently. Utility work needs sustained, predictable funding. Enabler work requires flexible, project-based funding tied to business value. Driver work calls for a different mindset entirely—willingness to invest without guaranteed ROI.

I’m a big fan of the practicality in this tool in that gives analytics leaders a common language to use with finance, IT, and business partners. It helps define what work is being done, what work is getting left behind, and what that gap is costing the organization.

If You Prioritize Enabler Work, You Must Federate Faster

When enabler work dominates the backlog, it puts every other type of work at risk. That’s exactly what we’re seeing in many enterprise analytics teams today. The project work keeps coming, often funded by partner segments or tied to enterprise portfolios, and analytics leaders feel obligated to deliver. It’s high-visibility work, with high expectations and high ROI. It takes priority.

But that priority comes with tradeoffs. Utility work—the foundational tasks that keep analytics functioning day to day—gets pushed aside. If that imbalance persists, the team ends up running from project to project without the ability to support or sustain what’s already been delivered.

One analytics leader put it plainly: “Our segments know if it’s not funded, it’s not getting done.” That sounds harsh, but it’s also honest. And it reflects the reality of an overloaded team trying to manage work without a clear funding model for utility.

If the enterprise is going to continue prioritizing project-based work, then a faster move toward federation becomes critical. Centralized teams can’t absorb all the demands coming from the business. Trying to do so just reinforces the perception that analytics is slow or unresponsive. Segments grow frustrated and start building their own tools and teams anyway—just without alignment or oversight.

Federation, when done intentionally, creates a path out of that bind. It allows segments to own their enabler work directly, including the funding, staffing, and delivery. Meanwhile, the central team can focus on governance, shared infrastructure, and enterprise-level reporting. In other words, each team plays to its strengths.

But that shift only works when it’s backed by data. You need to show how the current allocation of work is unsustainable. How many requests are truly utility? How many are enabler? What’s being delivered, and what’s being dropped? A well-instrumented intake process can reveal that. And once you have the data, you can make the case: either resource the central team to manage both, or shift the enabler burden to the business and move faster toward federation.

Selling the Utility Layer

Utility work is the least glamorous and the most persistent. It’s the ingestion of new data fields, the maintenance of dashboards already in production, the updates that follow adoption. Once a project is launched and the excitement fades, the real work begins. But too often, that work is unplanned, unfunded, and unsupported.

Chances are you’re doing a great job outlining the resources needed to deliver a project. But once it jumps over the wall into utility, you just take it on, whether or not you have the bandwidth. Utility work becomes the silent tax paid by centralized teams. Everyone expects it to get done. No one wants to pay for it.

The way out starts with visibility. Teams need to estimate the utility cost of every enabler project up front. Not just the hours to complete the initial request, but the capacity needed to support it over time. If you’re decentralizing, start that conversation early with each segment. Show them what it takes to “keep the lights on” once their request becomes part of the system. Ask for ongoing FTE contributions or a recurring budget line item: “If you want three new columns added, you also need to fund the 0.5 headcount to keep that table running.”

This is where many analytics leaders get pushback. Segments are often willing to fund a one-time project. They’re far less enthusiastic about long-term commitments. That’s where the parallel to cloud infrastructure costs can be helpful, or whatever IT activity resonates within your company. If the business is already planning for increased compute and storage costs over time, why wouldn’t the same logic apply to analytics staffing?

It also helps to frame utility as shared infrastructure. It’s not overhead—it’s operational capacity. It allows the organization to adopt what it builds and keep using it over time. Without it, the value created by projects erodes, and trust in analytics delivery diminishes.

The Shift from Cost Center to Internal Consultancy

It’s hard to have a funding conversation without bumping into the cost center label. Most centralized analytics teams are structured this way. The business sees them as overhead—necessary, but fixed. When new work comes in, teams scramble to absorb it. And when the backlog grows, so does the perception that analytics is a bottleneck.

There’s a better way to frame the conversation. Internal analytics teams can operate more like consultancies. That doesn’t mean they need to turn every conversation into a pitch. It means they treat their work as value-generating, not just cost-bearing. That mindset shift changes how you structure requests, allocate resources, and make the case for funding.

For example, if a project is expected to generate $5 million in savings, the analytics team can reserve a fraction of that projected value to sustain the work. Even a 5–10% carve-out can fund the ongoing maintenance and enhancements that come after going live. If the CFO is already removing those dollars from the business unit’s line items, keep a portion of that value in play to fund what comes next.

The same logic applies to revenue-generating projects. If analytics contributes to the creation of a new product, service, or channel, then it should share in the value creation. Not to profit—just to sustain. When that value is recognized, funding utility work stops feeling like an extra burden. It becomes the cost of doing smart business.

This doesn’t happen by accident. It requires analytics leaders to act as advocates—to show how internal consulting differs from internal servicing. The work still gets done, but it gets done with clear agreements, intentional funding, and an expectation of long-term support.

If your organization is ready to scale analytics, this is the conversation to start. Don’t ask for headcount. Ask for shared investment. Don’t justify cost. Justify value. That’s how you move from a reactive team to a strategic partner.

Conclusion: Define the Work, Fund the Work, Then Scale

Selling a federated model begins with selling the reality of your current one. When centralized analytics teams are asked to deliver more project-based work without additional investment, something has to give. Utility work gets sidelined. Adoption suffers. The cycle repeats.

Federation offers a way out—but only if it’s paired with clarity. What kind of work are you doing? Who is funding it? What will it take to sustain it after the initial project is complete? These are the questions that shift the conversation from "how much headcount do we need" to "how should we structure analytics to deliver value over time?"

There’s no one-size-fits-all funding model. But every model has to start with a clear understanding of what’s being asked. The utility-enabler-driver framework gives you the language to describe that work. Intake data gives you the proof. Together, they make a compelling case for rethinking how your analytics function is resourced, governed, and sustained.

At IIA, we’ve helped many organizations navigate this shift. If you're making the case for federation—or trying to right-size the team you've got—we’re here to support that conversation.