Project Documentation | By Duncan Haughey | Read time minutes
Progress reporting is a crucial activity for managing any project. As the project manager, you issue regular reports on the progress of a project against scope, schedule, and budget. These progress reports take many forms, often sent out in emails or as PowerPoint presentations.
In recent years, I've adopted an approach I like to call live minutes for my project progress updates. What follows is a description and example of live minutes, a breakdown of everything the approach entails and actionable guidance that will empower you to deliver better project progress reports.
Live Minutes Defined
The concept of live minutes, taking meeting minutes while running the meeting, might seem akin to simultaneously patting your head and rubbing your stomach. However, after some practice, the new practice will become second nature. After a while, you'll hardly notice you're talking and typing at the same time. Like with any skill, the more you practice the live minutes approach, the easier it becomes.
Why is progress reporting with live minutes better than the traditional progress reporting?
The answer is partly in the name 'live'. It's unlikely that stakeholders or anyone on your team will say they didn't know what was happening as you share a clear weekly record with them. Writing the minutes on-screen during the meeting allows people to keep up and helps reinforce the messages, especially if English is a second language for any attendees.
Practicing the live minutes approach to truly enjoy all its benefits boils down to being prepared, knowing what to write, assigning actions, using RAG status and colour coding, and managing risks and issues.
Meeting Preparation
The first step is preparation. Good preparation contributes more than 50% to a successful progress reporting session. I prepare the day before, spending at least 30 minutes doing the following:
- Reviewing the previous week's minutes, updating them as needed.
- Thinking about what I need to communicate and what help I need from my stakeholders.
- Presenting ideas and improvements.
I usually plan to begin with the good news and follow with any issues or problem areas later. This approach helps get the meeting started on a positive note.
If you think all the above sounds like a lot of work for each project, remember that tools such as Microsoft OneNote and Evernote (my preferred tool) make it easy to duplicate your previous week's minutes. That way, you're only making the changes and updates to the prior week's notes.
If your project is running into any trouble, it's also best to show up with some solutions in hand. I tend to abide by the bring me solutions, not problems adage, starting with myself. Your solutions might not be the eventual answer, but having them at the ready helps your team view you positively as a pro-active project manager.
Knowing What to Write in Your Progress Report
What does a good project progress report contain?
I start with a title of the project name, meeting type and date – for example, Project Goya Status Update, 15/11/2021.
I follow that info with a table of the major development areas. For example, my go-to table headings/row titles titles are Go Live Date, Work Package, Scope and Status (more about statuses shortly).
Next, I detail each work package, any updates, the project milestone timeline and the project status. After covering all work packages, I move on to the application support and other items on the periphery of the project.
Then it's time for risks and issues. I present these factors in two tables (which are detailed a little later below).
I finish the report with a section titled any other business (AOB) to allow anybody attending the meeting an opportunity to discuss anything important not covered in the update. Afterwards, I list any upcoming events and record the holidays for anyone involved in the project.
Here's an example progress report layout:
- Title, meeting type and date.
- Table with sprint number, description, delivery date and overall status.
- A section for each sprint with essential discussion points, progress to date and milestone timeline.
- Update on application support and other discussion points not directly related to the sprints.
- Tables of risks and issues with the latest status for each.
- Any other business (AOB).
- Events and holidays.
Assigning Actions
As you work through your progress report, actions will inevitably arise that you'll need to assign to individuals on your team. I present actions in the following way:
Action: Update and circulate the new finance module requirements specification by Friday 19th November – Rahul
I mark the item as an action, then write a concise description of the action with a date and the named individual responsible for completing the action. It's good practice to assign one responsible person to each action. Doing so avoids any confusion over who's responsible for completing each action – in this case, my business analyst Rahul. Of course, he may choose to involve other people to help him complete his action on time.
Actions are a vital review point at each meeting, along with a RAG status.
The POST method is a simple way to give clarity at the beginning of a meeting:
| Purpose | What is the purpose of the meeting? |
| Objective | What are you trying to achieve in the meeting, and what does success look like? |
| Structure | What is the structure of the meeting? |
| Timing | How much time is allocated to the meeting? |
Using RAG Status and Colour Coding
I find it helpful to colour code my progress reports. Below is the scheme I use:
- Overall project status:
- Challenged = Red
- Delayed = Amber
- On Track = Green
- Individual sprints, tasks or actions:
- In Progress = Red, Amber or Green
- Pending = Amber
- Completed = Green
- On Hold = Purple
- Closed = Blue
Managing Risks and Issues
Managing risks and issues is an ongoing task throughout the project timeline, but in terms of keeping the team updated, I resist having separate project risk and issues sessions. Instead, I prefer to finish my status updates and team meetings by reviewing risks and issues. For this step, it's crucial for you to not only understand the difference between a risk and an issue, but also know how to manage them as part of your progress reporting.
Risk Register
A risk is a potential issue you identify that may or may not occur in the future. If you're like most project managers, you identify harmful risks that would be to the detriment of your project. However, positive risks can also impact a project, and you can take steps to make them more likely to occur. For the most part, however, you'll be identifying harmful risks in your progress report.
It's good practice to include a last reviewed date for your risk register to let everyone know the last time there was a discussion and update.
Retaining closed risks on your risk register for one week after closing them is also a good idea. Doing so allows everyone time to see that the risk has been closed.
Below is an example risk register with descriptions of each line item:
| Item | What to write |
|---|---|
| ID | Give a number to each risk for identification purposes. |
| Date Raised | Record the date you first identified and added the risk to your register. |
| Risk Description | Provide a clear, concise description of the risk identified. Ensure anyone not part of your status updates could understand the risk and its potential impact. |
| Likelihood | How likely is it that this risk will occur, classified as low (not likely), medium (quite likely) or high (very likely)? |
| Impact | If the risk is realised, how will your project be impacted? Be descriptive. |
| Severity | If the risk is realised, how much will the impact damage your project? |
| Mitigation Plan | What will you do now or very soon to prevent this risk from happening or to minimise the impact of the risk if it is realised? |
| Owner | Assign a person (ideally not the project manager) who will be responsible for monitoring this risk and creating a mitigation plan. |
| Status | State whether the risk is open or closed. When closing a risk, get consensus from your stakeholders and team before declaring it closed. |
| Date Closed | Record the date on which you close the risk. |
Issues Register
An issue is something that's already impacting your project and demands immediate attention and a swift resolution. In some cases, issues can pose a grave threat to the project, so mitigating any risks before they become issues is vital.
As with risks, it's good practice to include a last reviewed date for your issues register to let everyone know the last time there was a discussion and update.
Retain closed issues on your issues register for one week after closing them, just like with risks, allows everyone time to see that the issue has been closed.
Below is an example issues register with descriptions of each line item:
| Item | What to write |
|---|---|
| ID | Give a number to each risk for identification purposes. |
| Date Raised | Record the date you first identified and added the issue to your issues register. |
| Issue Description | Provide a detailed account of the issue, how it occurred and any relevant information. Ensure anybody not part of your project could understand the description. |
| Impact Description | Write a detailed description of how the issue affects the project. What are the likely scenarios if the issue is not mitigated? |
| Impact | Assign a rating of either high (red), medium (amber) or low (green). |
| Priority | Assign a rating of either high (red), medium (amber) or low (green). |
| Mitigation Plan | Record the mitigating actions you will take to minimise or remove the issue's impact on your project. |
| Owner | Assign a person to resolve the issue and be accountable to the project manager and other stakeholders. |
| Status | Choose from either open, on hold or closed. |
Realising the Benefits of Progress Reports Using Live Minutes
Since introducing this progress reporting approach for status updates and team meetings, I've rarely seen any deadline or commitment questioned. People complete actions in a timely fashion – no one wants to attend the next meeting knowing they haven't completed the actions for which they're responsible.
If you instead need a full meeting transcript of meeting minutes, software applications exist that can do this for you. But there's a caveat. This approach is unlikely to work if you want people to read and act on your minutes. Few people want to trawl through a full meeting transcript to find one or two relevant areas.
On some occasions, you might choose to record a meeting, with or without doing live minutes. Recording is something I reserve for requirements gathering and technical briefings. For those purposes, it's helpful to have the video to remember the exact details of the discussions, agreements and actions. Having a video also allows team members unable to attend the live call to catch up at a convenient time.
For most meetings, however, lives minutes will make your progress updates more effective.
Why are live minutes so valuable to a project manager for staying organised and keeping the stakeholders informed of progress? These are my findings:
- I stay organised and keep an essential record of the project week by week.
- I'm creating an instant and permanent record of all essential meeting points and progress on my projects. I'll never forget an important update or agreement.
- I can assign actions to individuals during the meeting, ensuring there's clear accountability. Seeing an action written down makes it more likely your team will complete those actions, especially when they know their work is due for review in a week.
- I can manage risks and issues using simple table formats. I review progress weekly and decide what level (high, medium or low) the risk or issue represents with my team and stakeholders. I assign one owner as a single point of accountability.
- I always leave space for any other business (AOB) at the end of the meeting, opening the door for discussion on any points I may have forgotten or anything other attendees feel is essential.
- I'm recording all upcoming events and holidays, ensuring I won't forget about them.
- I defiantly don't try to record what people say verbatim. I interpret and summarise.
Writing live minutes may seem daunting at first, but just like with simultaneously patting your head and rubbing your stomach, the more you do it, the better you'll get.
If you're a project manager, progress reporting is an essential skill. Using live minutes can help ensure you communicate effectively and focus on what matters most for your projects. Why not give it a try? You've got very little to lose.
Recommended read: Project Status Reports Everyone Can Understand, by Louis Marshall.