“Carilyn, your status report says that you completed testing, but the task has four more hours on it?” “Yes, I ran one more test case this morning,” replied Carilyn. “But, as of Friday, when you did the status and the time entry, the task was still open? It’ll finish today, right?” “Yes, but it was just one more test case.”
Validating the task status within The Project Manager’s Cycle is done concurrently with Validate the Metrics. For this activity, though, you are reviewing each project team member’s status report (MSR) rather than the metrics that have been reported through tools. While this series will touch on status reporting in several entries, status reporting itself is a much bigger topic that I’ll eventually address in a future blog series.
The assumption for this PM cycle activity is that team members are submitting status reports. However, a “status report” can be tailored based on the project context. I’ve led small efforts – projectlets that are just a few weeks and have 2-3 team members – where I just drop by periodically and get a verbal update. The point is not the format, but rather the content you need and what you do with it.
First, the content of the MSR and the reported metrics are a “check and balance” against each other. The reports between them should be consistent; deviations should be noted and investigated. For example, if the team member reports on the MSR that they’ve completed a task, but the metrics show forty hours remaining, which is correct?
From the MSR Accomplishments section, note specifically task completions and mark these tasks completed in the schedule. In the Planned section, note tasks that the team member plans to start and make sure these are assigned to the resource, open, and available for time entry, including that the start date aligns for a near-term start. These should also be noted for review in the project team meeting (see future post in this series).
Finally, review the schedule the other way. That is, review open/active tasks for that team member and confirm the MSR documents task accomplishments (e.g., 12 of 15 test cases run successfully). Also look at tasks in the schedule that are scheduled to start and verify that the team members list them as planned in the MSR.
Any discrepancies need to be investigated, either with a discussion with the team member or during the project team meeting.
Other items to look for in the MSRs include issues (anything that is preventing appropriate progress on a task), risks (anything that may affect a future task), blocked time (environmental problems that prevented the team member from working on any project task), change management (changes to scope, quality, or cost), and deliverable status (is approval tracking appropriately) or milestone status.
Having completed these first two activities of the cycle, you have begun your list of To Dos for the week. Unexplained variances in the schedule and anything that raises a question or concern from the MSRs goes onto one of your lists: Issue Log, Risk Log, Commitment Log, Project Team Meeting Agenda, new change request, or your personal checklist of things to follow up on and people to talk to.
Getting good status reports from team members is always a challenge. Do you have effective techniques for getting them to provide the info? I’ve listed some content that should be in the MSR. Do you have additional sections that are useful?