Susanne Madsen Intl. Developing Project Leaders
  • Home
  • Services
    • Workshops
    • Speaking
    • Coaching
    • Stress management
    • Master Class Series
    • Testimonials
  • Bio
  • Books
  • Blog
  • Resources
  • Videos
  • Contact
  • Library

How to write the perfect progress report – dos and don’ts

4/8/2014

3 Comments

 
If you work as a project manager, chances are that you have completed dozens of progress reports during your career – if not hundreds! But how effective have they been? Have you had a clear purpose when writing the reports, for instance by wanting your stakeholders to take certain action as a result of them? Or did you fill them in because it was one of those routine tasks that had to be done?
Picture
Image courtesy of FreeDigitalPhotos.net
You may have been very conscientious and particular when filling in your reports, but unfortunately not everyone is, and as a result the weekly status report becomes one of those artifacts that is part of the process without adding much value. 

Top mistakes
Some of the classic mistakes that project managers make is that they include too much static information and not enough about what the real project issues are. In that way the report is not a true reflection of what is really going on. If you just write about what happened during the last reporting period and what you will do during the next reporting period, without mentioning how that compares to plan and what the real risks and issues are, there is no incentive for executives to pay attention to it. In many cases the report is even attached in an email without any context or description, meaning that executives who rely on smartphones are unlikely to ever get to the information.

The perfect progress report
So, what does a perfect status report look like? Well, first and foremost it’s a simple report, preferably on one page, which adds real value by providing an overview of milestones, risks, issues and budgetary information at a minimum. Here are some guiding dos and don’ts:

  • Don’t include too much static information about the background of the project.
  • Do include the name of the sponsor and the project manager.
  • Do keep the information to one page.
  • Do include the top 5 risks and issues, including owner and mitigating action.
  • Do include information about the budget and how you are tracking to it.
  • Do include an overview of the major milestones, their planned dates and a RAG status of each.
  • Do list key successes and achievements from last period.
  • Do list any earned value metrics you may have, but keep it simple and graphical.
  • Do make it clear what action you want people to take; is this report just for information or do you require a decision from anyone?
  • Don’t send out the report via email without providing any context in the body of the mail. Executives may never read the report, so provide a summary in the email itself.
  • Don’t send out bad news in a project report with out speaking to people first. You don’t want your sponsor to read about a major issue without being there to explain the situation.

Download a free template
To see an example of a perfect progress report, log on to my resources page and download a free copy. If you have any suggestions to improvements, please add a note to this post.


If you liked this post, you may also like: 
8 Tips for Managing Project Costs
10 guidelines for estimating project effort
Risk management is how adults manage projects!
Are you making any of these 10 project management mistakes?
What makes a perfect Project Initiation Document (PID)?



3 Comments
Simon Kynaston
10/8/2014 12:01:09

Nice idea, if only it was that simply, Hou just consider what the report may be used for as different stakeholders may have different perspectives and not forgetting this May be used to support project finances. The one page won't do it, the stats are required. A one page report with any financial info can be lethal to your demise if the board is expecting something different, by the end I reserve bottom line costs to at least page 3 with previous pages capturing much of the above lists in simple bullet point format. This is to ensure the readers have to engage in some brief details rather than just skipping to the points they believe to be most prominent. I also preface my reports to ensure the context of the report is clearly set out. Thereafter, risks are compiled into a 'Critical Risk Report' as the circulation of this report is more so controlee. May not be a good idea to highlight all the risks to everyone when your client may have other agendas not known to you.

Still a great guideline :) Thanks.

Reply
Robert Rattray
3/9/2014 07:30:15

Excellent article with some very helpful points. I have found that having 'last month/this month' data to be very helpful in progress reports. This anchoring of the data has been appreciated by stakeholders as a way of demonstrating progress - and keeping PMs on their toes :-).

Reply
Jesús R Bacca M
8/9/2014 10:09:50

Very useful article. I would add a couple comments with regard of frequency and target receivers of the status report:There must be a least two different status reports. One is from the project team to the PM, issued weekly. It must be technical and it should include tasks executed during last week, a simple lists of them, tasks to be executed next week, issues, concerns, changes requests from end users with a first evaluation (in terms of feasibility, class 2 costs and schedule impact). It must be presented by e-mail to the PM the day before of the technical weekly meeting of the project team where the PM gives the directions for next week (if any), a rapid risk and change request analysis is promoted and common teamwork concerns are discussed. No more than 1 hour meeting.
Second is a three pages or slides report from PM to a Steering Committee or Sponsors or to key stakeholders where I recommend specially to show major objectives and scope of the project (items out of the scope too) always in the first page or slide of the report. (It avoids deviations without following a formal change procedure). A S-curve, with a short explanation of budget execution deviations and how they are handled or solved in the second page and a list of issues and changes that need high level decision for they to be solved in the third page. This report must be issued every 15 days or monthly depending of the time line of the project.
Regards,

Reply

Your comment will be posted after it is approved.


Leave a Reply.

    Categories

    All
    Agile
    Authenticity
    Building Relationships
    Coaching
    Delegation
    Estimation
    Feedback
    Handling Conflict
    Innovation
    Iron Triangle
    Limiting Factor
    My Story
    Perception Of Failure
    Podcasts
    Positive Attitude
    Proactive Project Management
    Progress Reporting
    Project Costs
    Project Failure
    Project Initiation
    Project Leadership
    Project Management Mistakes
    Recruitment
    Requirements
    Resistance To Change
    Risk Management
    Self Esteem
    Stakeholder Management
    Stress Management
    Team Motivation
    Time Management
    Trust
    Vision And Mission

    Picture

    Susanne Madsen

    Susanne is a project leadership coach and the author of The Power of Project Leadership (now in 2nd edition). Read more..

    Picture

    Download FREE PM RESOURCES

    Picture
    Picture
    Picture
    Picture
    Picture

    Archives

    February 2021
    January 2021
    November 2020
    September 2020
    June 2020
    March 2020
    February 2020
    January 2020
    December 2019
    October 2019
    June 2019
    May 2019
    March 2019
    February 2019
    December 2018
    November 2018
    October 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    September 2015
    August 2015
    July 2015
    June 2015
    May 2015
    April 2015
    March 2015
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    January 2014
    December 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011
    October 2011
    September 2011
    August 2011
    July 2011
    June 2011
    May 2011
    April 2011
    February 2011

    View my profile on LinkedIn

    RSS Feed

Susanne Madsen International - Developing Project Leaders