How do you report your project status?

Question

Currently I use the "One Page Project Manager" Excel Template for project status reports. It contains a summary of last week's work and a forecast for the next week. For all important tasks we track, if they are comleted or not. Everything on one page. I send this report every week to all participants/stakeholders. (hint: I do not work in an agile environment)

How do you report your project status?

Answer 1

Status reporting should be brief (nobody likes to sit there for ages while every member of the team goes on and on about their status) so I'm a big fan of SOFT reports:

• Successes - what have you achieved since the last status meeting: tasks directly off the project schedule. If possible I tried to avoid reporting x% done -- it's either done, or it's not. Reporting by % means that tasks will sit at 95% for weeks. This also encourages the project manager/tech lead to break down the work breakdown structure into tasks that are no longer than a few days.
• Opportunities - have you identified any opportunities: things that will help the project that aren't being considered yet (e.g.: found a better way to script something, a library that will save the project from implementing something themselves, etc)
• Future Work - what are you working on between now and the next status meeting: again, directly off the project schedule.
• Threats - have you identified anything that will impact your ability to get your scheduled work done? e.g.: a previously-unidentified hole in the requirements, support calls are taking a big chunk of your time, implementing something turns out to be harder than expected, etc.

Ideally I would try and avoid doing this stuff in a big project meeting since 90% of the material is irrelevant to half the people in the room. I like to collect SOFT reports before the meeting, spend some time looking at them before the meeting and then discuss specific issues that are probably relevant to everybody during the actual meeting.

Answer 2

I am not a fan of separate status reports. I would like project status reports to be a function of the project management software that we use. One of the best ways to save time and to make the same information available to everyone (team, management, stakeholers, clients) is to have a consolidated information/data management system and use it for all your needs. Even if you have to send separate reports outside the company, it preferably should be a report from that management system.

We are in an agile environment and use VersionOne. Team manages all the tasks and activities on it while it is available to everyone else in the company to view progress, see burndowns and many other reports that are inherently part of VersionOne.

http://www.VersionOne.com

Answer 3

Even if you're not using Agile you would still win from tracking your progress in functionality rather than in tasks.

Your stakeholders most likely have no idea what '*refactor the t_sec_name table to add auto-increment to the identity column*' means and most likely would not care if it is completed or not.

However if you would report the progress on 'Increasing performance of adding new users to the application' you would be able to convey the information on the progress to your readers.

So I would report:

• the progress of your changes/fixes/enhancements on the functional level,
  • work completed
  • work in progress
  • work planned
• decisions/issues for the business/customers to address
• risks (creating a report is a good time to update your risk register)
• team issues (holidays, sick leaves, trainings)

Answer 4

We have a variety of 'enforced' formats where I work.

My daily statuses are in three categories:

• things accomplished
• things not accomplished (and why)
• customer comments
  • including requests for features / additions
  • candid thanks, complaints, etc
  • misc other

Project statuses have the daily status concatenated with the schedule to show what is ahead/behind.

Answer 5

the project management information you maintain for yourself is one thing, what you show to senior management and clients is another.

if your customer is in the food transport business and is getting you to build them an ERP application, chances are they wont understand concepts from agile/scrum or prince2.

what will they understand? percentages and plain english.

here is an example of a 'project progress update' (or 'highlight report') i send to clients and senior management on a weekly basis (normally on friday afternoon).

===

HIGHLIGHT REPORT FOR 2/DEC/2008

• Your project is 65% complete.
• 100% of all tasks in the design/mockup phase have been completed.
• 70% of the tasks in the coding phase are finished.
• The project management phase is 45% complete.
• The quality control phase is 10% complete so far.

• 35% of auxiliary tasks have been completed

• our bug log currently contains 3 unfixed bugs (1 of which is marked as high priority).

• the bug log also holds 3 feature additions pending approval.

we have just uploaded the latest work to our staging location for you to review.

the next thing we are going to be working on is the photo gallery component, we are aiming to have that completed by the end of next week (to be confirmed mid next week).

we are still waiting on the credit card gateway provider to confirm your account so you can receive online payments. we have flagged this as a risk since we are still waiting on your internet merchant account to be approved by your bank.

let me know if you have any questions, i will be happy to answer them as best i can.

===

its simple. it does miss many useful metrics you can get out of burndown charts and scrum approaches. but those arent good figures to present to clients (or management) directly.

oh, and i should make a point about listing bugs. there are different levels of disclosure senior managers like. personally, i am very transparent. but you should check with your managers how much 'bad stuff' you are allowed to reveal to your clients.

i have a more in-depth blog article on this if you are interested: Project Status Reports Everyone Can Understand

LM

Answer 6

I have a whiteboard outside my cubicle. On it is a smiley face. When there is a status change in the project, it switches between frown, worried squiggle, grim determination, smile, and grin. Next to it is an arrow representing the last change.

Although it started as a joke, it's actuall been a great way to keep non-technical colleagues posted on where the project is at.

Answer 7

My company uses VersionOne to get information such as percentage of backlog items completed, deferred items from previous sprints, and overall project completion percentage. When we want to present this information to the customer, we create a power point presentation and include the info. For internal use, we just look it up on VersionOne's site or put it in an excel file for non-technical employees who don't have access to it.

Answer 8

I use an excellent project status report developed by my previous Program Manager. I've successfully used it since with various sponsors and they have liked the focus on issues, risk, milestones and budget.

I've put the XLS file up with a bunch of other PM templates. Eventually i'll put the words around it describing how to use it effectively. However if you stick to using non emotive language, focus on the impact of the issues / risks you should be set.

I've also had a look at the OPPM book and wasn't really impressed. On comparison our Project Status Report normally takes a 15 minute run through to learn how to use instead of a whole book.

NB: This isn't designed for team members to report their status, but for PMs to report their project status to sponsors and program managers busy with multiple projects.