Effective Project Status Meetings

Project status meeting

One of the duties of a project manager is to find out from team members where they are at on their project tasks.  This can be done in a lot of different ways including automated or email-based solutions.  I have found that these type of solutions generally do not work very well because team members are people and progress is not just a matter of percent complete.

The method of project status reporting  between the team members and project manager that I have found to be most effective is the project status meeting.  This can be in person or on a conference call but it should include all the team members at the same time.  The team members must provide status orally in front of the team.  Why do this so publically?   For accountability and transparency.    People will be more motivated to complete their tasks on time if they know that they will have to admit any lack of progress in front of their peers.  Team members also need to know where everything is at and how their actions affect each other.  This builds teamwork and can help build trust.

What should the agenda for this meeting look like?  Assuming that you have planned start and finish dates for each task, here is one format that can be used for weekly status meetings:

  1. Accomplishments – These are the tasks completed this week that the PM knew about before the meeting.  Yay team!
  2. Are these done yet? – Tasks that are supposed to be complete by now, but have not been checked off.  If the answer is no, then the next question is “When will it be done?”  You may want to also ask what they need to complete it. There are more suggestions for this in my posts Getting the Truth and Hidden Reasons Why Things Don’t Get Done.  Beating them up about missing the planned finish date is a bad idea.
  3. Have these started yet? – Tasks that are supposed to be started, but not yet finished.  Just like the previous agenda item, if the answer is no, then the next question is “When will it start?”
  4. Are these due dates still realistic? – Tasks that are due in the near future but not yet.  This does not include tasks already listed previously.  If a due date is unrealistic, the sooner you know, the better.
  5. Are these start dates still realistic? – Tasks planned to start in the near future but not yet.
  6. Issues – Problems that are interfering with planned tasks.  This is usually a narrative description with action items that are taken to resolve it.  These are often technical in nature.
  7. Risks – Problems that might occur, but have not yet.  Lots of things might go wrong, but you should discuss the highest risks and solicit new risks.
  8. Changes – Changes to the project that have been requested or approved.  These are usually scope changes.  Discuss with the team how these changes affect the plan.  These do not usually happen weekly on most projects.

One thing this agenda does not cover are long-running tasks in progress.  It is best to avoid long tasks in the project schedule.  Tasks should not be more than twice the status report interval.  If you are reporting weekly, tasks should not be more that two weeks long.  Tasks longer than that need to be broken down unless there is an objective way to measure progress, like physical percent complete.

This agenda may look daunting to do every week, but it can take as little as 10 minutes to get through it depending on the size of the project.  The data collected from this meeting is used to update the project schedule and prepare a project status report for the project sponsors and stakeholders.

11 thoughts on “Effective Project Status Meetings”

  1. This is a good list. I’d add one more heading “Operational”. This section covers the tasks which although not specifically project related, they are fundamental to the outcome. These operational tasks include start & finish of staff, contract renewals, regular communications, methodology changes, etc.

  2. The project status meeting can be a valuable tool if kept short. You mentioned that it can take as little as 10 minutes to get through it. One important thing to do is to set a definite start and finish time. I have seen too many meetings get off point or too detailed and go on for hours. The point is to get a quick update and get back to the project task at hand.

    1. I agree Sean. If a status meeting discussions are getting too technical or off-topic, other meetings need to be scheduled as needed to discuss these with only the people needed. Project status meetings are about getting status rather than a catch-all for everything on the project.

  3. This is a good list. I’d add one more heading “Operational”. This section covers the tasks which although not specifically project related, they are fundamental to the outcome. These operational tasks include start & finish of staff, contract renewals, regular communications, methodology changes, etc.

  4. It is essential to hold regular fruitful meetings when managing a project. It can be one of the most difficult jobs, with various operational tasks involved. The most important thing is to ensure that only those people who absolutely have to be present in the meetings are there, and unnecessary factions are excluded to prevent confusion and wastage of time.

  5. Thanks for your complete list of project management details check list. These fundamentals are very useful for all. Keep going. I except more posts like this for prepare PMP Exams. Keep posting. thanks for sharing this useful and valuable information.

  6. I was curious if you ever thought of changing the page
    layout of your blog? Its very well written; I love
    what youve got to say. But maybe you could a little more in the way of content so
    people could connect with it better. Youve got an awful lot of
    text for only having one or 2 pictures. Maybe you could space it out better?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>