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!

  • What process model are you using? This may help us provide a response that may work better in your environment. – JoeGeeky Dec 18 '11 at 19:35
  • Are you currently using any commercial project status dashboard, eg: goo.gl/n0ItCE ? – Amrinder Arora Jun 8 '16 at 12:07

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?


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.


For different people you should chose different report frequency, for top management such as stakeholders or steering committee, better report once a month. To the management group as your line manager should be weekly review, 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!


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.


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.