KanBo Perspective

The Coordination Gap

You run fourteen systems and still can’t answer “where are we?” without calling someone. Here’s why — and what closes it.

A test you can run on Thursday

Pick one live initiative that crosses at least three functions. A product launch, a facility rollout, a regulatory submission, a systems migration. Something real and currently in flight.

Now answer three questions without messaging anyone:

1. What is blocked right now, who owns clearing it, and since when?
2. If the vendor slips two weeks, what else moves — and who needs to know today?
3. Why was the design decision from March made the way it was, and who signed off?

Most managers can’t answer any of the three. Not because they are disorganised, and not because their people are weak. They can’t answer because the information required doesn’t exist in any system. It exists in five people’s heads, and the only retrieval mechanism is a meeting.

That is the coordination gap. Everything below is about why a well-run organisation with a modern software stack still has it.

What you actually bought

Look at your stack honestly. Each system is good at something, and each one is structurally blind to the same thing.

Your project tool holds the plan. It doesn’t know the plan is now wrong. It will happily display a green milestone that everyone involved privately knows is dead, until someone updates it manually.

Chat holds the signal but has no memory. The message that mattered — “we can’t start until legal clears the template” — was accurate, was seen, and scrolled away in ninety minutes. Nothing in the system connects it to the task it blocks.

Email holds the commitments. In two mailboxes. Nobody else’s. When either person leaves, the commitment leaves with them.

The spreadsheet holds the roll-up. It was accurate at the moment someone typed it, which was eleven days ago, and producing it consumed a day of a good analyst’s week.

Your ERP knows the transaction happened. It doesn’t know it nearly didn’t, or that three teams spent a fortnight unblocking it.

Your BI dashboard shows outcomes. Downstream, in aggregate, after the fact. It tells you the quarter missed. It cannot tell you which handoff broke in week three.

None of these is a bad system. They are all doing their jobs. But notice what none of them holds: the connections between pieces of work. Who is waiting on whom. What breaks if this moves. Which decision is blocking which delivery.

Malone’s definition — coordination is managing dependencies between activities — is thirty years old and you probably met it in a strategy or operations course. The uncomfortable observation is not the definition. It is that your organisation has a system of record for customers, transactions, people, documents and conversations, and none at all for dependencies. The single thing that determines whether work finishes is the one thing nobody owns.

What the gap costs, in behaviours you’ll recognise

There’s no invoice for this, which is why it never reaches the budget. It gets paid in four other currencies.

Status becomes something people manufacture. A meaningful share of senior time each week goes into producing status for someone above, and into the meetings that collect it. That is not management. It is manual data assembly, performed by people expensive enough to be doing something else, producing a snapshot that expires the same afternoon.

Risk travels by personality. Whether a problem reaches you depends on whether someone is willing to raise it, how they feel about the last time they did, and whether they get airtime in the meeting. Your escalation path is a social process wearing a governance costume.

Every handoff loses fidelity. Engineering to procurement, procurement to the contractor, the contractor to operations. At each boundary, context is re-explained by someone who has already moved on. What survives is the deliverable. What is lost is the reasoning — which is precisely what the receiving team needs to avoid the next problem.

The same failure recurs across unrelated projects. Missed prerequisites, resource collisions, late approvals. You’ve seen the pattern three times. It repeats because no record of why survives long enough to change how the next one is set up.

Add the newest variant: you are now putting AI agents into these processes. An agent executes precisely and infers nothing. If your dependencies exist only in people’s heads, they are invisible to the agent too — so you get faster components and the same broken seams. Every agent you add is another division of labour, and division was never the part you were bad at.

You have tried to fix this. Three times, probably.

None of this is new. Every organisation of any size has noticed the gap and reached for one of three remedies. All three are sensible on the day they are proposed. All three fail in the same predictable way, and understanding why is more useful than any argument about features.

“We have developers. We’ll build it ourselves.”

The requirement looks small from the outside — a database, a few screens, a report. So something gets built, and it usually works. A dashboard that pulls from three systems. A workflow app for one process. The team that commissioned it is genuinely better off for about eighteen months.

Then the architect moves to another team. The integration breaks when the upstream system upgrades. Nobody owns the roadmap, because it was never a product, it was a favour. And the parts that were quietly skipped — the permission model that survives a reorganisation, the intake path for people who don’t use it daily, the dependency logic across teams that didn’t sponsor the build — were skipped because they are the expensive parts, and they are exactly what the gap consisted of. The internal build almost never fails technically. It fails on ownership, and it leaves behind one more system to reconcile.

“Let’s adapt something we already own.”

The engineering ticket system gets pointed at a cross-functional programme. Or SharePoint lists. Or the CRM, because delivery is sort of like a pipeline. This is efficient thinking and it has one flaw: an adapted tool keeps its native object model. You can bend a ticket into a dependency, but the system doesn’t understand what it now represents, so nothing downstream works — no aggregation, no detection, no honest reporting. Someone assembles it by hand again.

