Chapter 13

Stage Reporting

In This Chapter

Team level reporting

Reporting to the Project Steering Group

Specialised reports

Reporting during a stage provides control to the management level ‘above’. In the case of reports prepared by the Project Manager, that level above will mostly be the Project Steering Group (PSG). In the case of reports produced by a Team Leader, well they’ll normally go to the Project Manager.

Reporting is simple on the one hand, but needs careful thought on the other. You want to include enough information for effective control but over-reporting merely drives up overheads … or worse. Every bit of redundant information is written by someone, wasting time and effort. But then the recipients of the reports then have to scan through the redundant information to find the bits they really do want, and that wastes more time still. The ‘worse’ is that reports become so unwieldy that those who should be reading them simply don’t bother to look at them at all.

There’s inevitably a bit of overlap between this chapter and others in that it covers some of the same information. During a stage you are going to check progress, obviously enough. And during the stage you will also report progress so there’s an inherent information overlap with the checks. However this chapter has a different objective from other parts of the book and that is to help you decide on what should be reported, and then how.

The KISS Principle: ‘Keep it simple, stupid!’

Team Progress Report Checklist

If you’re the Project Manager, you’ll set down your requirements for the Team Progress Reports in the relevant Work Package, but you may base that on a default report format that you’ve set down in the Communications Plan. As with all reports, the content must be balanced. In the case of the Team Progress Report you’ll strike that balance depending on the amount of autonomy you give to the team and the characteristics of the work, such as whether it’s very high risk, or low risk, or something in between. The Team Progress Report will be prepared by the Team Leader, or by an individual team member if the ‘team’ consists of people working on their own (effectively as a team of one).

• Progress: this item is a no-brainer. However think exactly what information will be best in terms of being the most accurate and the most helpful.
• Productivity: Team productivity information is generally very helpful, but strangely absent on standard reports in most methods and approaches. The information is very helpful for forward projections though, such as that the team is performing better than expected and getting through work 15 per cent faster than set down in the plan.
• Problem updates: A Team Leader should report problems that have stage level implications using a Project Memo or equivalent. However the progress report is a useful place to update the Project Manager on what is happening with a reported problem at the moment, such as that it has now been resolved.
• Quality: Beware of quality reporting, even though it’s a no-brainer that quality is important. However, the information will probably be readily available elsewhere, such as on a Quality Checklist, so you may not need to include it in the Team Progress Report. The item is mentioned here because it’s in many project standards.
• Work in hand and forecast: Again, beware of this item even though it looms large in one leading project method. The work in hand and to be tackled next is already set down on the plan so again this information is already available. Including the same data all over again in a report is usually just wasteful.
• Comments: This section of the report can be very brief, but at the same time it’s enormously helpful. It is space for the Team Leader to comment on any aspect of the work of which he thinks the Project Manager needs to be aware. If there is nothing relevant to say, the Team Leader can leave this section blank on a particular report.

As also mentioned in Chapter 12, the progress measuring information in most computer tools is the percentage of the various activities which is complete. However, this is a guide at best and unreliable at worst. For team reporting, try to get facts not estimates. For example, that fact could be the completion of lower-level components of the products being created.

Stage Progress Report Checklist

As with other reporting, be careful to design the Stage Progress Report to include information that is both necessary and wanted by the PSG. There’s no point in having huge reports crammed with detail if nobody is ever going to read them. The Project Manager will prepare the report at the frequency that the PSG wants it and that’s often monthly or two-weekly.

Make the progress report ‘digestible’ for the PSG managers that it’s primarily designed for. That might be with ‘dashboard’ reporting with diagrams and graphs or giving the report as a brief presentation with a short handout rather than a formal written document. The Work Flow Diagram, colour-coded to show delivery, is especially effective.

When I’m invited to give project governance briefings to senior managers I recommend that they implement standard reporting across seven main areas, then with an addition item for any comments the Project Manager wants to include. The information can be fitted easily on a very easy-to-read, three-page report making use of dashboard style graphs and diagrams, so it’s very fast for managers to absorb the information. This checklist reflects the governance advice.

• Progress: This might be at stage level or project level or both. Having approved a Stage Plan, some PSG’s then like to focus on the project level to keep the ‘big picture’. Either way report progress with fact, notably product delivery.
• Cost: Spending on the stage compared to plan, and possibly overall spending on the whole project compared to plan.
• Time: An assessment of if the stage will finish at the planned time, early or late.
• Benefits: Comments if needed on anything in the last reporting period that has an impact on the level of benefits and the viability of the project.
• Performance: The performance of the teams against what was expected. Performance information clearly has implications for whether or not the project will stay on track and deliver to target.
• Quality: Measures to show the achievement of quality. This is often neglected in project governance and oversight but it’s a vital element.
• Risk: A statement on the current overall position on risk and any particular ones that the PSG should know about. However, you can leave this item out if you are also preparing a dedicated Risk Report – see the next checklist in this chapter.
• Comments: Space for the Project Manager to comment on any aspect of the running of the stage so far and the next reporting period.

Be wary of organisational standard project reports that have been designed by over-zealous administrators. They may have little real experience of project management and no understanding at all of the control needs of your specific project. If a standard report format is unsuitable but mandatory, the Sponsor and Project Manager should work together to challenge it or at least get exemption for this project on the grounds that it will lead to unnecessary overheads.

Risk Report Checklist

Depending on the level of risk in the project, you might include the risk information in the normal Stage Progress Report or have a separate, dedicated Risk Report. Another reason for having a separate Risk Report is if it has a wider circulation than progress information, such as to your organisation’s Risk Manager.

• Overall status: The Project Manager’s assessment of the overall risk position in the project. For example, is it increasing, decreasing or is it stable at the moment? Depending on the nature of the project it may be worth having separate reporting sections for upside risk (opportunities) and downside risk (threats).
• High severity risks: Specific information on the status of each high severity risk.
• PI Matrix: You can show the position of each risk in terms of probability and impact (PI) on a matrix. This is a good visual summary.
• New risks: A summary of new risks that have been identified since the last Risk Report.

Financial Report Checklist

You may just report project spending to the Sponsor, but often it’s necessary to keep the organisation informed too. That might be by making entries in a financial computer system or with a dedicated report. If you will use a report, consider what information should be included using this checklist.

• Spend: The money spent in the reporting period.
• Commitment: Money that has been committed, such as by placing an order on a supplier, even though there has been no spend yet.
• Variation: The difference between the actual spend and what you expected to pay for those same things.
• Changes: Information, where necessary, for instances where the spending pattern is different from that which you planned and which finance staff therefore expected. For example, something may have been purchased earlier than planned to take advantage of a short-term special offer from the supplier. Although the project looks overspent at the moment, actually it isn’t. Early spending is, of course, very different from overspending.

If you’ll have to submit financial reports to your Finance Department during the project, be sure to find out how the finance people want the information presented. For example as a simple list of items with totals against them on a sheet of paper, or in a spreadsheet, or by entering it directly into their financial computer system. If you supply data in the wrong format just through ignorance, you’ll be making work for someone to ‘translate’ that into the format that your finance staff need. Instead, find the preferred form and then use it. If there’s some reason why your data won’t fit the normal financial format, talk to the finance staff to find out how they would like you to deal with it.