Friday, February 18, 2011

The Project Manager’s Cycle – Negotiate with Resource Managers

“Rainey, are you aware of any recent changes with Mani?” Don was having lunch with Rainey, the Analysis and Design Manager and Mani’s resource manager.  “She’s missed a couple of deadlines, which is unusual for her, and one of the business contacts mentioned she’s been ‘testy’ in some of the meetings.  I’m concerned.”  Rainey, after a thoughtful pause, replied “Have you asked her about it?”  “No,” Don answered, “not yet.  I will talk to her this afternoon; since we were here, I just thought I’d see if you had any background.”
Up to now in my series on The Project Manager’s Cycle we’ve primarily been working with numbers and reports, with little communication outside the project team.  This is the first activity where we start coordinating with project stakeholders.  This activity assumes a matrix organization, where you have temporarily and/or partially borrowed resources from department managers in order to staff the project.  If you own the resources – that is, they report directly to you as their line manager – then you can skip this activity.
This activity takes as input the results of the previous two activities:  replanning the schedule and reviewing team member progress and productivity.  As a result of those activities, there may be changes to the planned utilization of team members or concerns about their performance or productivity that you need to discuss with their managers.
For each project team member, prepare a schedule that shows their expected allocation by week for the next several weeks.  Depending on the organization and the resource manager’s planning cycle, this may be as short as 3-4 weeks;  other managers may require three months or a full schedule showing the allocation as long as the resource is needed.
You may also want to provide the information by task with completion dates, depending on the detail that the resource manager wants to see.  You can use your scheduling tool’s Gantt chart feature or populate a spreadsheet.
Provide these reports to the resource managers and, where appropriate, schedule to meet with them, especially if there are performance or productivity concerns.  Review the report, productivity, progress, and any changes you’ve noted from prior weeks.
But don’t expect the resource managers to just accept your plan.  They may actually have assignments, priorities, and expectations for these same resources, which, of course, may require some negotiation on your part and the possibility that you are back to replanning the schedule.
When you have performance or productivity problems with a project team member, do you talk to the team member first or to their resource manager?  Why?

Tuesday, February 15, 2011

The Project Manager’s Cycle – Check Variances and Productivity

“Kevin, I see that for the Architectural Strategy Document, your task to track down all of the legacy systems we interface to is falling behind.  What’s going on?”
The next activity in The Project Manager’s Cycle takes as input the revised schedule from the replanning and rescheduling activity.  For this activity, the project manager compares the newly current project (cost and duration) schedule with the baseline to identify variances and develop appropriate response plans.
For example, the PM will review the current expected cost to complete each project deliverable with the baseline cost.  Not all shops track (dollar) costs, but resource hours can generally be used as a proxy for cost when effort-based scheduling is used.  (If you are not using effort-based scheduling, well, you are already behind the eight ball for best practices.)  For any deliverable where the current costs differ from plan by a designated percentage or dollar amount (say, 10%) plus or minus, the PM should investigate and document the reason for the variance.  As appropriate, prepare an action plan for addressing the cost/effort variances.
Likewise, for each project deliverable compare the completion dates with the baseline completion dates.  Again where the dates differ by a designated amount (say, two weeks) plus or minus, the PM should investigate and document the reason for the variance.  As appropriate, prepare an action plan for addressing the schedule variances.
As PM, you also want to review progress (effort and duration) at a more granular level to determine whether you are getting the performance and productivity from team members that you expect.  This is, of course, subjective.  Look at each active task and the team members’ recent reports for early warning signals that there is slippage or that you can act to prevent slippage.  Also look for patterns that should be factored into the remaining project schedule.  After all, you want to be already responding to variances long before the dashboard turns red.
Finally, having identified and explained the cost and schedule variances, consider whether project change management is appropriate.    That is, are the changes caused by the team or because the plan was faulty (absorb the variance) or because of scope, environment, risk, or client events (change is appropriate).
How high do you allow the variances to get before you step in?  How do you typically raise the need to discuss a variance with a team member?  When do you escalate?

Saturday, February 12, 2011

The Project Manager’s Cycle – Reschedule/Replan

“What do you mean ‘You’re going to be gone for four weeks starting next month?,’” asked Alice, after picking up the phone on one of the rare occasions she was actually at her desk and listening to Ravi explain his new vacation plans.  “But … well, you didn’t know.  I just found out that Infrastructure is slipping their schedule so we’re going to need you until the end of the month after all.”
Now we transition from initiation activities to planning and design within The Project Manager’s Cycle. 
If it hasn’t been done already, all the team member updates from the metric validation and the task validation need to be posted to the project schedule, including closing completed tasks, updating effort estimates, and opening tasks ready to start.  Your perfect plan from last week is now corrupted from just one week of actual results – new end dates, team members who are now over allocated,  team members who won’t be available as previously planned due to conflicts or newly planned absences, newly exposed issues, political maneuvering, prioritization conflicts, team member conflicts, and stakeholder conflicts.
Now you, the project manager, apply intelligence to scheduling, adjusting start dates, shuffling tasks, balancing resource allocations, and drawing on schedule buffers as needed.  Sure, your scheduling tool “auto schedules” and probably has an option to load-balance resources.  However, the rule engines for these are notorious for making obscene messes of your schedule.  Depending on the need to maintain the original target dates and prevent slippage, you may need to consider adding resources, overloading resources (OT), reducing scope, and crashing the schedule.
As a further part of this activity, you will also address event-driven activities, such as unplanned/dynamic impacts, deliverable acceptances, reprioritization, issues, problems, commitments, and the other conflicts mentioned above.  This may involve adding project tasks, reassessing resource assignments and allocations, changing task estimates and getting team members to re-estimate their task assignments.
The end result is a new draft schedule that you have to validate and “socialize,” which transitions us to the next activity in The Project Manager’s Cycle and sets the stage for my next post.
Unlike most of the other activities in The Project Manager’s Cycle, rescheduling and replanning is not something that is done and then completes.  Rather, every thing you as the PM does has the potential to expose a need to adjust the schedule;  adjusting the schedule has the potential to expose the need to further adjust the schedule or to take some action that will … well, it’s called The Project Manager’s Cycle for a reason.  This keeps happening ever and forever for the life of the project.    You are constantly restarting this activity.  Plan on it.
How do you live with yourself when you have the perfect project plan?

