• header 3

Value added project reporting

Reporting is a central part of project delivery. There is a variety of reports to produce: status reports, budget updates, steering committee packs and so on. Reporting can take up a significant proportion of project resources, and is often a point of dissatisfaction for project managers, project sponsors and other stakeholders.

Project reporting causes project sponsors’ and project managers’ eyes to roll – for different reasons. Sponsors are often unhappy with the reports they get. Project managers are often unhappy about the effort expended in reporting. Sponsors claim they cannot understand what is going on. Project managers complain about drowning in documents and PowerPoint presentations, and being unable to do “any real work”.

This sections looks at a sensible approach to project reporting. An approach that meets the needs of different stakeholders, and adds value without being an excessive overhead.

Reporting goals

Badly managed reporting wastes time, but project reports have productive uses. They keep those external to the project informed about the project and able to take whatever decisions and actions they need as a result of the project.  Secondly, project teams can use reports to drive the things they need from these external groups, whether that is decisions making, resource allocation, or any other activities undertaken. Hence we can derive two basic goals in project reporting:

  • Meeting the needs of both project stakeholders and the project itself 
  • Achieving this efficiently and effectively by maximising value from and minimising overhead of reporting

By holding these goals in mind we can develop the most value added reports.

Putting yourself in someone else’s shoes

The starting point for value added reporting is to ask the questions: who is the report for, and what do they need from the report? A report is not meant just to reflect what the report writer has to say, but is a tool to help the reader make judgements and decisions and take the right actions. 

When thinking about project reports, try to put yourself in the shoes of the person reading it and understand what they want. On top of this, a report is also a tool for the writer to get the things done he or she wants done. 

There is potentially a large range of different audiences for project reports, but we can simplify them into two: interested external parties in a project, known as stakeholders, and the project and project team itself. Their needs are conceptually simple.

  • Stakeholder needs are:
    • To understand progress towards achieving goals 
    • To ensure their needs are being met by the project
    • To prepare for any decisions or actions they need to take as a result of the project
  • Project team needs are:
    • To manage stakeholder expectations, maintain their awareness of project team performance, and develop their confidence in the project
    • To highlight risks and issues stakeholders should be aware of, or need to take action over
    • To facilitate decision making and approvals by sponsors and stakeholders
    • To gain and maintain access to resources and prioritisation

Test every report you write: is it giving stakeholders what they need, is it helping you to achieve your goals? Or put more simply: are you informing appropriately and making the right requests? Only when you answer yes to both parts of this question is it a good report.

Reporting principles

Project management is not reporting, but an element of reporting is essential to all projects. This must either be done by the project manager or delegated to another party, such as the PMO. 

The style and volume of reporting required should vary depending on the needs and context of the project. For example reports may have to scale up or down to account for the size, complexity, risk, value and visibility of the project. 

Projects managers should aim to be able to produce reports quickly and simply. If the project manager cannot quickly report status, the likelihood is that she or he is not on top of the project. 

Ideally, reporting should be a natural outcome of the project work being done. For this to happen project work products and artefacts need to be designed such that they are presentable to wider audiences. In reality, there is usually some need to tailor for specific audiences, but this should be minimised.

Project managers should seek to minimise reporting overhead. But they must also recognise that it is an important task that adds value. They should recognise that different audiences require different types of information, which may require different reports. The project manager should seek to balance the gains from producing a variety of reports, with the efficiencies from producing as few as possible. A good attitude is to think of developing as many as necessary and as few as possible.

Try to cut out anything that is not adding value, and stop reports that stakeholders have ceased reading. Politics and culture have an impact on this, and it would be naive to think that every project can just ignore the things it does not want to do or does not think adds value. 

Designing reports

The appropriate level of reporting is context sensitive. Examples of the factors you need to consider are:

  • Whether the project is politically contentious or not: contentious projects usually have to do more stakeholder management and associated reporting.
  • Whether the project operates in a situation with generous or constrained resourcing: when resources are constrained, reporting needs tend to increase to maintain access to resources and appropriate prioritisation.
  • Whether the project needs regular support from senior managers (e.g. to take actions, make decisions, or give approvals), or is it largely self contained: the more active sponsors and stakeholders need to be, the greater the reporting overhead to steer this activity.
  • Whether the culture of the organisation formal or informal: this is less about the reporting needs and more the frequency and style of reports. Less formal organisations tend to have regular updates in the form of conversations. More formal organisations tend to insist on formalised periodic reports.
  • How homogeneous the stakeholders are: when stakeholders have similar needs, levels of understanding and attitudes, one report may satisfy all. If the stakeholder community is varied, the number and range of reports tends to increase.

Finding the balance

Optimising the reports you produce is about balancing a variety of needs and contending pressures. Reports need to be designed for your specific context and requirements. What are the needs of your project, given the environment and context it operates in? This should be taken account of in project planning and resourcing. 

When a project is started, the reporting processes, report formats and responsibilities should be defined to meet the needs of the project and its stakeholders. As the project progresses, periodically review the reports - making sure the reports are reaching the right audiences and enabling them to make the right decisions, whilst never being afraid to stop reports that have ceased to add value.

This can be challenging when organisations insist on standard templates. But do not reject standard templates out of hand. Firstly, you may have no choice but to use them. Secondly, the reality is that many projects in one organisation face similar pressures, and have to report for similar needs. Standard templates can work, as long as they are well designed for the organisation, and there is flexibility in the level and detail of content input. 

Additionally, standard templates may be well received by sponsors as they are familiar with them and know how to get the right information from them. However, when you have the situation that a template has to be immensely complex to suit different stakeholder needs, or does not provide the right information for stakeholders – then it is time to redesign them.

Read 34873 times

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

Choose an article