The information food-chain, or death by reporting?
What is project reporting for?
Most of us do it, some enjoy it, some see it as a distraction, done well it can genuinely help but it can also confuse and mask real problems. It’s really trying to do just one thing – make a statement about the true status of the project, backed up by some facts.
Projects consist of people who deliver stuff – the project management team (project managers, engineers, contractors) and people who get the benefit when it’s complete – the sponsor team (stakeholders, senior management, customers). The latter clearly need assurance they’re going to get that benefit and reporting is a medium by which the first group provides that assurance to the second; it is usually one-way – a broadcast – but is it trusted, as the BBC World Service, or mistrusted, like Trump’s ‘fake news’? Do you know who actually reads your reports? If not, find out.
Too much or too little?
Agile PMOs allow different levels of reporting, proportionate to the complexity or duration of the project. Rigid PMOs impose fixed formats, templates and software which teams must stick to, regardless. Sometimes this leads to a grand job-creation scheme of unofficial reports done ‘on the side’ which often tell the real story!
A common tactic of immature project management teams is to carpet-bomb stakeholders with a huge amount of detail, though this frequently leads to pleas for executive summaries and single paragraphs that can be lifted into board reports. This approach can create more cottage industries, dedicated to writing reports that are too long and which are often more about justifying than demonstration of control.
Of course, reporting arrangements might be contractually laid out in advance as part of the project remit. This could be challenged if you can show that a disproportionate resource will be tied up in writing; a grown-up and reasoned discussion can right-size the project reporting function from the outset.
Another school of thought is that reporting should provide just enough information to allow key project decisions to be made (and no more). Decision theory calls this ‘satisficing’ – a portmanteau term combining ‘sufficient for’ and ‘satisfying conditions’. This works when the project management team has the trust of the sponsor team to only report what is needed to allow decisions to be made.
Whatever the regime chosen, it’s a good idea for the project management team to agree up-front with the sponsor team what will be reported, in what depth and how frequently. How many people will read it, and who are they? What will they expect to do as a result of reading it? Ask! It’s an even better idea to build in flexibility, so that under normal/on-target circumstances, reporting can ‘satisfice’; but where risks or issues threaten delivery, more detail or depth can be provided.
Reporting and not doing
There is a suspicion among some delivery teams that too much reporting equates to ‘down time’ that could be better spent delivering. I remember a telecoms engineer explaining an embarrassing delay to his irate boss by saying “All the time I’m telling you why I haven’t fixed it, I’m not fixing it…”.
Conversely, there is reasonable scepticism among sponsor teams that everything in the garden maybe isn’t rosy, if they are not getting any updates at all. In nearly forty years of project management I have never heard a sponsor say “Well, no news is good news!”. Project management colleagues may have experienced when a contractor runs into trouble, the first thing that stops is their programme plans. Nobody like to report bad news.
Current reporting trends
Gantt charts, S-Curves, flow charts and PERT charts arose from our profession; used well these can convey project status concisely and elegantly and I don’t propose to re-evaluate them here. Instead I’ll pick just two recent report formats:
A currently trending ‘thought-virus’ is to replace written reports with dashboards as a way of assembling snippets of connected information about the project on a single sheet. Arising out of visual representations of ‘balanced scorecards’, dashboards have their place, especially when kept simple; unchecked, they can morph into bloated patchworks of complex graphs, tables and paragraphs of tightly-packed two-point text that is impossible to read – adding so much information that they have to grow from A4 to A3 or bigger. If your car dashboard was this complicated, you would crash in seconds!
Red-Amber-Green reporting can be useful short-hand for status, though ideally containing a key, defining what factors will trigger a colour change. Modern thinking is to apply composite measures that account for Time, Cost and Quality/Scope in these factors (plus possibly safety and risk). It may be necessary to use other colours, for example blue for completed. Upward inheritance of RAG status raises the hottest colour to the top of a hierarchy – to catch attention, then lets you drill down to find the problem.
The information food chain
Project data is the raw stuff of measurement, which gets refined by analysis into information. However, even information requires further concentration into what we’d call intelligence. ‘Intel’ is then used by someone with a prerogative or need to generate an action.
Thus, it follows that if project reporting moves further up the food chain and provides the sponsor team more concentrated intel then the project manager and the sponsor team can make clearer and quicker decisions.
Conversely, one sure-fire way project management teams will find out that their reports are missing the mark is when the board or sponsors ask for more and more information, and at lower and lower levels. This suggests that the project manager’s food chain is no longer delivering nutrition. Death by reporting often ensues.
Reporting and knowing
A commonly held epistemological definition holds that that knowledge consists of justified true belief. In the same way, if a project manager can justify that the project is truly on target using simple and elegant reports, the sponsor knows they are in good hands and there is no need for an expensive army of reporters.
1 comments
Log in to post a comment, or create an account if you don't have one already.
Great post - particularly like the flexibility around DashBoard approaches. If a DashBoard throws up significant challenges month after month, then the content shouldn't be simply "increased", it should be refined - throw out the un-challenged aspects and insert the new responses to meet demand. It is often what you dispense with which makes a product stronger. Then next month do the same...... I wouldn't want to see any DashBoard format set in stone long-term: if that were to happen either (a) it is magnificent in every respect and doesn't need to react to the natural consequences of change or, (b) much more likely, the end user isn't bothered to critically review it and on we plod until we have to play catch-up at the eleventh hour