OK, it is your first week as manager, and you have requested and received a pile of progress reports on each of your major projects. The reports are written by a variety of people – some employees, some technical staff, and some contractors. You want to understand how each project is progressing.
What are your risks?
Which projects are over budget, in danger of failing, or have unresolved issues?
Where do you need to focus your efforts?
These progress reports can be a goldmine of information if you know what to look for.
First, let’s talk about the objective of a progress report. The goal of progress reporting is not to create a lot of paperwork. It is not to memorialize every twitch made by each developer. It is to supply management teams with information required for good decision making.
Progress reporting formats vary. Ideally, there is a common format within an organization for ease of review, but the format is not really important. Some formats are pretty, use big, confusing words, and have pages and pages of information. Don’t be distracted by charts, colorful formats, or irrelevant information. It is the content that matters, and certain content should be contained in every project report.
Let me say it again: every report, without exception, should contain this content. You will need it to evaluate progress and spot emerging problems and issues, so you can intervene before they become major issues. If you get a progress report without this information (and you will), go back to the team and ask for it. You may get some resistance (“we don’t capture this information” or “we’re too busy to do this” or “our contract does not require us to provide this”). The excuses may actually be true, but they are irrelevant. Without progress report data, you lack essential information to make good decisions.
Here is the essential content of a progress report:
Project Summary – Two or three sentences that describe where in the lifecycle the project is. Upcoming project or contractual deadlines or milestones are listed.
Author – The name of the team member who wrote the report. This should be the project manager. If it is not, be skeptical about the accuracy of the information.
Period of Performance – The period of time that the report covers. Weekly reports are best.
Report Number – The sequence of reports allows you to go back and compare information against previous reports to check for consistency.
Issues – A really important section. Issues are items that have the potential to adversely affect the project’s planned outcomes. Each issue should have an ID, opening date, description, and a named person (not a department, team, or any other organization) who is responsible to resolve it. Each issue has a planned response that describes what needs to happen to close the issue and move forward.
Are there lots of risks and or issues? If so, the project is probably having problems that require your attention.
Are the issues old? Then the completion schedule is likely being compromised. There may be role and accountability problems.
Are there no listed issues? If so, the team is either not doing sufficient risk management or is not being candid.
Table of Deliverables and/or Key Milestones – A table of all project deliverables, planned due dates, and current status. Overdue deliverables should be highlighted with explanations of what caused the delay, what is being done to complete it, and when. Tabular formats are preferable to prose – the data is concise and easier to read. Planned, Actual, and Remaining Costs – Costs are best analyzed within milestones. How much money have we budgeted? How much have we spent, how much is left, and is what we have left enough to finish the project as scoped? This section should tell you if you have a looming budget overage that you will need to prepare for or head off.
Planned and Actual Tasks/Accomplished – A listing of any tasks for the period that are 100% complete. Beware of status reports that tell you what work a team did (“we worked on the interface development”) rather than what they accomplished (“we completed the interface development between the RCSW and CBR systems and have run preliminary string tests”).
Late Tasks – A list of tasks that are planned to be complete but are not, including the number of days the tasks are late and why. A task that was supposed to be complete but is only 50% complete is still late. The number and severity of late tasks is a good indicator of schedule performance without a detailed review of the project schedule. Cross check this information against the schedule; they should match.
Next Scheduled Milestone – The next scheduled significant event and what needs to happen to accomplish it.
Planned Tasks for the Next Period – A list of tasks planned to be accomplished next.
Summary of Change Management – An abbreviated list of any changes in scope, schedule, or cost that have altered the baseline.
Updated Project Schedule – Usually expressed in a Gantt chart using project management scheduling software. Determine if the schedule details are consistent with the progress reporting details. (Often they are not).
Notes – Free form section for the PM to report any additional relevant information.
That’s it! Progress reports are intended to be useful tools to increase productivity and minimize risk and budget overruns in part by providing YOU with accurate, timely, and actionable information. Establish the process and infrastructure for high quality progress reports with the guidelines above to support you and your projects.
In Part II – Gaining Insight, we’ll give you more tips to read between the lines of a progress report to quickly improve your understanding and insight.