How to Report Status on a Project

How to Report Status on a Project
By Rob Redmond

Your boss has asked you to take the lead on a project in your company. Maybe you are a project manager, or maybe you are not. One thing is certain. Very few people know how to report status on a project, even when they are expert project managers. The basic problem? Most people do not understand the perspective of a manager who is being pressed for information about a big project. Here are some basic rules of reporting status that you can use to further your reputation as someone who knows how to keep management and the project team informed and drive a project to success.

The Management Perspective

If your project is important, your boss will be pressed hard to keep his superiors informed of its progress. Smart managers consume status on important projects voraciously. Excellent status reporting means that managers are fully informed of your projects health and overall direction without having to get involved themselves. There is particular information your boss needs in order to show her boss that she is on top of things and able to run the show effectively. Provide this information in a way your boss can consume it on a regular basis, and you will fall upstairs so fast your head will spin.

Even on relatively less important projects, effective status reporting allows your boss to spend only a few seconds skimming your report to determine what sort of progress you have made.

Excellent status creates clarity from confusion. Your job as the manager of a project is to take a swirling, chaotic cloud of information and distil it down into its most basic elements and then present them so that hundreds and thousands of hours of work can be understood in 30 seconds.

To write excellent status, you must understand:

  • The three components of status
  • How to write brief details
  • What key data are needed by management

Three Components of Status

There are three major components to reporting project status:

  • Overall – We need to see the overall project health. As managers, we want to be able to detect a project in trouble. We also want to help make that determination sometimes. You might not know everything we know despite our best efforts to communicate. Your project might not be as healthy as you think it is.
  • Milestones – Your project has major accomplishments which must be completed by specific dates. We managers want to see which milestones are complete, which ones are in progress, and which ones are coming up next. This allows us to analyze the schedule and decide to either feel comfortable with it or challenge it.
  • Issues – Your project also probably has one or more obstacles to completion which have been discovered. We’d like to see brief details about each issue so that we can make a decision about whether or not to step in and help if necessary.

Organizing Your Status

Just as you would clean a kitchen by starting up high and working your way down ultimately to the floor, project status is best when it starts off with the highest levels of detail and works it way down to lower and lower levels.

Thus:

Overall project health comes first. If I like what I see here, I can stop reading the rest.
Major milestones follow overall project health. If I don’t like the project health, or if I am in need of further details, I can read a little further and check out the scheduled dates we are driving toward and your progress on them. Issues may be holding up those dates, so when I see a problem in your project schedule, I can read further and see what it is. Really slick project managers report the issues in priority order showing the issue causing the most jeopardy to progress first.

Brief Details

Your job is to report on the details of your project in concise, crisp status that we can consume rapidly without having to spend much effort on it. It might take you thirty minutes to write your status, but always remember that your manager does not have thirty minutes to spend reading it. Your manager realistically only has about 30 seconds to consume your status as they may have 30, 40, 100, or even exponentially more projects for which they are responsible.

“Brief Details” may seem oxymoronic to a project manager, but to a supervisor with a team of project managers, it is not. There is enormous value in a project manager who can report status without narrative. My recommendation is that you write as though you were creating an old-fashioned telegram. More information about how to do that is coming.

Brief Details?

How can you provide details without being long-winded? It is a formidable task that most never master, but it is not impossible. Here are some suggestions:

  • Write in bullets, not in prose. There shall be no paragraph anywhere in your status.
  • Avoid unnecessary use of titles and colons. We can see that 7/4/2008 is a date. Writing “date: 7/4/2008” does not tell us anything that “7/4/2008” does not.
  • Reduce, reduce, and reduce some more. Do your best to shorten all expressions and sentences
  • Avoid adverbs (really, very, much) and avoid adjectives (good, bad, ugly)

Key Data

