Fourteen people in a room, one hour on the calendar, a recurring slot called "Process Review". Operations reports its numbers. Finance reports its numbers. IT explains a system change. Sales mentions a customer complaint. Everyone is competent, everyone is prepared, and at minute fifty-eight someone says "good discussion" and the meeting ends. Nothing about the process itself has changed, and the same slot will run again next month with a different set of slides.
Most organisations know that their important processes cross departments — order-to-cash, purchase-to-pay, hire-to-retire, quote-to-delivery. Very few have a review format that treats those processes as one thing. What they have instead is a series of departmental reports, delivered in the same room, at the same time. That is not a process review; it is a status meeting with a wider distribution list. This edition of Quick Tips is about five practical ways to run a cross-functional process review that actually produces change — and how to tell, honestly, whether yours does.
Consider a manufacturer whose order-to-cash cycle takes nineteen days from confirmed order to paid invoice. Each function reviews its own contribution monthly, and each one looks healthy: sales confirms orders within a day, production hits its schedule ninety-four percent of the time, logistics ships on the promised date, finance issues invoices within twenty-four hours of dispatch. Every department is green. The end-to-end cycle has not moved in two years. Nobody is failing, and yet the process is.
The reason is structural rather than personal. Departmental reporting makes the work inside each box visible and leaves the space between the boxes dark — and in a cross-functional process, the space between the boxes is where most of the elapsed time lives. Waiting is nobody's KPI. A file that sits four days in an inbox between logistics and finance appears in no department's performance report, because no department was working on it. This is the same dynamic we described in the edition on why the better each team performs, the worse the system gets: optimise the parts in isolation and the whole can quietly deteriorate while every local metric improves.
A second failure mode compounds the first. Because the meeting is built around reports, its output is naturally commentary rather than decisions. Reports invite discussion; discussion produces awareness; awareness feels like progress. But a process only changes when someone changes it, on a date, with a consequence attached. The five tips below are about designing the review so that both problems are addressed: making the end-to-end flow the subject, and making decisions the output.
The single highest-leverage change to a cross-functional review is to reorganise the agenda. Instead of a slot per function, walk the process from the first trigger to the final outcome, in sequence, once. Where does a case enter? What happens next? Where does it wait? Where does it loop back? The people in the room stay the same; what changes is that they are now describing one shared object rather than five parallel ones.
This sounds trivial and it is not, because it removes the safety of the departmental frame. When the agenda follows the process, a delay cannot be reported as "we delivered on time and then it went to finance" — the review simply continues into finance and asks what happened there. Handoffs stop being the end of someone's slide and become a step in a story everyone is looking at together.
A practical way to enforce this: put a single visual of the end-to-end process on the screen and keep it there for the whole hour. Every point anyone makes has to be located somewhere on that picture. If a topic cannot be placed on it, it belongs in a different meeting.
Ask yourself: does your review agenda follow the process from end to end, or does it follow your org chart?
Cross-functional reviews are unusually vulnerable to the loudest anecdote. When five functions describe the same process from five vantage points, and none of them can see the whole, the discussion resolves toward whoever tells the most vivid story. That is a poor way to allocate improvement effort — the vivid cases are rarely the expensive ones.
The fix is to open the review with the actual flow rather than with opinions about it. The timestamps needed to reconstruct a cross-functional process already exist, scattered across the systems each department uses: the ERP knows when the order was confirmed, the warehouse system knows when it was picked, the finance system knows when the invoice went out and when payment arrived. Process mining stitches those records into one measured path, which turns "I think approvals are the bottleneck" into "sixty-one percent of the total elapsed time sits in two waiting states, and here they are." Platforms such as noreja add causal analysis on top, so the review can look at what is driving a delay rather than only where it appears.
Evidence also changes the tone of the meeting, which matters more than it sounds. A measured process depersonalises the conversation: the number belongs to the flow, not to the department that happens to sit at that step. That makes it considerably easier for people to admit where their part is slow.
Ask yourself: when your review names a bottleneck, is that based on a measurement of the whole process, or on the most confident person in the room?
If you only have time to examine one thing in a cross-functional review, examine the handoffs. In most end-to-end processes, the transitions between functions account for a majority of elapsed time and almost all of the ambiguity: who is responsible while a case is in transit, what "done" means for the sending side, what completeness the receiving side actually needs.
Handoffs also hide a specific and expensive pattern: the incomplete package. A case arrives missing one field, one attachment, one approval — so it goes back, waits again, and returns. To the sending department this is a successful completion; to the receiving one it is rework; to the process it is a loop that can easily double the elapsed time of that step. Reviews that only look at throughput per function never see it.
Make each handoff an explicit agenda item with three questions: how long does a case wait here, how often does it come back, and what exactly is missing when it does. The third question is the useful one, because it converts a general complaint about quality into a specific, fixable definition of "complete".
Ask yourself: for the most important handoff in your process, do you know its average waiting time and its return rate — or only that people find it frustrating?
A cross-functional review has one output worth measuring: the number of decisions it produces that are still true a month later. Everything else — insight, alignment, mutual understanding — is valuable only as a means to that. And decisions in cross-functional settings fail in a predictable way: they are agreed collectively and owned by nobody, because the change touches several departments and no single manager can be held to it.
So make the ownership explicit and singular. Every decision leaves the room with one named person, a date, and a stated expected effect on the process — not a team, not a function, not "operations and finance together". If two departments must act, one of them owns the outcome and the other is a dependency. We wrote about the failure mode this prevents in the edition on decisions that don't survive the meeting: without a name and a date, an agreement quietly decays into an intention.
It helps to cap the number. A review that produces two decisions with real owners will change more than one that produces eleven action items nobody tracks. If the list is long, the meeting has been generating awareness, not change.
Ask yourself: could you list, from memory, the three decisions your last process review produced — and who owns each of them?
The last tip is about sequence. A review that begins with new topics is an event; a review that begins with the previous round's decisions is a loop. The difference is whether improvement compounds or resets every month.
Start every session with the same five minutes: what did we decide last time, what happened, did the metric move. This does three things at once. It makes non-delivery visible without anyone having to accuse anyone, it teaches the room that decisions here are real, and it builds a short factual record of which kinds of change actually work in your organisation — which is the most useful asset a review can accumulate.
Cadence deserves a thought too. Monthly is the default, and for most cross-functional processes it is too slow: a decision made in one session gets its first honest check six weeks later, by which time the context has moved. A shorter loop — a focused thirty minutes every two weeks, with the same standing structure — usually produces smaller changes more often, which is exactly the shape improvement should have. And it removes the temptation to fill an hour with reporting because the slot exists. The measure of a good process review is not how much was covered; it is how much moved because of it.
Ask yourself: does your review open with last round's decisions, or with this round's slides?
If your cross-functional review stopped happening for six months, what in the process would get worse — and would anyone be able to prove it?
Who in your organisation is accountable for the end-to-end cycle time of your most important process, as opposed to a segment of it?
How much of your last review was spent describing the past, and how much deciding about the future?
If you measured the waiting time at each handoff in your process, which department would be most surprised by the result?
What would have to be true for your review to produce fewer, larger decisions instead of many small action items?
Cross-functional process reviews fail for structural reasons, not because the wrong people attend. When the agenda mirrors the org chart, the parts of the process that cross boundaries stay invisible; when the format rewards reporting, the output is commentary rather than change. Both are fixable, and none of the fixes require new tooling or new headcount: make the process itself the agenda, open with measured evidence rather than impressions, put the handoffs at the centre, end with a small number of decisions that each have one owner and one date, and begin the next session with what happened to them.
A concrete first step: take the last three reviews of your most important process and count the decisions that produced a documented change in how work flows. If the number is zero, the meeting is not a process review yet — and one hour of the right structure will do more for your cycle time than another month of reporting.
It is a recurring session in which the people from every function a process touches examine that process end to end as a single object — from its first trigger to its final outcome — rather than reporting on their own department's contribution. Its purpose is to find where the flow breaks between functions and to decide on changes to it.
Two reasons. The agenda usually mirrors the org chart, so the waiting time and rework that occur between departments stay invisible — they are nobody's KPI. And the format rewards reporting rather than deciding, so the output is discussion instead of a change with an owner and a date.
Someone with decision authority from each function the process passes through, plus whoever can produce the process data. Keep it small enough that decisions can be made in the room. If people attend only to be informed, they can read the record instead — a review whose size prevents decisions has already lost its purpose.
The timestamps needed to reconstruct an end-to-end process already exist across the systems each department uses. Process mining joins them into one measured path, showing where cases wait, how often they loop back, and which variants dominate. That replaces competing impressions with one shared picture and lets the review start from evidence rather than anecdote.
More often and shorter than most organisations run it. Monthly hour-long sessions tend to fill with reporting and give each decision its first check six weeks later. A focused thirty minutes every two weeks, always opening with the previous round's decisions, produces smaller corrections more frequently — which is the shape sustainable process improvement usually takes.