Project Progress Reporting

This post is about how to create good project progress reports.
Progress reporting is a very important activity in project management. Project planning is generally recognised as the main management activity (and it is supported by most project management tools), but an effective tracking of the project progress plays also a key role, as well as the communication to the client and other stakeholders.

In my experience, many problems affecting projects are related to a lack of visibility on the real status of the work, and to a bad communication of that status to the clients. The creation of good progress reports periodically can significantly improve those areas, because it helps to understand the status of the project, and it provides effective communication with project stakeholders, to evaluate the progress and issues, and take decisions according to it.


In addition, the progress report is a good opportunity to formalise certain agreements, or raise issues, to make sure that all stakeholders are aware of them. Another benefit of progress reporting is to keep track of the way projects were executed, to learn from it for future projects within the organisation (in many cases, a final report is also created to document lessons learnt and relevant experiences obtained from the project).
The rest of the post will try to provide ideas about how to create good progress reports, and what information to include.

We can consider that a project is the set of activities required to accomplish a given objective (building a product, providing a service, etc...) within an agreed schedule, and using the resources allocated to it (people, material, costs, etc). The project report should therefore give the information about the status, progress, and forecast of all those aspects.
An important point is that the report has to be adapted to the intended reader (include the information relevant for the reader) and the type of project (whether it is fixed price, hourly cosultancy, etc). For example:

• A report to the client is normally more concerned about the technical status, and the compliance with the schedule and costs.
• An internal report to bosses should focus on the planning aspects, and the way the internal resources are used (to make sure it is executed within budget).

I am going to propose some generic contents of a project progress report, although it has to be clear that the different sections may apply or not depending on the type of project and the intended reader. Another important source of information are project management standards or quality assurance procedures applicable, because they usually provide templates and guidelines for the contents of the reports.
My proposed project progress report template is as follows:

1. Report information: Clarify the project, date, reporting period (start-end), author, scope, project phase, etc.
2. Summary of achievements, forecasts, and issues. It is a sort of executive summary, so someone can get a quick idea of the project status (e.g. a high manager who will not read the rest of the document):
• Highlight the main achievements of the period (e.g. activities completed, items produced, milestones achieved, deliveries, etc). This is the part in which you pass the message that many things are being done. In addition, reflect key agreements or changes, so they get formally accepted.
• Forecasts: Give the idea of what is next in the project, and what should be done in the next period.
• Problems found: Identify the main problems affecting the project (e.g. something expected did not happen, something failed, team members left, etc). If there is a problem, it is normally better to address it and discuss solutions, because it is a way get both parties involved in the issue, and it avoids bad surprises later.
3. Actions: Track of actions reaised on meetings, person assigned, status, when they are expected to be completed, results or agreements. It is normally in the form of a table.
4. Work progress: Report on the status of the work, at the required level of detail, with estimation of remaining work and expected completion time, for example:
• Progress of the different work packages
• List of activities done, and planned, estimating their completion time, and person responsible
5. Plan: Review and update the project plan, considering:
• Milestones: Achieved and planned, highlighting any change to be agreed.
• Deliverables to the client: Keep track of what has been delivered and what is pending.
• Deliverables from the client: Keep track of what has been received and what is pending (this is important because a delay here may cause a delay in the project, out control of the supplier).
• Meetings: Review and update the meeting plan. It is important to respect a meeting plan, to make sure that the communication with the client is good.
6. Resources: Inform of the different resources allocated to the project, such as the project team and their responsibilities. Changes in the team are reflected in this area.It is important that projects have different phases, and it is necessary to adapt the team to each phase.
7. Risks: Maintain a risk registry, where the potential problems which could affect the project are identified, categorised, and tracked. Client and supplier have to be aware of risks, and take measures to avoid they happen, or mitigate their impact. Once a risk cannot happen, or it actually becomes a fact, it is removed from the registry. A risk matrix can help to understand how dangerous they are.
8. Budget and costs: Keep up to date the budget, and provide information on how it is being spent (for example, in case it is related to hours spent in the project). Changes in the budget (e.g. when adding new budget) are reflected here. It is also useful to give information on invoices submitted and payments received or pending.

Depending on the type of project, the technical status will be reflected in different ways (not only activities or tasks), and there may be additional contents to include. For example, if project is for provision of a service, it will be necessary to report on the compliance to the SLA, in other projects it will be important to provide configuration control reports, or software metrics, etc. So, additional sections should be added depending on the project characteristics.

As general ideas, it is suggested to keep the report clear and concise. An agile approach can also be applied to reporting. It is not necessary to spend a lot of time writing the report, but to include realistic key information to understand the status. The key point is to update the report to represent the reality, asking internally as necessary to make sure that the status reflected in the report is according to the real progress.

In my opinion, a very effective way of reporting is by providing metrics (with charts, colours, and tables), because they help to discover information, and they also transmit it to the reader very effectively. In next posts, I will address the different sections of the report, and propose metrics, graphs, and different ways to track the information and extract the conclusions.

At Wipbi, we believe that progress reporting can bring a lot of benefits, and our platform intends to provide an efficient way to generate and access to the progress information. The tool represents a standard reporting framework, which will guide the project managers to create their reports easily, and help to make the process more efficient. In addition, it provides the way to share the information with the client, and improve the level of collaboration.