How do you report project status?

Question

What is the typical project reporting model are you using in your project team? When I say reporting, I am talking about both reporting externally to stakeholders and internally to all team members.

Do you use an 'active reporting' mechanism like everyone sending out status emails, or project manager going around asking for updates, or a daily status update call - or you use a passive reporting mechanism, like the project management system itself generates reports in an automated way based on normal project tasks updates entered by team members? How much of your reporting is individualistic and how much is tool dependent? Is it daily or weekly?

I would like to know what has worked best in your situation (please mention your context - like a co-located team or geographically distributed). There is obviously no one-size-fits-all answer.

Many thanks!

Answer 1

Some guidelines on status reporting which have worked well on projects I have worked on:

• Adopt an "active" approach: passive reporting is not productive because when it comes to project status, what matters is to tell people what's important for them to know at that particular point of time in the project. Passive reporting carries the risks of people ignoring the communication (if they have to go and get it themselves) and misinterpreting what's important. It's the role of the PM to sieve through the project information and pro-actively share the current status in a meaningful way.
• Adapt the frequency to your project: generally weekly reporting works well, but some projects may grant more frequent updates (e.g. projects with very short timeframes may require daily status report). If going daily, you have to keep it very short and simple at the risk of spending your entire time doing status reports. With Agile projects, daily stand-ups work well (though external stakeholders may not need the daily update).
• Get the status from the task owners: whatever frequency you report at, and whichever tools you use, the people who own the tasks need to update the status. Establish upfront a process with your team whereby people understand their responsibilities (what they have to update, how and when). As the PM issuing the report, it is then up to you to keep that process going and aggregate the information you want to convey in your status report (e.g. your team members are responsible for reporting status on their issues, but you make a call as to which issues you report on to your wider audience).

You can also review the following question: What makes an effective email status report? Why?

Answer 2

My team is co-located, working in a department of 6 small project teams (4 dev, 1 QA, .5 BA) and a dev ops team. We do a mixture of Scrum, Kanban and XP.

For the team, our story board is our main tool. It shows what's on our backlog for the next couple of weeks, what we're planning to do in the current week and we have a burn up chart that we print and stick on it to show progress towards our next releasable feature.

We invite our department management (CIO, CTO, Dev and Ops managers) to our morning meeting once every couple of weeks. This allows them to get a feel for progress and gives us a forum for raising risks and blockers.

For project stakeholders (users or user proxies) we run regular demo sessions to show what we've been working on, get feedback and guide our backlog planning. This may involve marketing people too if there is going to be any external marketing activity.

For the wider group of interested parties we do some email comms, this is usually a once a month email detailing all of the features released that month by all of the IT teams to avoid bombarding people with loads of emails.

Answer 3

The stakeholder segment defines the how, what, when, where, and why. It is a mistake to define a 'way' to report project status and to assume it will be appropriate in all cases against all stakeholder segments. While there might be similarities across projects, it would be a mistake to assume one size fits all, as you indicate in your original question.

So, I purposely avoid having a predefined method for communicating project status. I 'discover' it for each project during the stakeholder analysis effort and I actively modify to correct error in my earlier conclusions.

Answer 4

Ask the different people involved how they would like information reported, what information they would like reported and how often they would like to receive the information.

Answer 5

For different people you should chose differnet report frequency,for top management such as stakeholders or steering committee,better report once a month, but to the management group as your line manager should be weekly reivew, as you will need different support and resource from them. As the program manager, you should highlight the program risk/cost/schedule to let management team know your challenge and your chance,what ever, just keep the program transparent to all involved people, that will make things better than you can expected!

Answer 6

We use the Kanban Board as our main reporting tool. Every team member can go to the board and see current work in-progress. He can also see the backlog and todo list so he is able to see how much work we haven't started yet. If a PM comes and wants to know current status we usually bring him in front of the board.

We also do daily stand-ups, to communicate status and problems to each other.

We report to the client with excel spreadsheet that reflects the board and we let him align the priorities.

And now the context: co-located team of 10-16 with many maintenance projects and one big new project in-progress

Answer 7

We work over a connected network which helps our team members work over a collaborative platform and stay updated on project progress. The Microsoft Project 2010 at our organization is a web-based application which allows team members and project managers to fish out reports from the server itself. This minimizes going-around and handing over reports. I would suggest you check out the project management software and the features provided by the same to understand if it suits your needs.