Wednesday, February 9, 2011

The Project Manager’s Cycle – Change Control

“We missed one of the major requirements,” Don, the PM, was reporting to the owner in the status meeting.  “However, at this point we have very limited options.  If we add it now, we blow out the schedule and budget.”  “So what you are telling me,” replied Amy, the Finance Director and owner of this project, “is that I either have to live without this feature or I have to OK more money and it will go into production even later?”
The next activity in The Project Manager’s Cycle continues the “initiation” activities of the cycle.  We’re still collecting and building the inputs to the week’s monitoring and controlling activities that we repeatedly perform for the life of the project.  Therefore, this activity can be performed before, concurrently with, or after Validate the Metrics and Validate Task Status.
For this activity, Incorporate Approved Change Control, we are applying to our model the changes that have been approved in the prior week.  We then re-baseline those elements of the model.  The model is, of course, the project plan including the project schedule.  It’s appropriate to perform this activity now so that as we update the actual results based on team members’ accomplishments, the updates are made to the current, approved plan.  In addition, we want subsequent reports to reflect the approved plan – the one the stakeholder’s expect to see.
This activity completes the “initiation” activities of the weekly cycle.  We now begin taking these inputs as well as other outputs from the previous cycle to work the project.
I’m going to throw in a semi-unrelated aside here.  It’s unfortunate, but “Change Management” has two distinctly different connotations that lead to unnecessary confusion when we fail to make the intent crystal clear.  Specifically, there is “Project Change Management” and “Organizational Change Management.”  This post, as well as the PMBoK references to change management are for project change management – identifying, tracking, and applying approved changes to the baseline project plan.
Organizational change management, in contrast, is what we run into when we plan implementation of our project results – the people, process, and tool changes that our project makes to the organization.

Saturday, February 5, 2011

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?

Wednesday, February 2, 2011

The Project Manager’s Cycle – Validate the Metrics

“Okay, I’ve posted my hours now.”  “Great, thanks.  Let me check the reports…  It shows that you have four more hours to complete the task and that you’ll be done on Tuesday.  Is that correct?”
a)      “No, sorry.  It’s complete, I just forgot to update that part.”
b)      “Yes, that’s right.”
c)       “No, the mapping is more complicated than I thought.  It’ll be Friday, at least, before I’m done.”
The Project Manager’s Cycle involves taking in raw or rough data, processing, validating and acting on the data, then organizing the result into a coherent model for communicating to your stakeholders.  The initial data comes from reports by the project team members.  They report the state of their tasks relative to the plan, including progress/completion measurements for each of their assigned tasks.
The ideal source of the initial metrics is an enterprise project management tool, such as MS Project Professional with EPM, CA Clarity, or Planisware OPX2, where each team member updates the hours they worked on each task and the remaining hours to complete the task.  Without such a tool, the metrics may be percent completion values and changes to task end dates.  These are not as reliable, but they may be the best you have available.
Something that I have observed is that project team members, even veterans, have to be periodically reminded to make these updates and the expectations for reliability.  For example, the estimate to complete (ETC) must be re-estimated each week, not just reduced by hours worked, for it to be meaningful.  Alternately, percent complete values also need to be re-evaluated, not just incremented.
The project manager receives these metrics and is initially concerned with determining that they are within the expected norms.  That is, that the team member worked the planned number of hours for that week and that the remaining work is as planned.  Note that if the PM only focuses on hours worked (or percent complete), a major early warning indicator is lost.  Hours worked and hours remaining (percent complete and completion date) are a check-and-balance that the team member is progressing according to plan.
The first important validation is that team members are posting their hours accurately.  That is, that all hours worked on this project are posted to the appropriate tasks and only hours worked on this project are posted.  Otherwise, team members may under-report hours if they are experiencing difficulties or over-report hours to obscure time spent inappropriately on other efforts.
With accurate hours reported, any significant deviation, either positive or negative, needs to be flagged for follow up.  For example, if the resource is not contributing as many hours as planned, the PM should coordinate with the resource manager and the team member to determine why and how to limit impact to the project.  On the other hand, if they are working more hours, does that mean they are getting ahead or that they are having difficulties?
It is also appropriate to determine if team members have identified work that needs to be done that was not identified in the plan.  In other words, they need to report hours worked (or will need to report hours in a future period) and have no task to report those hours to.  Of course, as PM you will need to determine whether this work is new (maybe it’s included in the scope of another task), if it is new, whether it is in the project scope, and whether this needs to be addressed through change control or just not done.
Finally, confirm with team members which tasks are completed so they can be closed in the schedule.
Having an accurate and reliable schedule each week requires having accurate and reliable inputs from each team member.  Have you had success getting these from your project team members?