2.4 Project status reports
Project status reports are regular and formal. You will need to decide how often they are necessary – depending on the size and nature of the project, it might be weekly, monthly or quarterly. In some situations reports might need to be hourly, if a problem is causing serious concern and has the potential to delay progress seriously. Daily reports might be necessary if there are implications for arranging work for the following day.
The degree of risk involved, and the time it would take to recover from failure to complete important milestones, are guides for deciding the frequency of reporting. Other considerations might include how quickly the project could get out of control, and the time it would take to implement contingency plans. The project sponsor may have a preference about the frequency of reports and review meetings.
To prepare the report, you will need to have information from the members of the project team on:
completion of delegated tasks;
completion of key stages;
any work that is behind schedule (and why);
any issues that need to be resolved (as soon as they arise);
any difficulties anticipated in the near future.
Some project managers find a standard reporting template useful, so that team members can see at a glance what you need to know and just fill in the gaps. A standard report might include:
the project title;
a brief description of the key stage covered by the report;
the name of the person responsible for this key stage;
the date of the report;
actual progress tracked against planned progress towards project ‘milestones’;
a summary of progress on this key stage, including explanation of any slippage and remedial action taken;
any issues awaiting resolution;
the milestones due in the next reporting period and the date of the next report.
Once you have set up a system for regular reporting you will probably have to make sure that it happens, at least in the early stages. Be prepared to chase up reports and to insist that they are necessary and must be presented on time.
Read the following and then answer the question below.
Risk and contingency planning
Risk is the chance of something occurring that has an adverse effect on the project. Many risks can be foreseen and identified. For example, if the project involves development of computer-based systems, time needs to be allowed for ‘de-bugging’ once the systems are installed.
The main categories of risk can be summarised as:
physical loss of or damage to information, equipment or buildings as a result of an accident, fire or natural disasters;
technical systems that do not work or do not work well enough to deliver the anticipated benefits;
labour key people unable to contribute to the project because of, for example, illness, career change or industrial action;
political/social for example withdrawal of support for the project as a result of change of government, a policy change by senior management, or protests from the community, the media, patients, service users or staff;
liability legal action or the threat of it because some aspect of the project is considered to be illegal or because there may be compensation claims if something goes wrong.
In view of all these possibilities, the careful examination of the question below, early on in the project, can save a lot of (though not all!) problems later:
‘What could go wrong in this project?’
Having identified potential areas of difficulty you can then examine these by asking, in respect of each one:
How likely is this to happen?
How serious would it be if it did?
Having raised these questions, you can then consider what you might do either on your own or with a team. Some of the less likely possibilities and those that would really just be minor irritants may not need a lot of attention. Others could be seen as quite critical to the success of the project and you can, at an early stage, plan what to do if the worst happens.
What key questions do you think stakeholders would want you to answer when you prepare a report about the progress of the project?
We think that the central questions are:
Is the project on schedule?
Is it within the allocated budget?
Have the milestones been achieved?
If not, what action has been taken to correct the situation?
Other questions may be appropriate, including whether problems have been identified and solved, whether experience so far has any implications for future plans, whether any additional resource is required or whether there is any need for revisions to the overall plan.
The information gained from project status reports will be helpful in compiling reports to stakeholders, but different types of report may be appropriate for stakeholders with different concerns. For example, the project sponsor may be most concerned with the overall progress against goals, but stakeholders concerned with only one group of project objectives may only want information about these. There may be confidential information to be shared within a limited group of stakeholders. Some stakeholders will only have an interest in the overview and the implications for the organisation.
Example 4: Overview and detail
A junior estate manager who worked for a conference centre reported a personal experience of reporting at a different level. He said, ‘I was asked to make a presentation to the Chief Executive about the re-location of our residential accommodation and I was very worried that he would ask me to explain why we were so far behind schedule. We had found asbestos in one of the ceilings and had immediately stopped work and called in specialists which had, of course delayed everything. In fact, all that the CE wanted to know was whether we were going to keep to the revised schedule now. He was very pleased to hear that we had asked the specialists to check all of the other rooms that would be part of this move so that there would be no more nasty surprises. It made me realise that in reporting at that level I had to give an overview and show that we could stand back from problems and look ahead to make sure that we achieved the main outcomes as well as possible.’
Reporting often raises issues for those who receive the reports. You may want to consider that people often react with questions at the level of detail that you have offered. If you limit what you offer to target the key concerns from each perspective you are likely to reduce the extent to which you have to smooth anxiety or deal with misunderstandings!