How do you report project status? [closed]

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

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!

Answer 4

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 5

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 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

Reporting status to your team (internal) and to stakeholders (external) requires different communication approaches.

Regardless of being co-located or remote, most teams follow agile methodologies. So, status and progress reporting within the team is done during stand-ups, which can be daily or happen multiple times per week. Stand-ups are the perfect environment for each individual to talk about progress and any blockers they might be dealing with.

Typically each team is supported by a Program Manager, who guarantees the initiative is delivered on the timeline agreed by all stakeholders. The Program Manager will also interface with the external stakeholders on behalf of the team, and will join the team stand-ups and gather team updates, so they can regularly check-in and report progress to the Engineering manager.

Engineering managers, who are responsible for the technical quality of the work delivered, support multiple teams, work closely with Program managers to get visibility into what each team is doing. They usually have weekly or bi-weekly check-ins with Program Managers to get a pulse on the progress of each team, help escalate priorities and remove any blockers the teams are dealing with.

To propagate that information and give visibility to other stakeholders and leaders in the company, top-performing companies have a consistent approach to reporting status. You can find more information about it in this article.

Summarizing it, this is how they do status report meetings:

• Do one every two weeks,
• Block 30 minutes to 1 hour,
• Anyone who's responsible or accountable for a specific milestone must be present,
• Folks that need to be informed about progress are invited but attendance is optional,
• Go over the progress since the last meeting, what's blocked, and what will be delivered by the next meeting,
• Take note of any blockers and action items, and assign someone to work on them, Take time to celebrate accomplishments.

And because the main goal of these meetings is to provide visibility into company-wide initiatives, the meeting agenda is shared in advance and every attendee responsible for an initiative reports progress following specific guidelines:

1. Project and elevator pitch, so everyone can understand what the project is about.
2. Timeline for the project. This is a recap of how much time to ship the deliverable to customers, where you are today, and other major milestones.
3. Review action items from last status meetings and check they were completed.
4. Progress since the last status meeting. People responsible for deliverables do a demo at this point.
5. Activities that are blocked or at risk. At this point the team creates action items to get those activities unblocked.
6. Upcoming activities. All activities and milestones that need to be done until the next status meeting.
7. Celebrate accomplishments, achievements, and critical milestones.

The Program manager is usually the one organizing these status meetings. Some of their responsibilities involve taking notes, making sure the meeting starts and ends on schedule, and following up on the meeting's action items.

This way, information about the progress on a specific initiative is propagated across the company. From teams to all stakeholders involved, everyone has visibility into company initiatives.