Reporting does not replace a shared operational view
By Charley Fredaigues
- Organization
- Project
Reporting is a periodic snapshot of what has happened, produced for leadership. A shared operational view is a common reading of what is happening now, available to those who need to act. Both are useful. But the first is often asked to do what only the second can do, and people are then surprised to discover drift too late.
Many organizations have a polished monthly report, up-to-date dashboards and colored indicators. Yet many of their executives learn about problems from their clients. This article explains why, what sets the two tools apart, and how to move from one to the other without rebuilding everything.
What is reporting, and what question does it answer?
Reporting is produced by someone, for someone (most often leadership, a board, a funder), from selected, aggregated and formatted data, at regular intervals: every week, every month, every quarter. It answers one question: what happened?
It is a tool for accounting for a period, and it is valuable for that: keeping a record, presenting a summary to a third party, comparing month over month. It does not answer two other questions, which are the operational ones: what must be decided now, and who takes care of it?
What is a shared operational view?
It is one common reading of the situation, available to those who work on it: the project manager, the manager, leadership and, when relevant, the client. It has four characteristics.
- One reference record per commitment, not one version per department.
- Up to date with what everyone knows, not only with what was presented at the last committee.
- Deviations visible as they form, with an owner and a decision attached.
- A reading based on each person’s rights: shared does not mean exposed to everyone.
It does not produce a document: it is consulted. And above all, it can be read without going through anyone.
Reporting and a shared view: the differences
| Reporting | Shared operational view | |
|---|---|---|
| Question asked | What happened? | What is happening, what must be decided? |
| Relation to time | After the fact, at fixed intervals | At the moment you decide |
| Who produces it | Someone, who copies and formats | Those who work, as they work |
| Who reads it | Leadership, sometimes a third party | Everyone, according to their rights: team, leadership, client |
| Level of detail | Aggregated: one color per project | Precise: the deviation, its owner, its decision |
| Main risk | A reassuring dashboard that smooths over the deviation | Data not entered, therefore wrong |
| What it enables | Reporting, keeping a record | Deciding, anticipating, answering a client |
The two columns are not opposed. They simply do not play the same role.
Three situations where reporting shows nothing
Three situations encountered in the field, told without any name or detail that would identify anyone. In each, the organization had a report. It was of no use, for three different reasons. We describe them in more detail, from the angle of leadership learning everything from its client, in another article.
Reporting looks back, the negotiation lies ahead
An executive visits a client to renegotiate a contract. The same day, a technician from their company causes an incident on the client’s site that stops part of the production. The meeting changes course: nobody talks about the renewal any more, but about trust.
The company’s monthly report contained nothing of this, and could not: it described the past month. What mattered was what was planned at this client that day. A view of upcoming events at a client (meetings, interventions) would have avoided having a decisive negotiation coincide with a risky operation. Reporting does not look ahead.
Reporting says "late", not "who is waiting for whom"
A client calls the head of a service provider to complain about a delivery that has not happened. The executive apologizes and puts pressure on their teams. The project report did show "late", in red. It did not show that the teams had been waiting for the client’s documents for weeks.
An aggregated indicator says there is a deviation. It does not say on which side the cause lies. Without that, the executive spoke to the wrong people, and missed the chance to ask the client what was blocking on their side. What had to be read was not the color of the project, but the list of what was pending, and from whom.
Everyone reads their own report, nobody reads the same one
A client is slow to pay, claiming they were not delivered. They were: their own teams signed the acceptance. But their executive knew nothing about it. The provider had the proof in its report, which the client’s executive does not read; the client had the signature in its files, which its executive had not consulted.
Here the problem is not the absence of reporting, but the fact that everyone has their own. Two versions, two readers, no common reading. An acceptance recorded in a place both executives can read ends the discussion before it begins.
Why reporting alone is not enough
These three situations illustrate five limits, which come from the very nature of reporting.
It arrives after the fact. A monthly report says at the start of the month what happened the month before. A deviation that appeared in week two had three weeks to grow before being read. And what is to come (an intervention, a deadline) is not in it.
It is made by hand. The data is copied from several files, formatted, proofread. That time is not spent reading or acting. And when the deadline presses, the report that is ready is the one that is published, not the one that is right.
It aggregates, so it smooths. One color per project, an average per department: the deviation that matters, precise and localized, disappears into the summary. The dashboard is reassuring because it is a summary, and a project "slightly late" can hide the fact that one single thing blocks everything else.
It records, it does not attribute. A report says a project is late. It does not say who is responsible, what has been decided, or what remains to be decided. In our second situation, that is exactly what was missing.
It exists in several versions. Finance, production and sales do not always have the same figures, or the same definition of a project "being late". The committee then spends its time reconciling versions instead of deciding. And the client has its own version.
What creates a shared view
It is not first a tool, it is an organization. Four elements make it up.
1. One reference record per commitment
For each contract, project or intervention, a single record that is authoritative, in one place. The other documents (presentations, dashboards, minutes) are drawn from it, not the other way around. When two people disagree, they open the same record.
2. Named responsibilities
Who enters data, who reads, who decides. Data without an owner for its updates is out of date the day the project speeds up. Data without a designated reader is read by nobody. Data without an expected decision-maker leaves the deviation waiting.
3. A short, regular ritual
A weekly check-in, focused on deviations and the decisions to take, whose decisions are recorded and dated. It is not one more committee: it is the moment when the shared view is put to use. Without it, it becomes one more dashboard that nobody consults.
4. Clear access rules
Everyone reads what concerns them, no more, no less. The table below gives an example for a client-supplier relationship.
| Who | What they read | What they do not read |
|---|---|---|
| The project team | Their actions, their calendar, the state of the commitment | Margins, other teams’ internal costs |
| The supplier’s leadership | Everything: progress, finances, workload, deviations | The client’s internal notes |
| The client | What concerns them: progress, actions requested from them, acceptances to validate | The supplier’s margins and workload |
| The client’s leadership | The same as their team, without going through it | The supplier’s internal data |
Sharing does not mean exposing everything: that is what makes the idea acceptable on both sides.
What becomes of reporting?
With these four elements, reporting changes role. It stops being the source of knowledge and becomes a consequence of the shared view: a summary drawn from the same data the teams read every week. It then keeps its usefulness, which is to account for a period, and it costs much less to produce, since it no longer has to be rebuilt.
When is reporting enough?
It would be wrong to say a shared view is always needed. Reporting alone is enough when:
- activity is stable and predictable, with few commitments in progress;
- one person holds all the information, and leadership is that person;
- there is no client to report to along the way.
As soon as several teams share a commitment, or a client has to be informed along the way, reporting is no longer enough: it describes what has been done, not what is being decided.
A simple test, then four weeks
Three questions
- How long does it take to produce the monthly report, and how long to read it?
- Who read it, and what did they decide afterwards?
- Is a deviation that appeared last week visible today, and to whom?
If the time spent producing clearly exceeds the time spent deciding, or if you cannot name a decision made thanks to the report, the snapshot is polished but the view is missing.
Moving to a shared view in four weeks
On a single client or a single project, never on the whole organization at once.
- Week 1: choose the reference record. List everything that exists on this commitment (files, emails, calendars, documents) and decide where the authoritative record is. Remove parallel copies.
- Week 2: name. An owner for updates, readers, a decision-maker. Write in three lines what each person must do and when.
- Week 3: hold the weekly check-in. Twenty minutes, on deviations and decisions only. Record what is decided.
- Week 4: draw the report from the record. Produce the monthly summary from the same data. Measure the time saved, and what still has to be done by hand.
And the tool?
One more dashboard does not create a shared view. What makes it sustainable is historized data, read by everyone according to their rights, and rituals that rely on it. This is the principle behind pylotik, the operational commitment management software we publish: leadership, teams and the client read the same data, each at their own level, and the management summary follows from it.
It has its limits, which we prefer to state: the information displayed is what the teams have entered, it does not measure it for them, and it replaces neither named responsibilities nor the ritual. It can be used without any consulting engagement, and we work without imposing it: the product page says what it does and what it does not do.
The starting point remains the same: knowing who must be warned of a deviation, when, and who decides. We cover this in an article on executives who learn about problems from their clients, with a "who warns whom" table to fill in.
Frequently asked questions
What is the difference between reporting and a shared operational view?
Reporting is a periodic summary produced for leadership: it answers "what happened". A shared operational view is a common reading of the situation, available to those who act, at the moment they decide: it answers "what is happening and what must be decided". The first accounts for the past, the second enables action.
Should you get rid of reporting?
No. It remains useful for accounting for a period, presenting a summary to the board or a funder, and keeping a record of periods. It simply is not enough to decide: it is better drawn from the same data the teams use every day, rather than rebuilt by hand.
Does a shared view mean showing everything to everyone?
No. Shared means everyone reads the same data, not that everyone reads everything. Access rights remain different by role: a client sees what concerns them, a team what it carries, leadership everything. A supplier’s margins and internal workload do not have to be visible to its client.
Why is a "late" indicator not enough to decide?
Because it says there is a deviation, but not on which side the cause lies or who must act. A delay can come from something the client owes as much as from a gap in the team, and the response is not the same. You have to read what is pending, since when, and from whom.
How do you avoid two executives arguing over two versions of the facts?
By recording the facts that bind both parties (a delivery, an acceptance, a committee decision) in a place both can read, with their date. The discussion is then about what to do, not about what happened.
Where do you start to move from reporting to a shared view?
With a small scope: one client or one project, one reference record, an owner to keep it up to date and a short weekly check-in devoted to deviations. The existing report is then built from that base, and the approach extends to other clients once it has proved itself.