Collecting And Sharing Status

Question

How do you collect and share status? Some PM's think group status meetings are a waste of time and prefer to collect status in one-on-one's. Others prefer email. What works best for you? How do you collect updates on various tasks and share it across the team?

Answer 1

In general, I recommend looking for approaches where something serves the needs of collaboration and allows trivial status collection as a byproduct. Take a look at "information radiators" for more information, ideas, and perspectives.

For example, the transparency inherent in lean or kanban often involves a highly effective card wall is something that a team will keep accurate because it supports and serves the need of the team. The status is then easy to extract without having to "bother" the team. Used carefully, electronic tools can serve the same needs, especially in highly distributed/dispersed team environments.

Please note that the daily stand-up in an agile team is NOT a status meeting, and is another tool that serves the needs of the team while allowing some amount of status to be extracted.

Answer 2

For a small team, up to a dozen people or so, I have found a short weekly email to be useful with the least overhead cost to the team. This status report consists of

1. the list of goals for the week and their stauts
2. anything else worked on during the week not on the goals,
3. a prioritized list of what will be done next week.

The exercise of drafting the email causes everyone to spend some time thinking about where they are in the work and about where they need to be. If redirection, or correction is needed then I would approach people one-on-one to discuss. If additional coordination is needed then bring only the necessary people together to coordinate.

This avoids a weekly meeting where everyone has to wait idly until their turn to report status. Perhaps in this meeting some coordination occurs that would not have without it. However, I think work coordination is better handled among the team, or at a meeting focused on the technical matters - sometimes without a PM present.

Answer 3

One-to-one meetings work best for me when collecting status information. In contrast to team meetings, they give me a much better feeling how things are really going.

For sharing information, I am using both frequent personal updates and team meetings. I try to minimize the number of meetings but without getting everybody together regularly, there is a big risk of "loosing" some team members.

Answer 4

I found that walking around and talking to each person is the only effective way to get a full status update. the write it up and send an email.

Unless you're really good at it, don't use electronic means to record the status; pen and paper is the fastest and least annoying method, as far as those giving the status are concerned.

Work from the bottom up, going to the managers last. It was fascinating to see the reaction of managers when I reported to them what their teams were up to. The disconnect never ceased to amaze me.

It's time-consuming. When I did this in a company of about 100 people it took an entire day to collect and write up the information. But it was worth it:

• QA used this status report (sent out at the end of the week) to plan their week in their weekly planning meeting.
• Managers used this report in their weekly coordination meeting.
• C-levels used this to plan ahead.

Format:
Like all good status reports it had last week's plans, this week's achievements and the plans for next week, so that one could see how projects were progressing.

As a bonus, the weekly status report included current absences, upcoming leaves, vacations and holidays.

Answer 5

We use Microsoft Project Server for the team members to enter the hours spent and hours remaining on their tasks, and we use a SharePoint tasks list for action items. That way, we do not spend a lot of time in the status meeting talking about the boring part of status reporting. Rather, we spend our group meeting time coordinating future activity, discussing issues or questions, and reporting on status where other people in the meeting would care - for example, if person A finished a deliverable that person B needs, that would come up.

Answer 6

How do you collect and share status?

When gathering and sharing information you will have to decide between large target audience with little attention to detail and small audience with a much greater attention to detail.

Collecting data

• Option 1: Developer emails you status update. You read status and ask developer to clarify few points. Developer sends another email with clarification. You repeat the process for 10 developers. You then aggregate data, re-type it into a shorter summary and then share it with stakeholders. Problem here is that you'll be sending a number of emails, you'll be spending time reading emails and spending more time writing up a summary. This is a lot of work, if all that you want to do is collect and share status.

• Option 2: You have a one-to-one conversation with developer. You take notes of what you believe is important. You ask developer to elaborate on certain points. You then repeat this process for 10 developers. This should take less time. It will also improve your professional relationship with your colleague as well as give you an opportunity to find out about their fears and beliefs.

Sharing Information

• Share the right amount of information with relevant stakeholders. Don't bore flash developers with a data warehouse migration update.
• Find the right feedback process for the size of your organisation. There is no point in sending an email if there are five people in a department, just like it's pointless to have a meeting with twenty people in a room.

Some PM's think group status meetings are a waste of time and prefer to collect status in one-on-one's.

There must be a strong justification on why it's a waste of time. Points that I have made above can be easily used as an argument to this.

How do you collect updates on various tasks and share it across the team?

We don't. Developers know what they are working on and if something is unclear then they ask their colleagues, seniors or a project manager. We are a team of over twenty developers, QA lead, CI lead and few designers.

Answer 7

The method I've been using is to gather task updates (expected or actual start and finish dates + whatever commentary they want to provide) from each team member individually. This information is then used to update a shared project plan. The PMs then do some analysis on what has changed (looking at views of near-term tasks, selected milestones, critical paths, etc.) to create an agenda for a team meeting where we collectively agree priorities until the next meeting and what matters need to be flagged for other stakeholders attention.

The report out consists of various project views (Gantt charts, milestone reports, Risk and Issues log).

There's a neat little piece of software that makes this whole process quite easy that has been developed by Project Success Inc. It works nicely with Microsoft Project (2007, 2010 and 2013; not sure about 2016).

However, the software is far from perfect. It has messy, imperfect GUI and is not very intuitive for either PMs or task owners. The key success factors for this method seem to be capable PMs who are fluent with both Microsoft Project and possess enough facilitation skill and subject matter expertise to build a credible plan with input directly from the task owners.

Answer 8

I am currently looking for a tool to share status updates on projects easily with multiple stakeholders. I came across this site, http://knowapp.com/, which looks promising. It's not free but could be well worth its costs if it saves me on the multiple meeting needed to update on projects especially those in the queue.

Let me know if you have used it or know something similar.

Thanks!