The Project Manager’s Cycle – Publish the Project Status Report

“Project status this week, in a nutshell, is that we are continuing to stay on schedule, but this is despite your team’s contribution.”  After the initial chit-chat, Srini intentionally opened the status meeting with a statement to get everyone’s attention, especially the Sponsor and Owner Jack.  “Our project team has been working around the delays of returning document reviews and approvals.  We’ve pretty much exhausted the continuing work, though.  As you can see on the status report, there are several deliverables over due for approval and the draft requirements document is held up.  If you think these durations will continue, then I recommend that we extend the time your team is allocated for these activities and extend the time line.”

With this post, we conclude documenting the activities in The Project Manager’s Cycle, the Monitoring and Controlling activities that the project manager performs each reporting cycle for the life of the project.  All of these activities (with the exception of the Client Project Meeting) build each week to the Project Status Report (PSR).  The PSR encapsulates all of the information the Sponsor/Client/Owner and all Stakeholders need into a compact package.

The PSR should document both the current status of the project (in summary) and progress since the last report.  The essential elements of the PSR include an Executive Summary, Accomplishments, Planned Accomplishments (in the next reporting period), Deliverable/Approval Status, Change Request Status, and Issues.  Accomplishments and Planned Accomplishments are reported relative to the plan (project management is the classic example of Management by Objectives).

Note that traffic lights (  Red,  Yellow,  Green) are not in my list of essential elements of the PSR.  I am ambivalent about them.  When used properly they are often valuable, but they are even more often used improperly.  If you use traffic lights, the meaning of each color must be defined clearly and all of the stakeholders reading the PSR must know what each color means.  Further, a single light is really not meaningful.  After all, the ultimate purpose of the lights is to show where external action is needed and one broad status doesn’t provide the specificity needed.  Rather, what I’ve seen that works best are lights representing Schedule, Scope, Budget, Resources, and Closure/Acceptance repeated for each project phase or (preferably) each deliverable.

The PSR is probably the most important document the PM produces and I can’t cover all of the nuances in one post, so expect to see more on other elements of the PSR in the future.

Do you have a project status report best practice to share?  How about a PSR disaster?

The Project Manager’s Cycle – Review Issues & Action Items

“We will finish development in two weeks.  We had some setbacks last week that through us behind and the problems in my last report took longer to resolve than we expected, but we’re moving again and our momentum is back where it should be.”  The voice over the conference line exuded confidence and enthusiasm.  After a short discussion about scheduling a demo for executives, the call ended.   Of the two people in the room, Mike, the PMO director had the most to lose.  It was his responsibility to assess the reliability of the reports and set realistic expectations for the C-suite.  The voice on the other end of the teleconference was the delivery manager for a newly acquired subsidiary.  They were growing fast and the parent depended on them to quickly contribute to the bottom line.  But they had a well-earned reputation for dramatically missing deadlines.  They were already four weeks late on a three-month development schedule.  Mike had to evaluate the reports from the subsidiary and decide when the parent would ramp up the announcement and roll-out.  A misstep too late meant lost revenue;   moving too early and the impaired reputation of this conservative company would probably cost Mike his job.

Turning to the other listener, he opened the conversation:  “What do you think?”  Mike had asked this consultant to join him on the call and offer his advice interpreting the report.  “Mike, the application model is client-server.  They report they are using a development model based on Microsoft’s Solution Development Framework.  If this is true, then based on their report they should have all the navigation and major pieces of the application should be functional.  Anything missing should be stubbed in.  Just get them to present a demo for you.  When they can do that, then you know they’re getting close.  Until then, it’s just noise.”

It hardly seems necessary to say that managing issues is part of The Project Manager’s Cycle.  After all, sometimes it seems that all we do is fight fires.  The Review Issues & Action Items activity will probably seem very similar to the previous posting, Review Risks & Mitigation Actions.  After all, you maintain an Issue Log with owners just like you maintain a risk register with owners.  And review the Issue Log each cycle for items that you own, develop or validate the action plan, and then follow it.  If the issue or action item is product related, delegate it.

Also review the Issue Log for actions owned by others, follow up with them on status and to confirm they have an appropriate action plan and are making progress on it.  You may need to nudge some owners.

We are often overwhelmed by issues:  poor planning, difficulty taking a roaring forest fire and decomposing it into actionable responses, failure to use our team (manage laterally), failure to delegate (manage down), failure to escalate (manage up), and failure to follow up and communicate.  Dealing with issues is a lot like eating a sizzling four-pound steak:  cut off a small piece, take a bite, chew, swallow, repeat.

I will offer my “best practice” for tracking issues and action items.  During our weekly project meetings (you will find later in this cycle that there are two) we discuss issues, resulting in clearly identified owners and action items they are responsible for.  All action items are reviewed before the meeting concludes.  The action items and owners are listed in the meeting minutes.  Then, and this is the key part, the issues and action items from that meeting roll forward into the agenda for the next meeting (sort of like sourdough starter).  Issues and action items stay on the successive agendas until consensus that they are closed.

This practice obviously doesn’t work for very large or badly run projects where there may be dozens of issues and actions, but it is simple, effective, and keeps team members accountable for the typical project I lead.

There’s a reason that review risks precedes review issues in my version of The Project Manager’s Cycle.  We can get so overwhelmed by current brush fires that we fail the due diligence that limits future bonfires.  It’s worth noting that a project with lots of issues is symptomatic of either poor planning or poor risk management.

Good planning and following the PM cycle will help you manage issues rather than letting them manage you.

Do you have an issues and action items best practice to share?

The Project Manager’s Cycle – Validate Task Status

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