Project steering & reporting

These three notions are often used interchangeably, whereas they name three distinct activities that are not organized the same way. **Steering** is the project manager's continuous act of decision-making. It consists of observing the real state of the project, anticipating drifts, arbitrating between options, launching corrective actions, and reporting on these choices to those who will be affected by them. It is a daily activity, carried by the project manager themselves, oriented toward action. **Reporting** is the production of a documented state of the project, at defined intervals, intended for others than the project manager: management, sponsors, project steering committee, sometimes the client. It plays three distinct functions. The first is synchronization: aligning the reading of the project between the project manager and their counterparts, and feeding decisions that go beyond their own arbitration perimeter. The second is traceability: reporting, combined with the minutes of the bodies it feeds, constitutes the project log, that is, the history of successive states, the trace of decisions taken, the memory of arbitrations. It is this trace that allows, months later, to reconstruct why such an option was chosen, and which protects in case of dispute. The third is stepping back: producing a report forces the project manager to step out of the day-to-day, to aggregate, to interpret, to formulate. A project manager who entirely delegates their reporting loses this periodic opportunity to regain height on their own project. **Governance** is the framework that defines who decides what, on what criteria, at what frequency, with what escalation. It precedes steering and reporting: it sets the rules of the game. A poorly governed project will have neither clear steering (who has the power to decide?) nor useful reporting (to whom, to decide what?). The frequent confusion comes from the fact that the three activities meet in the same meetings (steering committee, monthly review) and that a single document often serves all three. But their purposes diverge: steering seeks action, reporting seeks synchronization, governance seeks the framework. A project where one of the three is confused with the others loses efficiency.

A project manager who opens their weekly report facing thirty indicators has already lost the game: they are no longer steering, they are consulting tables. The quality of an indicator system is judged on three things, in this order: the number, the nature, and the use made of them. **First discipline: fewer indicators, better chosen.** An aircraft cockpit contains about a dozen priority instruments that the pilot looks at every few seconds, and about a hundred secondary instruments that they consult only in case of an alert. This hierarchy is not a constraint, it is a safety condition: beyond a certain number, the human eye no longer sorts. A project reporting system follows the same logic. A good indicator meets three cumulative conditions: it measures an actionable variable, that is, a variable on which the project manager has an action lever; it produces an actionable signal, readable in seconds and interpretable without additional expertise; it triggers at least one possible decision if the threshold is crossed. Indicators that do not meet these three conditions are noise that masks the useful signals. On a large project, five to seven well-chosen indicators are enough to cover current steering. Adding more does not add anything to the decision: it dilutes attention. **Second discipline: prioritize predictive signals over drift observations.** An indicator that measures drift after the fact (actual spend against budget, cumulative delay on missed milestones) usefully informs where we come from, but says nothing about what remains to be done. A predictive indicator does the opposite: it compares an actual trajectory to an expected trajectory, and signals the gap before the impact is consumed. The *Fever Chart* is the canonical example in a project where deadlines govern success. It compares the consumption of the schedule buffer to the progress of the critical path and makes visible, in real time, whether the trajectory holds or drifts. It is not one indicator among others: it is the pivot of a steering approach where the schedule drives the decision, because it captures drift at its source, on the duration variable, before it transmits to the budget. Other predictive indicators come as complements. The consumption of the contingency reserve, read by time-phased breakdown, produces an analogous signal on the budget. The S-curves of EVM (*Earned Value Management*), when they rest on a serious modeling of activities and not on a simple linear extrapolation, offer a useful projective view, provided they are coupled with a critical path surveillance, without which they can mask a trajectory drift by averaging it over the whole project. Without this hierarchy, financial drift indicators take all the space in a report. Yet in a project, they are almost always the delayed consequence of an earlier schedule drift: watching them without watching the upstream signals amounts to measuring the smoke while ignoring the fire. **Third discipline: reporting is an act of analysis, not of collection.** The project manager's added value is not to gather the numbers, it is to interpret them. A report that limits itself to a table or a dashboard without commentary does not help its recipients decide: they are reduced to interpreting for themselves, or to demanding justifications. Each indicator must be accompanied by a reading: what it means, what it triggers, what action is being taken. It is also for this reason that reporting must remain carried by the project manager themselves: delegating it to a deputy or to a PMO turns a steering act into an administrative task, and deprives the project manager of the hands-on grasp they need to make their own decisions.

The drift of a project prepares itself long before becoming visible in financial indicators or in a delivery delay. An attentive project manager has several classes of upstream signals at their disposal, each detectable if it is watched explicitly. **Schedule signals.** The consumption of the schedule buffer relative to the progress of the critical path is the earliest and most reliable signal. A buffer consumed at 40% while only 20% of the critical path has advanced is a strong alert, independent of other indicators. The displacement of the critical path itself (a non-critical activity that shifts to critical) signals a deep reconfiguration of the dependency network, often invisible in an aggregated report. The trend of these signals matters more than their point value: an accelerating consumption is more worrying than a stable consumption even at a high level. **Team signals.** Unusual turnover on critical resources, the accumulation of blockers raised without resolution, growing difficulty in obtaining slots with certain contributors, are signs that the project is losing its internal momentum. These signals do not appear in any standard table; they require active listening from the project manager and a fine reading of daily interactions. **Interface signals.** External dependencies that begin to slip (supplier delivery, client decision, regulatory arbitration) are a classic upstream signal. A project manager who follows their project only internally misses half of the drift causes to come. **The silence signal.** A project where everything seems to be going well for several consecutive reviews deserves particular attention. Silence can reflect healthy steering, but it can also reflect a team that has stopped raising difficulties, a report that has become formal, or a culture where problems are hidden. An experienced project manager knows how to distinguish the two and actively looks for topics on a project that is too quiet. Detecting early therefore requires three joint postures: instrumenting predictive signals (buffer, critical path, trends), maintaining a direct link with the team and the interfaces (not only reading reports), and cultivating a healthy suspicion toward projects that report no difficulty. A project that never presents a problem is almost always a project whose problems have not yet been seen.