Management will need certain data from you in order to see overall health, performance against milestones, and the threat that project issues present. For overall project health, these data points might include:

  • The project’s name
  • The project identification number if your company uses a tool to store projects
  • The overall project health (red yellow green – more on this in a future article)
  • The % complete you expected to be at today (planned completion)
  • The % complete you are actually at
  • The number of days behind or ahead against the plan
  • The number of blocking issues you face (more about this later in this article)
  • The number of “normal issues” you face

These data elements should provide a sound overview of project health for the average executive who is not details minded and is not interested in getting more involved in your project.

If I am your supervisor, I need to see more than just the overall health of the project. I also want to see where we are against certain milestones so that I can make a decision about whether or not to get more involved. One of the hardest things a manager has to do all day is decide whether to give you more room or get into your work with you. We don’t want to carry your work for you, but we also don’t want you to fall flat on your face.

Providing project milestones is helpful in this regard. It lets us see your schedule at a high level, determine if the schedule is acceptable as it stands, and predict pitfalls you might face down the road.

Milestones have six components:

  • The milestone name
  • The percent complete of the milestone
  • The planned start
  • The planned finish
  • The actual start
  • The actual finish

Some people like to provide red, yellow, green (RYG) status for each milestone in their project. I don’t believe that adds any value. Of course the completed tasks are green. They are complete! All following milestones have the same status as the current milestone, so there is no point in differentiating them. The RYG status of the whole project is all that is necessary.

It’s best to start with the earlier tasks first and the final delivery date at the bottom. If you list them haphazardly, you will create more confusion than clarity.

Issue Management

The final portion of your status report is to list the major issues your project faces. Important data that we need on your issues:

  • Ticket number – if there is a ticketing system, give us a link to the ticket or the number of the ticket
  • Issue name – this should be very descriptive and brief.
  • Date and time reported – we need this to see aging. The older an issue is, the more likely someone is going to get in trouble for not solving it faster.
  • Priority or severity of the issue – your issue is mega-important if it is a “blocking issue.” If the problem is stopping the project from moving forward and is single-handedly responsible for endangering the delivery date, it is a blocking issue and is very important. If the problem is just another bug in some software that will be resolved in short order, it is not as important.
  • Who has it – the name of the person who currently owns driving this issue forward
  • ETA – Managers are like children and always want to know when they are going to get something. “Are we there yet? Are we there yet?” Provide a time and date for when the issue will be resolved. If you cannot, then provide a time and date for when you will get to the next step in the issue resolution process. If you cannot do that, then provide an ETA for your next updated status on the issue.
  • Current Activity – What is currently being done to resolve this issue? Are you firing up a conference call? Are you calling out for reinforcements from a particular group? What is being done to mitigate? Are there alternatives?

Expected Results

If you produce really great status on a project and provide it often enough and to the right people, which are great topics for future articles, you should expect one of two results. Either management will become very quiet and not engage with you very much, which usually means they feel you are on top of the project and are capable of operating without their intervention, or they will increase their communications with you in order to ferret out further details and determine if they need to intervene.

Either result is better than the alternative: Management asking you for status. Your job as a project manager is to create clarity from confusion for the project team and for management. Essentially, the job is one of analysis and communication. If management is asking you for the status, either you are not sending it to the right people, you are not sending it often enough, or you are not sending a good status report.

Management should be able to passively absorb your status without having to reach out to you to find out where things are at. The pace at which you send it, the audience you select, and the content of your communications should be available to them easily and quickly.

A project manager that can status a project skillfully and briefly is a rare find. It should not be necessary to create colorful slide shows or multi-page documents in order to provide really great status reports. Many go that route and drown management in errata. Narratives and prose are always unwelcome in status reports, and yet so many write as though they were authoring a novel and create a report that management must spend inordinate amounts of time with in order to get what they need. Others fail to provide enough information at all, or worse, they provide status irregularly or rarely.

In all of the project management training and certification systems available today, almost none teach how to report the current state and next steps of a project. Learn to status your projects effectively and you have a competitive edge that goes beyond the standard project management toolkit.

