Most monthly business reviews are extended status updates with better catering. Dashboards get presented. Project owners report on progress. The numbers get discussed in a tone that suggests gravity. Everyone leaves with marginally more information than they arrived with, and the meeting goes back on the calendar for next month, because that is the cadence.
No decision was made. Nothing actually changes in how the company operates. The next MBR will produce a similar set of slides, with slightly different numbers and the same outcome.
A real MBR changes at least one decision per session. It is not a reporting venue — it is a deciding venue, and the difference is structural, not tonal. Here is how to build one that earns the time on the calendar.
Why most MBRs fail to decide
The standard MBR is built around presenting status. Each function gets a slot. Each owner walks through their numbers. The CEO asks a clarifying question or two. Somebody says "we should follow up on that offline." The meeting moves on. By the end of the ninety minutes, the room has absorbed information but has not had to make any choices, because the format never forced one.
The deeper problem is that most MBRs do not have the data that would enable a real decision. You cannot decide whether to reallocate resources if you cannot see, in real time, where resources are actually allocated. You cannot decide whether to descope a goal if you cannot see which work is currently moving it and which has stalled. So the conversation defaults to the data that is available — completed projects, milestone updates, vanity metrics — and avoids the decisions that would require the data that is not.
The four-part structure
A real MBR has four sections, in order, each designed to push the room toward a specific kind of conversation.
Part 1: Goal health, not project status. The first fifteen minutes cover objective health — which goals are on track, which are at risk, and why. Not which projects are complete. The question is not "what did we finish" — it is "are we moving the things that actually matter?" The two questions sound similar and produce wildly different conversations. Goal health should be visible before anyone walks in the room. Pre-read, not presented. If the first fifteen minutes are spent reading numbers off slides, the rest of the meeting is already lost.
Part 2: Work-to-goal audit. This is the section most companies cannot run, because they do not have the data. The question: is the work we are actually doing connected to the goals we say we care about? Take fifteen minutes to review which goals have significant work attached, which have little or none, and which significant work streams do not connect to any goal at all. The third category is where the surprises live. The answers tell you more about execution health than any project status report ever will.
Part 3: Resource reality. Where are people actually spending their time? Does it match where the strategy says they should be spending it? A goal that ranks as "top priority" but has no team time allocated to it is not a real priority — it is a stated preference. The MBR is the place to call out the gap between the stated priority list and the actual allocation of human attention. This conversation is uncomfortable because it usually reveals that the company is running on three priorities while claiming seven. That discomfort is the point.
Part 4: The one decision. Before the meeting ends, name the decision. One thing that will change in how the team operates next month, based on what was just reviewed. A resource shift, a deprioritisation, a hiring decision, a scope change, a goal that gets killed. If there is no decision at the end, the meeting was a reporting session with a fancier name. No decision, no MBR.
What makes this hard in practice
Running a real MBR requires data that most companies do not have in accessible form. Goal health visible in real time. Work-to-goal connections traceable without a spreadsheet exercise. Resource allocation visible against strategic priorities, not just against project codes. Most organisations cannot produce that view because their goals live in one system, their work lives in another, and their capacity data lives in a third — usually in someone's head.
If the MBR preparation takes three hours of spreadsheet consolidation by the chief of staff, the structure will collapse within two cycles. The meeting will revert to status updates because the data for the harder questions is too expensive to gather. The format will follow the available data, every time.
When goals, work and capacity live in the same system, MBR prep goes from three hours to twenty minutes. The data for all four sections is already there, derived live from the operating state of the company. The meeting can be about deciding, not about reconstructing the picture from twelve different sources and hoping nothing got lost in translation.
The cultural shift the format forces
The hidden benefit of an MBR built around "the one decision" is that it slowly trains the leadership team to come to the meeting expecting to choose. The first two months are awkward — people are used to performing, not deciding. By month four, the format has its own gravity. People walk in with proposals. The CEO walks in expecting trade-offs. The room learns that bringing a status without a recommendation is not enough.
This is the cadence that produces a learning organisation. Not the offsite, not the all-hands. The monthly forcing function that says: we will look at the strategy, look at the work, look at the resources, and change something. Every time.
The Vindaris view
We built Vindaris partly because MBRs in most companies are a sad waste of senior time, and the reason is structural rather than human. When the data for the four sections is already in the system — goal health derived from work, work-to-goal connections native, resource allocation visible — the meeting changes shape. The chief of staff stops being a data janitor. The executives stop being audience members. The room starts deciding.
If your MBR ends without a clear decision more often than not, you do not have a meeting problem. You have a data-availability problem dressed up as a meeting problem. Fix the underlying architecture, and the format starts working on its own.