I speak with organizations all over the world, and when it comes to delivering projects, I hear the same struggle again and again: work keeps slipping, and no one can quite say why. Teams are busy, dashboards are full, and the important initiatives still don't land on time. The dashboards show that velocity is a problem, but not where it's breaking or what to do about it. You can't fix what a dashboard only tells you is wrong.
It's rarely one bottleneck — it's many small and large inefficiencies, within each workflow and between them, that compound into missed organizational goals and objectives.
Strategy doesn't fail in one place. It loses speed across the whole path from idea to delivery, and most of that loss is invisible because each stage is measured on its own.
Process Mining to the rescue.
An idea or feedback comes in, but it gets routed to the wrong queue or categorized under the wrong theme, so it never lands against the objective that would have made it a priority. A high priority demand clears intake but takes a month longer than it should. A project starts late because the demand started late. A story sits in a backlog while the dev team waits on a decision. That's not one potential problem, it could be many: small frictions and large ones, different causes at every stage, some procedural, some human, some structural. What ties them together isn't the cause. It's the cost. Each one chips away at the same thing, the business imperative the work was supposed to serve, and because they're scattered across stages and owners, no one sees the full bill.
That's your value stream. And here's the catch. You can manage every stage well and still have no view of how the work actually flows between them. Status reports tell you where things are. They don't tell you how they got there, where they stalled, how often they went backward, or whether they're even pointed at the right objective.
Process Mining does. It reads the flow, and it reads it across stages, not just inside them. That's what lets it connect the dots and show you velocity end to end. The best way to see how is to go deep on one stage, so let's take demand.
Focusing on Demand Management
Let's focus on demand, because it's how teams vet what work gets focused on and approved. It's where an idea becomes funded, staffed work, and where a project's start date is really decided. If demand is slow or sloppy, everything downstream inherits it. So, demand is both the clearest example of how process mining works and the highest-leverage place to apply it.
A demand almost never succeeds or fails on its own. It moves when the work under it moves. That work lives in Demand Tasks: the assessments, architecture reviews, sizing, and approvals hanging off the parent record. The demand is the headline. The tasks are the story.
That's why you mine them together. Look at a demand alone and a stall is a mystery. It's just sitting in a state, or bouncing backward, for no reason you can see. Put the Demand process and the Demand Task subprocess side by side and the reason shows up. You can follow a stuck demand straight down to the exact task holding it. The links between the two are the diagnosis. Demand fails two ways, and both show up this way.
Use case 1: Rework - Quality impact
The first failure is motion in the wrong direction. Work that should move forward loops back instead. A demand returns to an earlier state to redo something that should have already been settled.
Rework can happen anywhere in the process, and where it happens changes what it costs. A loop early in intake is cheap to absorb. A loop late, after a demand has been qualified and real work has gone into it (risk and compliance review, sizing, architecture estimates, resourcing, security, sign-off) is expensive, because much of that work gets redone and it happens when the project clock is already running. Process Mining surfaces all of it, wherever it sits. It shows you where the backward loops are and when they happen, and it ranks them, so you're not guessing which ones actually matter. Improvement opportunity detectors within Process Mining surface inefficiencies providing the impact, allowing teams to prioritize effectively.
Understanding where the friction is the first step. Leveraging Now Assist enabled investigative tools gives you the why it happened as well as the context. Intent and Activity analysis surfaces the themes and clusters of topics that caused the inefficiency, along with the steps the work took. Work note analysis goes a layer deeper into the human record, pulling the reasons people wrote down at the time: which stakeholder held things up, what kept getting kicked back, what the few real root causes were. Now Assist puts it all in plain language. You end up with context you can act on, not just a flag. You can see the loop, understand what caused it, and go fix the thing upstream that keeps sending the work back.
Use case 2: Stalled work - Velocity impact
The second failure is the opposite of rework. Instead of moving backward, the work doesn't move at all. A demand sits in a state, on track in theory, while the clock runs and nothing happens.
Stalls are easy to miss because a stalled demand still looks "in progress." Nothing is wrong on the record itself.
Time is leaking somewhere, and it's usually not where you'd expect. Often the demand isn't stuck in its own state at all. It's waiting on the work underneath it: a Demand Task that's sitting Pending for weeks or Open for months, holding the parent demand in place until it clears. The demand isn't stuck in qualification. It's waiting on the work qualification depends on. And the demands that stall this way are frequently the ones you can least afford to lose, the high-priority, strategically important work. Process Mining shows you where the waiting truly happens and when, and which stalls are doing the most damage.
Again, knowing where the friction sits is just the first step. The Now Assist enabled investigative tools give you the why and the context. Intent and Activity analysis surfaces the themes and clusters of topics behind the wait, along with the steps the work actually took, so you see what it was waiting on rather than just that it waited. Work note analysis goes deeper into the human record, surfacing the reasons captured at the time: the record sitting unassigned, the requester taking longer to send back what a task needs, the handoff that never happened. Now Assist names it plainly. So instead of "this demand is slow," you get the specific reason it's idle and the specific place to intervene. Most stalls turn out to be assignment-and-input problems in the task layer, not qualification problems in the demand layer, which means the fix is concrete.
The gaps map to the KPIs you're measured on
Closing these gaps isn't busywork. Each one moves a metric leadership and peer teams care about and track.
Rework hits the quality KPIs and impacts organizational goals such portfolio delivery and strategic alignment. Every backward loop shows up as a higher rework rate, more scope churn and change requests, lower project success rates, and weaker benefits realization when work ships late or wrong. Cut the loops and those numbers move in the right direction.
Stalled work hits the velocity KPIs. Idle time inflates intake and qualification cycle time, drags out idea-to-value and time-to-market, pushes out project start dates, and ages your demand backlog. It also frees capacity, so more of your team's time goes to strategic work instead of waiting.
Both feed the one number above all others: how much of the portfolio truly delivers on the goals and pillar KPIs it was funded to serve.
Connecting the dots, both directions
Here's where it gets bigger than demand management. The same lens that explains a stuck or looping demand also lets you trace the work into the stages on either side of it. That's the whole point of mining the value stream instead of one workflow.
Upstream, what funnels into a demand comes from an idea (or product feedback). A late demand often started as a mis-routed or mis-categorized idea. The idea was real and worth doing, but it got filed under the wrong theme or sent to the wrong queue, so it never attached to the objective that would have moved it up the list. By the time it became a demand, it was already behind. Mine the idea-to-demand flow and you can see it: where ideas get categorized, where that categorization sends them, and which paths quietly lead to work that never connects to a priority. The quality problem upstream isn't bad ideas. It's good ideas not categorized or prioritized correctly.
Downstream, into Project and Story. A demand that reworked or stalled hands its project a late, shaky start, and you can follow that thread forward. Mine the project process against its task and milestone subprocesses and the same shapes appear: backward loops where work gets redone, quiet stalls where a project idles waiting on something underneath it. Follow it one more step into Story and Dev and you find the same patterns again. A story bouncing from Work in Progress back to Draft. Work pinging between Dev and QA. Each loop is rework on the most expensive resource in the chain.
The value is in the connection. When you can see a mis-categorized idea become a slow demand become a late project become a delayed story, you stop treating four separate problems and start seeing one flow with one set of friction points. That's velocity you can manage in a data driven manner.
Same approach, every stage and workflow
Idea, demand, project, or story. Whatever the friction point, you work it the same way: detect, expose, and investigate. Start at the parent, drop into the work underneath, let the analysis surface the friction points and what’s causing it.
Process Mining uses improvement opportunity detectors to detect and expose it for you, scanning the process and flagging where the time and the loops are in minutes, not weeks. From there, the investigative tools provide the context. Intent and Activity analysis rebuilds the real steps inside a pattern and the themes behind them, so you see what caused it instead of just the endpoint. Work note analysis adds the human side the activity data can't carry: why work kept reopening, which stakeholder kept holding things up, what the few real root causes are. Now Assist sums it up in plain language, so you're reading a diagnosis instead of digging one out of raw event data.
Why this is a velocity and quality story
Velocity and quality aren't a trade-off here. They're the same fix.
Every backward loop is rework, and rework is a quality signal. Something upstream wasn't done right, or wasn't pointed at the right objective, so the work came back. Kill the loop and you get both: the work moves faster and it's cleaner when it lands. Every stall is idle time on the work you most wanted to move. Unstick it and the right things move first.
Do that across the chain and the math compounds. A well-routed idea feeds the right demand sooner. A cleaner demand stage gives projects a real start date. Healthier projects feed dev work that's ready to build. Pull the rework and the idle time out of each stage and you hand that time straight back to the front of everything downstream. The whole value stream picks up speed, and the work that reaches the business is the work the business asked for.
That's the alignment that matters. Not a dashboard that says you're on strategy. Work that arrives on time, built right, and pointed at the objective it was meant for, all the way from idea to story.
Step zero for agentic work
Putting AI agents across this chain is the right instinct. But drop an agent onto a process that loops work backward, leaves tasks Pending for weeks, or routes ideas to the wrong queue, and you just automate the mess faster.
Process Mining is the part that comes first. Intent and Activity analysis and work note analysis turn "we should automate this" into a real list: the rework steps to kill and the stalls to clear, at every stage. They also tell you what an agent would have to do, because they've already mapped what a person does to move the work along.
Understand the process first. Ground your data so you can automate effectively and put AI agents to work where they'll move the needle. And it doesn't stop there. Once the improvements and agents are deployed, point Process Mining back at the same process to measure the impact. That closes the loop, you see what changed, what still needs work, and where to go next, so the process keeps improving continuously instead of drifting back. End to end.
If your strategy feels slow and you can't say where, stop looking at the stages one at a time. Look at the flow between them. Look for the backward arrows where work gets redone, the quiet records sitting still while the work underneath them ages, and the ideas that got pointed at the wrong objective before they ever became demand. They're in your data right now, across the whole chain, and different as they are, they all add up against the same imperative: the gap between what your portfolio promised and what it delivers.
