Close Search (X)

Project Reporting – Adding Value rather than Ticking Boxes

I want to describe a scenario. It’s one we are all familiar with: it’s month end and status reports are due. Let me describe a bad case of this scenario, (a situation that each of us has probably seen time and again). There is a standard template that has to be completed. We look at last month’s report, and shift the things we said we would do to the activities completed section. Then we edit them when we realise we have not actually done all the things we said we would do. We think about the plan a bit and decide what we will commit to doing in the next month that won’t cause us too much pain in a month’s time. Next we ponder whether to update the major risks list and how to write a management summary in 2 sentences. Finally, there is a bit of a panic to get the financial data right. And the feeling that accompanies this: it is all a bureaucratic pain which makes no difference to the delivery of the project.  Either no one reads the report, or if they do you are asked some irrelevant questions which take time to answer but help no one. It should not be like this, and we all know it shouldn’t! Reporting is central to project delivery. There are status reports, budget updates, steering committee packs and so on. Reporting can take up significant time and effort, and is often a point of dissatisfaction for project managers, project sponsors and 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”. So, what is a sensible approach to project reporting: an approach that meets the needs of different stakeholders, and adds value without being an excessive overhead? The starting point for value added reporting: understanding the goals Bad reporting wastes time, but 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, reports can be used to drive the things project teams need from these external groups. This could be decisions make, resource allocated, or any other activities undertaken. From these thoughts 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

The frame of mind for value added reporting: putting yourself in someone else’s shoes 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, 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 value adding report. [ribbon-light]Reporting principles[/ribbon-light] Project management is not reporting, but reporting is essential to all projects. This must either be done by the project manager or delegated to another party, such as the PMO. But do not delegate it as an administrative task. If you do this you will end up with administrative reports – not ones that drive the behaviour you want. Only delegate it to someone you know understands the project and stakeholder needs well. The style and volume of reporting required should vary depending on the needs and context of the project. 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 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. It is naive to think that every project can just ignore the things it does not want to do or does not think adds value. [ribbon-light]Designing reports[/ribbon-light] The appropriate level of reporting is context sensitive. Examples of the factors you need to consider are: •    Is the project is politically contentious or not? Contentious projects usually have to do more stakeholder management and associated reporting. •    Is the project operating with generous or constrained resourcing? When resources are constrained, reporting needs tend to increase to maintain access to resources and appropriate prioritisation. In the current world, money tends to be tight and so greater focus is given to this. •    Does 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. •    Is the culture of the organisation formal or informal? 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 are the stakeholder needs? 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. [ribbon-light]Finding the balance[/ribbon-light] Optimising the reports you produce requires balancing needs and contending pressures. Reports should be designed for your specific context and requirements. What are the needs of your project, given the environment and context it operates in? This must be taken account of in project planning and resourcing. Heavy reporting overheads need matching resources. 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, 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. [ribbon-light]Author bio:[/ribbon-light]Richard Newton is an author and programme manager. His last book The Management Book is the CMI’s management book of the year 2013. He has written several books on project management. His next, The Project Management Book will be published on 24 April 2013.

Back to the top of the page Contact Us Join our Newsletter