The Teal Book: Part E
The purpose of reporting is to ensure the management team(s) and interested parties are aware of the current status and outlook of the work relative to the baselined plan, particularly with respect to the likelihood of achieving the objectives. Reports can also act as a prompt for requesting advice, direction and decisions and for prompting preventative and corrective action to be taken.
The portfolio director and senior responsible owner have prime accountability for their portfolio, programme or project, respectively. Reporting is a vital aspect of assurance, when they are routinely kept up to date on the status and outlook of the work they are directing. Their boards have similar needs.
Just as a portfolio director and a senior responsible owner need to understand what is happening in order to fulfil their duties, so each team below them relies on the work of others if they are to perform their own roles effectively; they need to be aware of anything which could potentially disrupt or enhance their work.
A good reporting framework can:
Reporting is how information flows among portfolio, programme, project and work package teams. It focuses on the status of work, analysis of variances and forecasts of future performance.
Reporting is different from stakeholder engagement (see Chapter 26: Stakeholder engagement) and communications (see Chapter 27: Communications). Reporting focuses on providing the status of the work while stakeholder engagement focuses on ensuring the needs and concerns of stakeholders are addressed appropriately and communication on ensuring interactions with stakeholders are effective.
Good reporting relies on good control (see Chapter 17: Controlling). A report should be derived from the analysis and insight gained from controlling the work. Reporting should not replace direct conversations, meetings and other interactions needed to manage teams and control the work. Figure 18.1 shows reporting in the context of the control cycle and can be applied at every level in the project delivery hierarchy. Work should be undertaken in accordance with the plan using the delivery approaches defined in the governance and management framework, with progress tracked using appropriate measures.
The progress information is assessed and analysed and, where appropriate, collated into reports which, as shown in Figure 18.2, may be:
Action should then be taken to address any variances or problems. For this reason, reporting should be forward-looking. The aim is to prompt action to keep work on course to meet the defined objectives, while taking advantage of opportunities and reducing the impact of threats.
Reports should meet the needs of those receiving them. Each report format should be designed with the recipients in mind. Those needs differ across the project delivery hierarchy as each manager at each level focuses on their overall objectives. Lower levels tend to focus on the detail of specific deliverables, outputs and outcomes. Middle and higher levels focus more on the interdependencies and the achievement of outcomes and benefits. The higher up the hierarchy, the more outcome- and benefit-focused, holistic and wide ranging the reporting should be.
The frequency of the active reporting cycle should be both informal with managers reacting to day-to-day circumstances and also formal, usually with defined time periods, usually synchronised with the control cycle and often feeding into wider organisational reporting.
So that those involved in the work can understand the part they play in the team effort to meet the overall objectives, reporting, as shown in Figure 18.3 as an example for a project, needs to be:
Every project delivery management role has a reporting responsibility upwards through the project delivery hierarchy. This Is what most people think of when ‘reports’ are mentioned. It tends to be the most formal aspect of reporting.
The portfolio director has overall accountability for reporting the status of a portfolio to the wider organisation and, where necessary, external bodies such as regulators. This report is usually the responsibility of the portfolio manager on their behalf, with the draft of that report fulfilling most of the portfolio director’s information needs; additional information can be included in a supplementary report, if necessary.
A similar approach can be taken for programme and project reporting. The senior responsible owner has overall accountability for reporting to the next higher level (such as to programme or portfolio level) with the report generally drafted, on their behalf, by the programme manager, project manager or manager of other related work, as appropriate.
A work package manager should report on their work to the respective project manager or manager of other work.
While each manager at each level receives reports from the leads at the next lower level, such information does not generally fulfil all their needs. Managers also need to be aware of deliverables they are relying on from other teams and understand the risks and issues other teams are facing. The formality of this reporting tends to rely on the proximity of the teams. If closely located or meeting frequently, such reporting can be less formal.
Likewise, each manager needs to understand, from the next higher level, the context of the work they are managing, if they are to make reliable decisions and not accidentally cross the decisions of others. This requires each reporting manager to keep their peers and their team members informed. This reporting tends to be less formal and can be, for example, a standing item at team meetings.
In many cases a single person is not able to collate all the information needed and so the above roles can be supported by people from a support office. Support office staff often have a responsibility for some aspect of controlling the work and so have direct access to the information needed. As reporting can be designed to work in many ways, it is convenient to think in terms of a reporting manager, for example, a project manager for a project and a report author, who drafts the report on their behalf. A manager who drafts their own report is also the report author.
As described in 18.4 on what is reporting, reporting can be active, when a manager sends a report to someone, or it can be on-demand, when a manager draws the information they need from a data repository.
The advantage of active reporting is that the reporting manager can explicitly raise the points they believe the recipients need. The disadvantage is that it can take time for reports to pass up through the project delivery hierarchy and therefore the information can become out of date. When working in a matrix, focus on coaching people to write good reports: repeated editing of reports as they pass up the line increases the work and time spent on reporting activities, and can introduce delays and inaccuracies.
The advantage of on-demand reporting is that it is instantaneous, but it does rely on the repository being relatively up-to-date and on the recipient wanting to, and being able to, extract what they need. Each set of information needs to be time-stamped so the recipient knows how current the information is. Where it fulfils the need, on-demand reporting avoids having a formal reporting cycle and removes the time lag associated with reporting up the delivery hierarchy. Chapter 24: Information and data management gives more detail on information management.
In practice, reporting is likely to be a mix of active reporting and on-demand reporting. For example, a periodic report could highlight the few risks that the manager wants to draw attention to, which might not necessarily be the most important overall. Hyperlinks could however be provided to enable the recipient of the report to access a live risk register with the full details on all the current risks (see Figure 18.4).
Reporting brings together information gathered from every practice in The Teal Book and while large volumes of information are sometimes needed to control the work, a report need only highlight the information which is important to the recipient at that point in time.
Bear in mind that the recipient might receive multiple reports; keeping reports focused and to the point helps ensure requests for advice, direction or decision are identified and information is acted on, as well as making best use of time, both in preparing and reading reports. The reporting manager should agree, as part of defining the report, how the recipient would prefer specific requests highlighted. For example, by including such requests:
Forecasts, particularly those which extend far into the future, are uncertain and people are often reluctant to commit to a date or cost which for example, they know is uncertain. In some cases, they might insert a margin of informal contingency which is invisible to the report recipient. If this is done at every level, this can lead to dates being pessimistic and costs being bloated, and even threaten the viability of the business case for the work. It is better to have reports on benefits, time, costs or resources reported as either ranges or with probabilities or confidence markers so the recipient of the report knows the extent to which they can rely on the information provided.
Information provided by a work package manager should be gathered with that from other work packages and collated at project level by the project manager. The same need for collation exists through the project delivery hierarchy to programme, portfolio and up to organisational level. It is therefore necessary to understand not only the issues facing those providing the information needed for effective control, but also the needs of those, at a higher level, who require the information.
Particular reports might have to be provided, for example, for government major projects and grants reporting This can be less frequent, for example quarterly or annually, but needs to be carefully managed to ensure that reporting meets data requirements and, where relevant, is appropriate for release into the public domain.
Government and Departmental Major Projects Portfolio and reporting
It is a requirement of the Government Functional Standard for Project Delivery that programmes and projects in the Government or Departmental Major Projects Portfolios to report annually, with quarterly updates in a format defined by the National Infrastructure and Service Transformation Authority and in accordance with the government’s transparency policy. See How to publish central government transparency data for more information.
Having understood who needs a report and why, a reporting framework should be defined which can provide the information recipients need, when they need it. This can be through active reporting or on-demand reporting or a mix of both (see 18.5 on who reports to whom).
The reporting framework should define who reviews and approves a report:
Having a report reviewed by multiple parties should be avoided if possible as this adds delays. It is better to coach people to provide information that is usable and foster trust among the team. It should be noted, though, that some reports require a fuller review, for example where important or sensitive decisions depend on the information, or where it is to be published.
A report should be timely, factual and realistic, highlighting where the work is heading and confirming progress to date. The content of each report can change through the life cycle as the needs and focus of the work change. In every instance, recipients should consider why they need the information, and the reporting manager or author should consider why they are providing it.
Each report should state the period or date the information relates to and the date on which the report was produced, or if drawn on-demand, the date it was created with date stamps for the constituent data. The form of a report should be appropriate and proportionate to the work being reported on and the roles being reported to.
The rules for triggering exception reports should be defined, based on margins (tolerances) applied to the particular constraint being reported on. An exception report should contain a statement of the actual or forecast exception, a description of the planned recovery action and an estimate of the threat to the work plan in terms of benefits, schedule, cost and risk.
Reporting for a programme, project, phase or work package should be tailored to the level of the report. Data should normally cover the current month, current financial year and life of the work. A typical programme or project level report should cover at least the following.
The purpose of the report and what is asked of the recipients. This includes whether the report is for information only, or whether any decisions, direction, advice or support are needed (see 18.6. on how to report on the work).
An assessment as to whether the agreed scope and objectives are still achievable, as defined in the plan, and the current confidence in delivery, usually known as the delivery confidence assessment (DCA).
An assessment of progress to date and the estimated completion date against the schedule. This should be consistent with the progress of deliverables and is typically shown in graphical form. Any forecast start or finish dates that are later than the planned should be shown separately, as slippage may affect the completion date (see 17.6.1.6 on choosing methods to assess and analyse the status of the work).
An assessment of spend to date and forecast costs against the plan for the month, year and life of the work. These should be shown by category of expenditure and should identify any cash releasing benefit impacting on the financial baseline where relevant (see 29.6.3.7 on reporting on financial status).
An assessment of resources in place against the plan. This should identify internal and external resources by category, and any current or forecast vacancies (see 28.6.1.4 on ensuring accurate resource monitoring).
An overview of current risks and issues. This should include any changes in the status of identified threats together with any newly identified threats, opportunities or issues. An overall risk rating and exposure, in monetary or schedule terms, might also be provided (see 20.6.3.7 on monitoring and reporting risks and 21.6.3.7 on monitoring and reporting issues).
A summary of significant change requests and their current status, showing how far each has progressed through the change control cycle (see 22.6.3 for key activities in controlling change)
Where relevant, an assessment of the quality of outputs or outcomes in delivery or delivered. This might include testing data, user feedback or other measures of quality agreed for the solution, and should identify any concerns and action needed to address them (see 30.6 on how to manage quality).
An assessment of benefits forecast and delivered to date against the plan. These should be shown by the relevant category of benefit; cash-releasing benefits can be included (see costs above) but care should be taken to highlight where these are also included as cash costs in financial reporting, to avoid double-counting (see 19.6.2.1 on understanding the objectives and desired outcomes).
Reports for portfolios can be similar but are more likely to reflect the sponsoring organisation’s reporting on their business plan and to include information on:
The choice of frequency for a formal reporting cycle is often tied to the control cycle (see Chapter 17), but it does not have to be. For example, a report from one level of the project delivery hierarchy to another could be monthly, but the manager could hold weekly control meetings with the team. The frequency can be different for every component in the project delivery hierarchy. The faster moving or riskier the work, the higher the frequency of reporting. At a limit, if information on work is captured as it happens and available ‘live’, such as in finance systems, the requisite information (or part of it) can be drawn on as and when needed. It can also be continuously analysed using automated routines, such as in some software testing approaches. Greater use of reliable artificial intelligence applications is likely to prompt faster, real time reporting on a continuous basis with exceptions being flagged where relevant.
Consistency of layout and terminology helps make reports easily and quickly understood. Most project management software includes reporting formats that can be tailored. Using the same base template across an organisation helps both authors and recipients use reports effectively. Otherwise, the common choice is to use office tools to create the reports and base each report type on a reusable template.
Information for lateral and downward reporting can be similar but often needs to be specifically targeted. For example, a project manager might share their report to the senior responsible owner with their work package managers and include a commentary covering the points they see as important to the team members. Aim to reduce the number of reports that need to be drafted or generated whist still fulfilling the needs to the recipients.
For on-demand reporting, the reporting systems needs to be designed so that it is easy for users to access the information they need to create their own reports, for example by being able to:
Advances in artificial intelligence can mean that information can be accessed from the designated information repositories using natural questions, and this is likely to support wider use of on demand reporting in future.
The activities for reporting are summarised in Figure 18.5 and are iterative, with similar activities repeated through the project delivery hierarchy.
The governance and management framework should define what reports are needed and at what frequency to meet the needs of the recipients, contractual obligations (if any) and the level of information necessary to control the work at each level in the project delivery hierarchy. This forms part of the overall governance and management framework for the work (see Chapter 4: Governance and management). The important aspects of this activity are discussed in more detail in 18.6.2 on preparing for reporting. The framework should be maintained to address relevant feedback from its use.
The reporting approach and methods should be planned and documented early in the life cycle of the work. Reporting needs should be defined, including but not limited to the content, author, recipients, frequency, confidentiality and format of each report needed.
Those accountable at each level in the project delivery hierarchy should ensure they are receiving the information they need, either as reports or by drawing it from the data repositories. They should focus on confirming that appropriate and reliable information is being passed from one level to another, particularly ensuring the information is consistent and usable. An important aspect of oversight is to watch for trends, which should have been highlighted as part of controlling the work (see Chapter 17: Controlling) and which indicate the objectives are likely to be met or that action needs to be taken to ensure they are met.
Reporting should be monitored and adjusted to maintain alignment with the needs and requirements of the recipients of the reports as well as the prevailing risk. When a report is no longer relevant or does not meet the needs of the recipient, action should be taken to see the report is no longer sent or that the recipients’ new needs are met.
The information needed for a report should be collated by the report author and validated, bearing in mind that some information is necessarily uncertain. and should be noted as such. Strictly, validating the information is part of ‘controlling’ the work so if, as Is often the case, the same person is drafting the report and controlling the work, this would be done as a matter of course. However, with large, dispersed teams, multiple layers of reporting can mean that vital information is distorted or lost. In such cases, it is important to shorten reporting chains where possible and also to use informal channels to test and provide context for formal reporting (see 17.6.1.7 on verifying the information). Aspects relevant to the report’s recipients should be noted, and variances and problems understood.
The report author should draft the report, in the prescribed format, drawing on the collated and validated information. The report should make clear what is fact, what is opinion, what is uncertain and include requests and recommendations where relevant. Care should be taken to ensure that the content reflects the security levels of those handling or receiving the report and that the report is labelled accordingly.
If not approving the report themselves, the report author should ensure those who need to review the report do so in a timely manner ready for it to be approved.
Reports should be issued to recipients in a timely manner in accordance with the defined governance and management framework. Where relevant, the distribution of reports should comply with any confidentiality or security requirements. Reports should be stored in the assigned repository in accordance with the organisation’s data retention policy.
Once the reporting framework is no longer needed it should be closed. For a programme, project or work package, this is when the work has been completed. For a portfolio, this is unlikely until the portfolio ceases to serve its purpose. The stopping of individual reports can be progressive throughout a programme or project as and when each is no longer needed by the recipients.
Page permissions updated for public launch.
First published for closed beta consultation.