FLOW-V Demand Management Framework: Breakthrough Conversation with IIA Expert Kari Jones

In this blog series, Jason Larson, head of content at IIA, interviews IIA Experts who help enterprise data, analytics, and AI leaders navigate their most pressing challenges. With 150+ highly-vetted domain experts, IIA's Expert Network delivers tailored decision support, unbiased plan validation, and ongoing guidance to advance data and AI outcomes.

In this Breakthrough Conversation, Kari Jones, executive director of transformation and operations at Financial Markets Authority, shares the framework she built to solve a problem she's met in every sector she's worked in: too many good ideas and never enough capacity to deliver them. Jones calls her framework FLOW-V, and walks through how each piece works, how it shifts with how much an organization trusts its people, and why she'd rather push decisions down and out than hold onto them herself. 

You've said the same demand problem shows up whether you're in grocery retail, public health, or financial regulation, where you are now with the Financial Markets Authority. What is that problem, and what pushed you to build a framework around it?

There's never enough capacity to meet the demand that enablement functions face. I call it an enablement function rather than a support function, because that's the job — enabling frontline teams to do their best work in partnership with them. But there's never enough analytics, data, or engineering people to chase every good idea an organization has, so everyone ends up forming an orderly queue to work out what gets done, and what gets done first.

For me personally, that meant sleepless nights, calls from stakeholders wanting to bump their work up the queue, and the pressure of feeling like every one of those calls was mine to make. You can never make everyone happy. Someone is always trying to go around you, and you end up with burnt-out teams asked to deliver everything to everyone.

What happens next is what I call the black market of data favors: side deals, people trading on the side, "if you could just do this little thing." Work seeps into the pipeline that leadership doesn't even know about, and prioritization becomes a political decision instead of one judged on merit. That's why I see it as a leadership and design problem, an operating system problem, not just a process problem.

I've inherited versions of this in more than one organization, no model at all, just a scramble over who gets what worked on, or a single funnel for every kind of work. When everything goes through one pipe, the pipe becomes the problem. Whoever sits at that pinch point rarely has the context to weigh a corporate project against a customer initiative, so friction gets added earlier instead. Go do a security assessment, a privacy impact assessment, more detailed costings, which just kicks the can down the road and creates busy work, with unintended consequences nobody thought through. Whoever reaches the front of the queue first tends to get funded until capacity runs dry, which rewards being first, not being right.

So you built FLOW-V. Give us the overview. What does each letter stand for?

Flow to value, because that's the point of all of it. Everything an analytics or data function does should be about impact and value, but getting there is hard, and FLOW-V is a five-part operating system for managing demand under constraint.

F is Frame the work: moving from a single funnel to domains and portfolios. L is Locate decision rights: pushing trade-offs to the people closest to the outcomes, not centralizing them with me. O is Operate in rhythm: annual direction, quarterly commitments, monthly check-ins that keep momentum without locking you into a plan gone stale. W is Wire governance to trust: matching how much oversight you build in to how much your organization genuinely trusts the people making the calls. V is Validate value: bookending initiatives so you tell the story of impact upfront and measure the benefit at the end. Each piece is simple on its own. Applied consistently together, that's what makes it powerful.

Let's start with Frame. How do you decide how many domains to create, and what happens to work that doesn't fit neatly into one?

I group work by shared objectives. When a group of people is aligned around the same goals and KPIs, they're incentivized to help each other prioritize the initiatives most likely to move that group's numbers. Shared objectives instead of personal agendas — that's the glue.

At the FMA, we settled on six portfolios: four demand-driven domains, including Regulatory Platforms, Digital Experience, Corporate Platforms, and Data & Regulatory Intelligence, plus two capability portfolios, Cyber Security and Foundational Capabilities. The split mattered, because we couldn't get more work into production without investing in automated testing first, and capability portfolios get resourced for sufficiency rather than run through the same prioritization process as demand-driven work. Your delivery capacity behind each domain is often the true constraint. Three or four tends to be the sweet spot; fewer and you're back to a funnel, more and you fragment delivery and burn out your portfolio leads.

Delivery capacity is usually fixed, so we make clear calls about which initiative has the greater impact and let everyone else form an orderly queue. The delivery team builds deep knowledge of a particular domain instead of flipping between operations, customer, and marketing, which builds pace over time. I also lean on what I call an infinitely scalable operating model, strong vendor relationships you can scale up or down with investment. Digital Experience has almost no internal delivery capacity, nearly all externally delivered with a portfolio lead and a bit of internal support, while other domains are fully internal. I flex between opex and capex depending on where the funding sits. It's never mattered to me whether the people delivering value sit inside the organization or outside it.

Locate is about decision rights. You've talked about "letting the ego go." What does that look like in practice?

It means accepting that even twenty years in an organization, with a deep understanding of the strategy, doesn't mean you should make every call. You're an enablement function; the business is the business. I want my frontline teams to own the solutions and be part of the change, not have it forced down their throats, what I call foie gras change management.

I don't want every decision arriving on my desk, because then I become another bottleneck. I want consistency instead, guiding principles that make clear how decisions get made in each domain, so people have a voice and there's a system behind the call. Our engagement survey flagged decision-making at the right level as an area to improve, and this is how I've tried to close that gap.  

FLOW-V assumes you can identify the most impactful problems, but impact is often contested, political, or only obvious in hindsight. How do you resolve disagreement about what counts as high-impact, and who has the final word?

The framework helps because you're not running one funnel, you're running multiple. Stakeholder groups ladder up to the same set of goals, so when you compare projects, you're comparing similar initiatives instead of asking whether a marketing project is worth more than a supply chain one. Those are apples and pears, and you never win that argument; it just turns into escalation and politics.