Worse, adoption stops at the boundary of the team that already lived in that tool. Which is precisely the boundary the gap sits on. Six months in, the work has split between the adapted tool and everything else, and a coordinator is now employed to coordinate the coordination tool.

Change that changes nothing.

The most expensive remedy of the three. A reorganisation. A new PMO. A governance framework, a cadence redesign, a revised RACI, a fresh set of steering committees. These produce a great deal of visible activity, and they are all — every one of them — another act of partitioning. New boxes, new owners, new meeting series. What none of them produces is new information. The person in the Thursday meeting still cannot answer what is blocked and who owns it; they now just answer it inside a different governance structure.

And here is the part that matters for anyone considering a genuine fix. A large change programme consumes the organisation’s appetite for change. Afterwards there is no air — for two years, sometimes three. Nobody wants to hear another proposal, and any proposal that arrives is met with the most powerful sentence in enterprise life: we tried that.

So the status quo does not merely survive a failed transformation. It is strengthened by one. Everyone now has evidence.

Which is why the gap persists in competent organisations. Not through ignorance, and not through lack of effort. Through three plausible remedies, each of which spends real money and real credibility, and none of which puts the dependencies anywhere a system can see them.

What would actually close it

Not a better task list. Five plain requirements:

1. The work and the connections between work sit in the same place. A dependency has to be data, not a sentence in a status update.
2. The system tells you when a connection breaks — before the meeting, without anyone deciding to speak up.
3. Everyone reads the same object at their own altitude. The contributor’s task, the manager’s initiative and the executive’s portfolio position are the same record, not three copies drifting apart.
4. The reasoning survives. Decisions, context and documents attached to the work they concern, retrievable in two years without an archaeology project.
5. It accepts work the way work arrives. If closing the gap requires every stakeholder to change their habits on day one, it will not close.

That is the specification for a work coordination platform: a system whose primary object is the activity and what it depends on, rather than the document, the transaction, or the message.

And four conditions, without which the specification doesn’t matter

Given the three failed remedies above, the software is the easy half. The conditions are these.

A cold head. Closing a coordination gap is not a transformation and should never be sold internally as one. The moment it becomes a programme with a brand and a launch event, it joins the category of things people wait out. Scope it small, keep it unglamorous, let the results argue.

Evidence, gathered before anyone commits. Not a survey about how people feel about collaboration. Concrete artefacts: how long the last three cross-functional deliverables actually took versus plan, where each one lost its weeks, how many hours a month go into producing status that expires the same day. You need this for two reasons — it tells you whether the gap is really your constraint, and it is the only thing that will hold the line in month five when someone senior asks why this isn’t finished yet.

A clear answer to what and when. Which work goes into the system, at what altitude, by when, and what explicitly does not. Coordination systems fail as often from over-modelling as from neglect. The organisation should be able to state in one sentence which class of work is coordinated here — and everything outside that sentence stays where it is until the first class works.

And the one nobody does: name what stops. This is where most implementations quietly become the fourth failed remedy. The weekly status meeting, the parallel spreadsheet, the deck assembled every Thursday afternoon, the escalation call, the chase email — these are not overhead sitting next to the system. They are the manual substitute for the system. If the infrastructure works and the rituals stay, you have added work rather than replaced it, and within two quarters people will reasonably conclude that nothing changed.

So decide in advance: when the dependency data is live and trustworthy, which specific meeting is cancelled, which report stops being written, and who has the authority to cancel it. Put a date on it. A coordination platform without a corresponding list of retired rituals is a cost, not an investment.

KanBo against that specification

Where the work lives. Work is held as Workspace → Space → Card. A Workspace is the organisational container — a business unit, region or programme. A Space is where one live outcome gets coordinated. A Card is the unit of work, carrying its owner, contributors, dates, custom fields, checklists, documents, discussion and full history. A card can appear in more than one Space as a mirror card — the same card, not a copy, so an update in one place is an update everywhere. Cross-team visibility becomes a property of the structure rather than something you have to keep asking for.

Who owes what to whom. Dependencies are modelled explicitly: parent/child for breaking work down, predecessor/successor for sequence — and each has a cross-space variant, so a card in the engineering Space can be the prerequisite of a card in the regulatory Space. That is what makes portfolio-level dependency real rather than a claim on a slide.

Obstacles are handled separately, and this is one of the more useful design decisions in the product. A blocker is a named object with a description, a reason and a responsible owner — scoped globally, to a Space, or on demand. Blocker impact analysis answers the question that actually drives escalation decisions: if this clears, what unblocks? In most tools an obstacle is a flag on a task and nobody owns it. Here it has a name and an owner, which is the difference between a problem being visible and a problem being someone’s.

