How many times do you enter the same project information each month?
You update the forecast, copy the costs into a spreadsheet, prepare a report for your manager, and then put much of the same information into the client’s template. A few days later, someone asks for a different breakdown.
The information probably exists somewhere. Finding it, checking it and putting it into another format takes most of the time.
This describes the biggest frustration I had in nearly every company I worked for. The project reporting system was a mess or didn’t even exist.
Meanwhile, there is a project to manage.
Problem: Project reporting creates too much extra work
Information is spread across separate systems
A project can have an accounting system for actual costs, a timesheet system for labour, a schedule for progress, and separate spreadsheets for forecasts, changes and invoices.
Each may work reasonably well by itself. The difficulty comes when they do not share information.
The project manager becomes the connection between them. Every reporting period, someone downloads the data, checks the codes, copies the figures, and tries to explain why the totals do not agree.
Perhaps the accounting report includes invoices processed yesterday, while the forecast uses last week’s costs. Perhaps someone has updated the labour spreadsheet but not the monthly report. You can waste hours investigating a difference that is simply caused by the reports using different dates.
Reporting becomes a separate job from managing the project
Some organisations have one system for doing the work and another for telling senior management about it. Project managers then have to manually recreate information they have already recorded.
At program level, this becomes even more wasteful. Each project manager prepares a different report, and someone else combines them into a program summary. They spend time adjusting headings, graphs and tables before they can even compare the projects.
If five project managers each spend four hours preparing reports every month, that is twenty hours of work before the program manager starts combining them. That is a simple illustration, but it is worth doing the calculation for your own team. You might be surprised if you delve into it, you could find far more time than that is wasted each month.
The reports can still give a misleading picture
A report may show that spending is below budget while overlooking work that has been completed but not yet invoiced. It may show the original completion date even though the current schedule forecasts a delay.
More reports will not fix missing or outdated information.
Managers need to know what is happening, what is likely to happen next, and where they need to act. If the reporting system cannot provide that reliably, the project team is doing a lot of work for limited benefit.
In one role I had, I calculated that it took me eight hours each month to bring together all the relevant information for the required senior management report on my teams program of projects. But I still had to make different format versions for other departments, plus many ad-hoc requests for information about specific projects or parts of projects. Then I had to answer constant questions to clarify the differences in information they received from other sources. In the end I probably spent about 40 hours per month on this type of reporting, knowing that with an efficient system I could have done the same work in about an hour.
Solution: Link project records to the reports people need
Agree on the reporting requirements at the start
Before choosing software or developing templates, work out who needs the information and how they will use it.
The project manager needs enough detail to manage individual work packages. A project director may need a short summary of costs, completion dates and decisions required. The client may need information in a particular format for their own reporting system.
Ask about the reporting period, issue date, recipients, required information and file format. Find out whether they need to read the report or also import and analyse its data.
A PDF may suit an approved monthly record, but it can create unnecessary work if the recipient needs to sort the underlying figures. I cover this further in How to Ensure Your Client Gets the Project Status Reports They Want, which applies to how you deliver reports to internal stakeholders as well.
Record the agreed arrangements in your Project Management Plan. This gives the team a clear reference when someone asks for an additional report later.
Use one connected set of project information
A good project reporting system should bring together the information needed to manage the project, including:
- Approved budgets and changes to those budgets.
- Actual costs, labour hours and expenses.
- Outstanding purchase orders and other commitments.
- Forecast costs and expected completion dates.
- Progress, milestones, risks and issues.
- Changes and variations.
- Billing information and invoice status, where relevant.
This could be one package or several modules that exchange information automatically. The important requirement is that people do not have to keep entering the same information multiple times into unrelated records.
Finance can remain responsible for the accounting records, and the scheduling team can maintain the schedule. Their information should feed the reports through agreed connections, using matching project and work package codes.
For a small project, a controlled spreadsheet may be adequate. As the number of projects, contributors and reporting requirements increases, a connected database system becomes much more useful. See Why Good Project Management Software Is a Better Project Forecasting Tool Than a Spreadsheet.
Set up consistent project and cost codes
Connections between systems need consistent identifiers. If the same work package has different codes in the budget, timesheets and purchasing records, someone has to maintain and check the mapping.
Agree on the project number, work breakdown structure and cost codes early. Use enough detail to manage the work without making every timesheet entry unnecessarily complicated.
Tell team members which codes to use and where to find them. Explain how to record rework, approved changes and other costs that need separate tracking.
My post on Timesheet Cost Codes explains why making this information easy to find matters. Automating the transfer of time records will not help if people book their time to the wrong work package.
Connect labour records to forecasts and costs
Individual hours should flow from approved timesheets into the project’s labour information. Site managers and design managers should be able to check the hours and progress for their areas without maintaining another independent record.
The system should let you compare budgeted hours, hours used, and the hours still expected to complete the work. This makes it easier to identify a task that is using its allocation faster than expected.
Be clear about when timesheets are approved and when the associated costs become available. If costs arrive later than hours, show that limitation rather than presenting incomplete labour costs as final.
Team members should also have a simple way to advise that they need more time. My Time Forecasting System post develops this idea further.
Show the expected final cost as well as spending to date
Costs to date tell you what has already happened. You also need a realistic estimate of the remaining work.
The report should distinguish the approved budget, actual costs, commitments, remaining forecast and expected total cost at completion. Define the variance calculation so readers understand whether a positive figure means an overrun or a saving.
For example, suppose a project has a $500,000 approved budget, $200,000 in actual costs and $330,000 of remaining forecast costs. Its expected total cost is $530,000, giving a forecast overrun of $30,000.
If $150,000 of that remaining forecast is already covered by outstanding purchase orders, do not add those orders again. They are already included in the $330,000.
Also identify completed work awaiting invoices and agree with finance how it is recognised. Clear definitions prevent a connected system from producing a very quick, very misleading total.
Make routine outputs easy to produce
Once the information is recorded properly, you should be able to produce the common reports without rebuilding them each time. These may include:
- Weekly progress reports and monthly project summaries.
- Monthly cost summaries and expenditure by work package.
- Labour hours and labour costs for a selected period.
- Expense breakdowns and costs to date.
- Budget variances and forecasts at completion.
- Billing schedules and invoices, where the approved workflow allows.
Users should be able to select a project, period or work package and get the relevant output. They should also be able to trace a summary figure back to the supporting records.
Keep billing separate from cost reporting where necessary. The amount spent on a project is not automatically the amount you are entitled to invoice. Billing still needs the required approvals and supporting evidence.
Keep the management summary brief and useful
Start a status report with the basics. Include the project name and number, project manager, reporting date, approved budget, expected final cost and key completion dates.
Then explain the significant changes since the previous report, current problems, major risks and decisions required. Put detailed breakdowns behind that summary so readers can investigate them when needed.
For example, “Commissioning is forecast two weeks late because the control panel delivery has moved. Approval of the alternative supplier is required by Friday June 15th” gives a manager something useful to act on.
Asana’s guide to project status reports provides further examples of report structure. Whatever template you use, it must leave room for the project manager to explain the figures and recommend action.
Roll project information into program reporting
If you manage a program or portfolio, establish common definitions and report fields across the projects. Every project should use the same meaning for approved budget, forecast completion and reporting period.
The program report should draw from the project records. Each project manager should update the forecast, risks and commentary in the normal system, with those updates feeding the program summary.
You should not need every project manager to spend hours formatting their own tables and graphs for someone else to rearrange.
This also supports Regular Projects Review Meetings. The information is available before the meeting, allowing discussion of resource conflicts, emerging problems and decisions that affect other projects.
Give people the access needed for their responsibilities
Set permissions according to each person’s role. The accountant may control accounting entries, authorised staff may manage billing, and discipline managers may update forecasts for their work.
Individual team members should enter their own hours through the timesheet process. Changes to approved budgets should follow the organisation’s approval requirements and retain a record of who changed them and why.
However, do not make access so restrictive that people cannot do their jobs. A person responsible for cost forecasting needs timely access to the relevant cost information. Requiring them to request a fresh export from someone else every time defeats much of the purpose of the system.
Train the team and check the information
Training should cover the actual tasks people need to perform. Show them how to enter hours, update a forecast, correct a mistake and find the information relevant to their role.
Make the instructions easy to find. Include the reporting process when new team members join, and explain which old spreadsheets or reports the new process replaces.
Set clear deadlines for inputs and checks. Show the reporting cut-off date and when information was last refreshed. If a connection fails or an input is missing, the report should make that visible.
Before issuing a report, check important totals against their source records, review unusual movements, and confirm that the commentary matches the figures. Keep an approved snapshot of formal reports so you can establish what was issued at the time.
Test the complete process before relying on it
A software demonstration can make reporting look easy. Ask the supplier or your internal systems team to demonstrate your own reporting requirements with representative project data.
Follow a timesheet entry, purchase order, supplier invoice and approved budget change through to the reports. Check that they reach the right project, are counted once, and appear in the appropriate period.
Test the client’s required output and the program summary as well. Confirm who will maintain the connections and resolve failed transfers.
You may not have authority to replace the company’s systems. In that case, identify the repeated manual steps and work with finance, IT and the project office to improve the existing process. A reliable connection between two established systems may solve a large part of the problem.
Measure whether reporting is becoming easier
Record how much time the team spends preparing, checking and reformatting reports. Include the effort of project managers, discipline leads and people combining the results.
An agreed reporting cost code can help make this effort visible. Use the evidence to assess whether an improvement is worth funding, and compare the effort again after implementation. The cost savings in a large company could be substantial, but a small 5 person company could probably make use of a standard cloud based project and program management system and its default templates just fine.
Also review the reports themselves. Ask recipients which information they use and what decisions it supports. Remove duplicated reports where approval and governance requirements allow.
The expected result is less paperwork and more reliable information. If a new dashboard simply creates another monthly form for every project manager to complete, you should probably revisit the process.
Lesson: Make project reporting part of managing the project
Set up your project reporting system early. It should connect the records people use every day to the information needed by the project manager, client and senior management.
Use consistent codes, clear responsibilities and properly linked systems. Train the team, check the data, and make routine reports easy to produce.
The project manager should spend most of the reporting effort explaining what the information means and what action is needed. Repeatedly copying costs, hours and forecasts between separate files should take as little time as possible, and really should not be needed at all.
You need to replace the significant waste of multiple systems creating multiple reporting requirements. A good project reporting system should give you more time to manage your project or program, and perhaps even make your job enjoyable again.
To start with, I recommend looking at the list of project management software at Wikipedia, but also do a good internet search, as a lot of newer software options are missing from the Wikipedia page.
