In project management, what criteria makes an effective email status report, and how often should a status report be sent to be useful?

  • 7
    Can you provide context. Are you proving status to a PM, business owners, stakeholders, upper management, etc? More information would allow for better answers IMHO. – Mike Polen Jul 23 '11 at 23:42

An effective status report tells your project stakeholders in a clear, concise manner where the project is at and how well it's going. Its main objective is to inform, and to be effective it needs to be factual, up-to-date, and easy to read and understand for your audience.


email is fine for small projects, but for larger projects that have multiple streams of work it can be too limited: email calls for fairly short pieces of information (1 page or so), so works as long as you are succinct. Dedicated PM tracking/reporting tools or office documents (e.g. MSWord, MSExcel, MSPowerpoint) allow more details and more options in terms of presenting information (graphics, formatting, layout, etc.).


I find weekly status reports work well. Unless required to do so, nothing more frequent or you'd spend your time working on your status report (and wouldn't have that much to report on). Anything less frequent (like monthly) and your project loses visibility.


An effective status report requires to-the-point, factual and clear statements, regardless of the medium you are using. It is about what is happening now, so focus on what's just been accomplished and what's coming up, highlighting any key problem areas that may affect progress. Here is an example for structuring your content:

  • Report Header: Project name/ID, PM name, Date of issue.
  • Project status: a short statement saying where the project is at and how it is going against plan. You can also use a RAG (Red/Amber/Green) indicator to show progress (not to plan / at risk / on track). Show last week's vs this week's status so your reader can immediately see how things are evolving.
  • Key achievements this week: list key tasks worked on this week and any milestones or task completion achieved.
  • Key activities next week: list key tasks to be worked on in the coming week and milestones to be attained.
  • Top risks and issues: list any significant risks and issues that are affecting project progress. Try to keep it to 5 items or less, keep it short but always provide an indication of resolution plan/action for each problem.

Other recommendations:

  • Unless your are required to do so, I'd recommend you don't include budget information in the status report; typically this information only concerns a few people, it may be sensitive data and you will often not have much update week-on-week (accounting is typically done on a monthly basis).
  • To be effective, the format and content of the status report need to fit its audience. As Thomas said in his answer, his supervisor wants one page so that drives how things are reported. In other cases you may have stakeholders or supervisors who want to see a certain amount of details or content, in a specific format. It's good practice at the start of the project to validate with your supervisor/sponsor how you will report on your project.
  • The status report is to inform, so don't use it to resolve issues or address specific problems.
  • Don't use the status report to announce bad news: if your project is in trouble, don't wait to communicate about it.
  • Be disciplined about issuing the report: it gives visibility to your project and also shows that you are on top of things. It's also very useful for you as a PM to keep track of how things are going and provides you with a formal, regular communication channel.

This is very dependent on the nature of your project and team. Generally, I try and highlight the areas of the effort that are highly variable. In software, this is typically open impediments, impediments discovered and addressed, and new work (stories) completed. I'll also include some graphs that convey budgeted burn vs. actual burn vs. total budget and historical current progress vs. expected total work (CFD report, for example)

Ideally, each of these, if not the overall report, is easily generated from an electronic tracking tool and requires little additional effort.

Finally, I tend to include a short paragraph of my interpretations of the information as the leading aspect.

So, as a template:

Project Name


Short paragraph describing my interpretation of the current situation, as well as calling out anybody that deserves positive recognition. I never include negative attributions to a specific employee, these are borne by the team as a whole.

Open Impediments

Issue one title - overview and ramification
Issue two title - overview and ramification

Resolved impediments

Issue one title - overview and ramification
Issue two title - overview and ramification

Completed work

Story one title
Story two title

Budget charts/details

  • +1 Eric, I like your template, it's clean and easy to find the information you are interested in. I would love to se a real world example. – Levi Putna Jan 4 '13 at 6:45

The status report that we use consists of just 4 sections: completed tasks, in-progress tasks, planned tasks, and blocking issues. It's just a Word document that's emailed to the supervisor by close-of-business every Friday (or, if you are taking time off, before you leave on the last working day for the week) and then archived, although with the new archival software, some people have begun to move to writing the status report in the email. If there are any important issues, you can also include a "notes" section.

As for the format, it's just a bulleted list, referencing an ID (everything has an ID, from defects to tasks to documents) and a few sentences about what we did regarding it. The overall length of the document should be about a page - if the supervisor has any questions, they'll ask for more details.

Depending on your time tracking policies (ours, being in the defense industry, are really strict, tracking time in 6 minute intervals and everything having a program and project charge number), you might also want to include that information. We don't, simply because our supervisors have access to our time cards. Some people still choose to copy the table generated by our timecard software into their weekly report, but it's not mandatory.

As for why this is effective, it's because it's on short intervals and it's kept short and to the point.

If you are asked to report your status every week, you actually have a somewhat decent recollection. Not everyone keeps a log of what they do. I try, but between the various projects that I'm working on, meetings that I go to, people that I talk to, and other things that happen in the course of the day, my log isn't always 100% complete. However, on Friday afternoon, when I sit down to write this, my memory is usually good enough to remember what I did on Monday (even at 4:30 on a Friday afternoon).

It's also short. My supervisor wants a page, and not much over that. It's just something that can be referred to later, if there are any questions as to what was happening. The time cards tell a story of what we worked on and for how long, but it doesn't answer anything about a "why?" or "how?" question. When you put your tasks in writing, you can keep track of why you did things, why you ran into problems, how you solved them, and so on. This is the kind of thing that's useful during performance evaluations and just to know how a project went during a retrospective.


From my experience on the "work" side of the equation (ie, implementation, not management), the most common format I have used and been asked to use is this:

Subject - [project] [time] status [date] {detail (could be a subproject)}



  • bulleted list of accomplishments of the day


  • bulleted list of issues that are upcoming or may impact the project


  • bulleted list of open cases (if appropriate) or open problems - subbullet as needed


  • bulleted list of related-but-semi-off-topic items (schedule interruptions, work arrangements, etc)

Plan for [date|period]

  • bulleted list of what is expected to be done the next day or week (week if the last status of the week)

So, a sample email might look like this:

Customer Name EoD status 05 Dec 2010

Good evening


  • Servers provisioned
  • Storage allocated
  • Media staged


  • Network allocation for server move


  • Power not ready in new rack


  • Company-wide picnic Friday afternoon

Plan for 06 Dec:

  • Get power to new rack
  • VLAN allocation complete
  • Move servers
  • Install {product}

The status report that I have used to update management and team includes a variant of a quadrant report. This will address the key concern and also the need to know status for the management and team. I have successfully managed to bring across key concerns and also highlight job well done by the team to management

Is as follows -

  1. HighLights (Bring Good news first )

  2. LowLights (Update bad news and what and who will work to solve it or identify the issue)

  3. Risk ( Possible things that could Go wrong and what are the back up options)

  4. Next Activities ( Key activities / deliverable s for next 3 weeks)


As has previously been mentioned audience is key to the template & frequency of reports. Don't be afraid to ask for feedback from you audience and make changes.

If your looking for a document template I like quadrant reports. They provide the ability for a person to quickly scan a document and see a project status visual via a traffic light. If the audience so desires, they can read about a certain area. Here is an example: http://www.sebasolutions.com/downloads/ProjectStatus-RevB.pdf

Note, that this is an excerpt from the book, The Handbook of Program Management by James T Brown.

Your Answer