What tells you before the meeting does. KanBo continuously checks every card against its own dates, its children and its predecessors, and records what it finds as issues on the card itself. The card carries a count and names each one in plain language — Card has 1 issue · Card is overdue — graded by severity: info, warning, danger. A child due after its parent’s deadline. A successor underway while its predecessor is unfinished. A predecessor that finishes after the task it is supposed to precede. An end date before a start date.

Two things follow from issues living on the card rather than in a report. Anyone who opens the card sees the problem at the same moment their manager would, which removes the reporting delay entirely. And because issues are data, a Space can be filtered by them — so “show me everything currently in trouble across this programme” is a view, not a request you make of five people. These are exactly the failures a plan cannot catch and a human only catches by paying attention at the right moment.

This is the answer to question 1 in the Thursday test. The system raises it; nobody has to be brave.

Keeping your own process without losing your reporting. Every Space defines its own statuses — name, colour, order. Each one is anchored to one of five fixed status types: Information, Not started, In progress, Completed, Cancelled. Small mechanism, large consequence. Custom statuses normally destroy analytics, because no engine knows that “Closed Won” or “Released to Site” means finished. The type anchors local vocabulary to a meaning the system understands, so a sales team, a construction team and a compliance team run genuinely different processes inside one fabric and still aggregate honestly.

Seeing it without asking. The same work renders as Kanban, List, Table, Calendar, Timeline, Gantt, Mind Map, Workload, Forecast Chart or Time Chart, with configurable grouping — by owner, status, label, due date, role or custom field. Two are worth singling out for a manager. Workload shows capacity against demand, which turns “two teams need the same person in March” from a March surprise into a January decision. Mind Map lets a team lay cards on a canvas and draw the connections between them — dependency modelling before execution, rather than dependency discovery during it.

Getting people to actually use it. A Space or an individual card can be given its own email address, with control over who may create work that way. Teams that live in Outlook forward the request and it arrives as a structured card with an owner and a date — no tool migration on day one. KanBo dates can appear in Outlook as tasks or as calendar appointments, per user preference. MySpace lets an individual pull cards from anywhere into one personal working view, which is the answer to “not another system to check.” And stakeholders who only need visibility hold Reader seats — a wide audience can watch without consuming licences meant for people doing the work.

Making it repeatable. Space and Card templates carry the process itself — statuses, fields, roles, required steps — so the quality gate, the compliance review and the sign-off are structural in every instance rather than dependent on a diligent person remembering. This is how a lesson learned on one project actually reaches the next one. KanBo Robot handles the mechanical follow-through with no-code triggers and actions: when a card hits a status, notify, assign, move, update.

AI agents as participants, not another silo. Through KanBo’s MCP layer, agents operate on the same cards, relations and permissions as people. Given the point above about agents amplifying the seam problem, this is the structurally important one: an agent working inside the coordination record is a participant; an agent working outside it is one more disconnected tool.

Who can see what. Six permission levels — none, reader, visitor, member, owner, super — inherited from workspace to space rather than re-granted each time, and grantable to groups that can themselves contain groups, matching how your organisation is actually shaped. Full activity history for who changed what and when. Deployment on cloud, on-premises, GCC High or hybrid, which matters when the coordination record is also evidence a regulator may ask for.

What it doesn’t do

It doesn’t fix a culture where bad news is punished. It makes bad news harder to hide, which is genuinely useful and genuinely uncomfortable in the first quarter.

It won’t help work that is truly parallel. If your teams operate independently with few handoffs and stable processes, standardisation is a cheaper answer and you should use it. This earns its cost where work crosses boundaries and a missed dependency is measured in weeks or in regulatory exposure.

And modelling every dependency in the organisation is as bad as modelling none. Deciding which dependencies matter is still your job. A coordination system used without that judgement produces very precise noise.

A sensible first move

Don’t roll it out. Take one Space, one real cross-functional outcome that is currently painful, and run it for a quarter. No launch event, no programme name, no steering committee.

Before it starts, do two unglamorous things. Write down what the last comparable initiative cost you in slipped weeks and where they went — that is your baseline, and you will not be able to reconstruct it later. And nominate one ritual that gets cancelled if this works: the status meeting for that initiative, or the report someone assembles for it every week. Name it now, while nobody is defending it.

Then re-run the Thursday test at the end, and use those three questions as the acceptance criteria. If at the end of the quarter you can answer what’s blocked and who owns it, what moves when the vendor slips, and why the March decision was made — without calling anyone — then cancel the ritual you nominated, and you have both a closed gap on one initiative and a defensible number for what closing it is worth across forty.

If you can’t, you’ve spent a quarter and learned something specific about where your coordination actually breaks. That is not a bad outcome either.

Strategy fails at the seams, not in the components. Coordination is the last major function in the enterprise still running without a system of record — and unlike the others, its absence never shows up as a line item. It shows up as weeks.