Rob Redmond studied sociology, psychology, and political science as an undergraduate before entering the workforce. Returning to school, Redmond earned an MBA from Georgia State University in June of 2000. Rob is currently employed as a manager of IT of a large technology company. Rob runs the struggling manager blog where he posts about his experience in both management and project management.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

7 Responses

  1. Avatar Bruno Collet says:

    Very helpful summary, Rob.

    I’d like to add that project status should be provided in both push and pull mode. Let me explain. Push mode is when the PM sends the status to managers, let’s say every Monday morning. Push mode allows managers to access project status on-demand with a web interface. A project management software with a server version, or a simple wiki, does the job.

    Even if managers don’t often use the on-demand project status, they will appreciate the “ongoing” nature of reporting.

    I am in both roles: PM and manager. As manager, I also like seeing a chart (a burndown chart for example). I also like colors, but that’s really a question of personal taste.

    Bruno Collet
    Blog “Execution in the Information Age”

  2. Avatar Julian Gall says:

    I agree with most of what has been written but I’m a little uncomfortable about the reporting percentage complete of a milestone. One of my pet peeves is lack of clarity in terminology for project management. I think we need to know what we mean by deliverables, activities, milestones, scope, objectives etc.

    It seems to me that pregnancy is an activity, birth is a milestone and the baby is the deliverable. This is intuitively understandable. The pregnancy has all the features you mention when you talk about a milestone.

    So, are we as part of atatus reporting just talking about major activities or project phases? I don’t think so. As a project manager, it’s important to know about the milestones too. e.g. When will system testing start, when will it be finished, when will the system go live etc. These are the really important aspects of the project and do not necessarily have any related “percent complete”, but meeting them keeps the project on track.

  3. Just to sum up this matter, we put three points to consider on a status report.

    Point #1: “where we are”: this is to describe the position of current progress. It could be cost status, time status, and scope status. Use a dashboard or simple chart to describe these will be better.

    Point #2: “how we are doing the project”: this is to report what problems and issues happened within the project and how we responded them. This will include summary of changes within the project and/or the product.

    Point #3: “where we are going next”: this is to describe action plans to do next week.

    Notes: The summary of Point #2 can be also put in Lessons Learned Document at the end of the project phase.

  4. Avatar Samer Zawaydeh says:

    Dear Sir/ Madam (PM Hut),

    Thank you for your article about the Project Status report. It is directed toward creating a brief summary of the project. This is what the Executive Summary in the Monthly report should contain.

    Please allow me to add, that if the Planner is trying to create a Monthly Status report, then it should be more comprehensive.

    These segments are a must in each Monthly status report:

    Scope:
    I. Engineering (Material and Shop Drawings)
    II. Procurement
    III. Construction
    IV. Commissioning and Testing

    Cost:
    I. Invoicing
    II. Extra Work
    III. Variations

    Time:
    I. Approved schedule with Critical Path
    II. Actual progress with updated Critical Path
    III. Delays and reasons for delays

    The status report should address each issue above in addition to list all the following:

    1. Minutes of Meeting
    2. The following logs:
    a. Correspondence sent and received
    b. Non Conformance Recrods Issued
    c. Material submittals status Log
    d. Shop Drawings status Log
    e. Procurement Log
    f. Invoicing, insurance and guaranttees Summary
    g. Request for Information
    h. Confirmation of Verbal Instructions
    i. Daily reports
    3. Manpower summary
    4. Outstanding Issue and Recommendations

    Thank you again for your excellent article.

    Samer

  5. Avatar x says:

    Dependencies?

    Key dependencies?

    And how to identify the differences between either? And how to report?

  6. Avatar Patrick Browning says:

    This article was a validation for what I have to learn as a PM and Manager, reporting to higher levels managers over the years. I have learned that my bosses, almost without exception, want a 20,000 foot report for the project. Bullet statements and usually some type of color charts created from the data have been the norm in providing status. RYG and a bullet for Red status under each milestone has always helped provide the needed information.

  7. Avatar Janisse Green says:

    Excellent and useful information

Leave a Reply