Within a domain, we size the work, mega, medium, or small, plotted on a grid of impact against effort. The question most organizations never ask isn't how much this will cost, it's how much we're willing to invest to get the outcome. I learned a version of this from fellow IIA Expert Scott Frieson: you need a view of your singles, doubles, triples, and home runs, to use a baseball metaphor.

The other half comes from the concept of lean analytics: what's the smallest thing you can do, in the least time, to prove or disprove the hypothesis. People get attached to their baby, so this is harder to embed than it sounds. At a former employer, a grocery retailer, rather than rolling a program across every store to cut fish waste, we picked one store, gave them the data, and ran it for three weeks. It proved the concept before we asked for the full investment.

Going back to the black market of data favors, some of the best relationships between analysts and business partners start as informal side deals. How do you formalize the good without killing what made it good?

You have to keep the side deals going. You can't make it all the work, and you have to accept there will always be a shoulder tap, always someone sneaking a small one in off the books. It's got to stay proportionate.

I wouldn't take on the things that reduce the integrity of the investment process, but a couple of days of work that improves a relationship is different, and my team knows to escalate the bigger calls to me. One of our AI pilots came about because the legal team finally wanted to explore it, and my head of data flagged it to me. I said drop everything, fit it into this sprint or the next, because it served our own purposes too — a key business team demonstrating impact in something we cared about.

We also plan for it. Your quarterly capacity plan should account for the planned work but hold back some capacity for the unplanned work you know is coming, so a random urgent ask doesn't blow up existing commitments. My rule of thumb is roughly this — half a day, just do it; a couple of days that will bump committed work, probably not. Relationships are the glue of an organization. We're not running an industrial manufacturing plant.

You've called Operate "the boring bit, but the most important bit." What does that rhythm look like day to day?

This is where you, as the leader, become the drumbeater. Two months before the start of the year, we lock in planning estimates, rough sizing, investment appetite, and domain objectives, and build an indicative backlog. It's always been about answering one question for finance: why do you need this budget? Here's the list, so here's the level we're requesting, then it's a negotiation.

The hard graft happens in the quarterly rhythm: lock in dates, get the stakeholder prioritization groups together, and march. At the midpoint, we check how we're tracking, and I don't want to hear about the greens, only the reds. We have clear discipline around whether we stop work in flight to start something else, since guiding principles need to exist before that decision comes up, not in the moment. Underneath that sits a monthly rhythm we call the DRUM, the delivery review update meeting, where the portfolio lead and the prioritization group review the backlog and look ahead to the next quarter. None of this is the analytics team deciding things alone in a room; it's a rhythm of transparency with stakeholders about what's genuinely happening.

Wire is about matching governance to trust. How has that looked different across the organizations you've led, say Woolworths compared to the FMA?

At Woolworths, the grocery retailer I mentioned earlier, trust was high and the culture wanted speed; it was a get-it-done organization. The FMA is a public sector regulator, funded by industry levies, with a risk-adverse board, and it optimizes for control and risk management ahead of pace. When budgets and capacity tighten, governance and paperwork tend to increase along with the mismatch, because people want to understand how work gets chosen. You can't skip this operating culture entirely in a high-scrutiny environment, but you can train the organization toward what's genuinely just enough.

At the FMA, our Strategic Project Committee sits above our prioritization groups and releases funding each quarter, confirming they're satisfied with what's been delivered, even though I own that budget line. That's about transparency, not about taking away my authority. I've also had to adapt the language itself, translating a product, agile vocabulary for an organization that doesn't share it yet: program management instead of portfolio management, projects instead of products, funding release and stage gates instead of drawdown. Nothing about what we deliver changes. How we show up and talk about it does.

How do you demonstrate value once the work is delivered, and why do you think most stakeholders struggle to articulate it in the first place?

At the end of every quarter, we produce an impact report — what we delivered, and the stories of impact from the frontline teams who commissioned it, what they loved, what benefits they're starting to see. Those stories go to the executive leadership team and set up the next budget conversation: we're a safe pair of hands, here's what we could achieve with more capacity.

Underneath all of it is what I'd call value literacy, and there’s opportunity for us to mature as a team here. Stakeholders often can't articulate why a piece of work matters or what would change if you gave them the thing, and that's harder than it sounds. It asks people to think hard about what they're trying to achieve, the old outcomes-versus-outputs idea, a cliché because it's true and hard to live out. Most organizations reward action and output, when it's outcomes that move the dial.

It starts upstream of the analytics team. Organizations need to be clear on their goals, how they measure them, and what each business unit contributes to them. Without that, nobody can reason well about value, because there's no shared sense of what "valuable" even means. It comes down to focus, discipline, and hard choices, rather than knee-jerking into action. Most people don't know what will move the dial, so they ask for whatever their boss asked for, which is where hierarchy and culture come in: does the organization reward doing stuff, or achieving stuff? That question sits underneath value literacy, and it's bigger than any analytics function.

The part I'd most want people to take away is that it's fine not to know. That's the premise behind lean, hypothesis-driven work — instead of launching a big project, what's the small thing we can do to prove or disprove the hypothesis first? It frustrates stakeholders sometimes, because it slows things down and they're often just responding to what they were told to do. But it's the discipline that separates outcomes from activity. Analytics and business teams aren't always incentivized by the same things, and that tension isn't personal. The thing an analytics team has to know is whether it's working on something that will move the dial, because that's how we're judged, not by how many BI reports we put into production this month.