The Project Manager’s Cycle – Conduct Project Team Meeting

“Alright, let me take a few minutes to update everyone from the Sponsor meeting.  You got the minutes, but I’ll drive into some of the content between the lines.  Then we’ll go around and let everyone give their update.”

I like to hold my project team meetings early in the week – Monday afternoon or Tuesday morning – and focus on what will be accomplished by the end of the week.  Over the years I’ve attended many other team meetings.  Those experiences, like my own early experiences where I focused on getting a status from everyone, provided a very accurate after-the-fact picture of project slippage.

We near the end of this series on The Project Manager’s Cycle.  The project team meeting is a different animal than the Client Project Meeting.  It doesn’t need the formality.  It’s where you surface the problems and develop an action plan for responding to them, so that you can go to the client with solutions, rather than problems.

I found that meeting early in the week and asking the team members what they were going to accomplish by the end of the week was effective at focusing their energies as well as driving out issues before they occurred.  There are only a few possible responses.  For example, if a team member explained that they wouldn’t complete a task on schedule because of a blockage that I could eliminate, I could do my job, keep them productive, and avoid problems.  Or if they commit to accomplish things that aren’t in the schedule, that creates an opening for me to ask questions to understand the variance.

The best case is if they commit to complete activities that are aligned with the schedule.  For most people, that duration is short enough that they have visibility into anything that would prevent them from completing the task.  So I can be fairly confident that if they say they’ll get it done that week, they will.

There’s one more question I ask, though, that builds on the commitment.  “What can prevent you from completing this task on schedule?”  This question is subtly powerful.  The inexperienced or naïve may say “Nothing.”  But this is a trap.   If they subsequently fail to make the commitment they cannot then roll out a series of excuses.  They have already stated before their peers that the only reason they would fail to deliver is their own.

The experienced, sharp, connected team members will use this opportunity to list all of the possible causes of failure or delay, which is just what I want.  I write the list down, then go through each item one by one.  These are the detailed task risks that you don’t generally hear about until they are brought out as excuses after missing the date.  By exposing them before the due date, as a team we can qualify them, prioritize them, determine the appropriate response, and assign an owner before rather than after the fact.  If something does happen, we have evidence of anticipating the problem and proactively responding.  Further, it gives me the opportunity to ramp up client or management resources in anticipation of a problem.

Further, when team members see that I am using the information to make them successful, they become even more open and trusting.

In terms of process, the project team meeting consists of the activities publish the meeting agenda;  conduct the meeting; and publish the minutes.  Inputs are team member individual status reports, the project schedule, and minutes from the Client Project Meeting.  Outputs may include updates to the schedule, Project Status Report, risk register, and issue log.

Most team members are forthright and dependable.  The challenge, though, is recognizing and motivating the remainder.  What do you do in your project team meetings to improve success, even from the challenging members?  Do you have other best practices to share for optimizing the success of your project team?

The Project Manager’s Cycle – Conduct Client Project Meeting

The occasion was the monthly project review meeting.  The PMO hosted these and all PMs were in attendance.  The typical agenda would have the PMO director select a half dozen projects, three flowing smoothly and three challenged projects, the PMs for each project would present the status, then the floor would open for Q&A.  Having your project records open to your peers can be very intimidating.  For this meeting, however, the senior project auditor  was presenting the latest revision of the project audit checklist.

“As you can see on the monitor, the checklist has five items for the client meeting.  For documentation, the PM should bring the most recent six weeks of client meeting minutes.  These are the document of record for the meeting.  Step 62 confirms that you are using the correct minutes template.  For step 63 of the checklist, we will confirm the frequency of the actual meetings.  For step 64, we will review the invitees and minutes recipients.  For step 65, we check that project risks have been reviewed and documented in the minutes at least once in the last month.  The final step in this section, as all others, is for the auditor’s subjective review – that the documentation reflects meaningful, productive and valuable effort, not just completion of a “check box” so the PM can pass the audit.  Any questions?

As Bob Dylan sang, everybody’s gotta serve somebody.  Whether it is the Sponsor, Owner, or Client, you serve this person as their agent to deliver the project.  They have delegated this responsibility – and presumably the authority – to you and will periodically want to discuss your stewardship of their project.

The Client Project Meeting is an odd duck in The Project Manager’s Cycle.  The predecessor activity to the client project meeting is Publish the Project Status Report (PSR, which I haven’t discussed yet) and the project status report is the input into the client project meeting.  The output of the client project meeting, in addition to the minutes, is potential input into any of the nine Knowledge Areas of the PMBoK (integration management, scope management, time management, etc.), any of the Executing Process Group activities (those activities specific to delivering the product or service), action items, commitment management, and the agenda for the project team meeting.

If I am delivering specifically a project status meeting to a project owner or client, I generally prefer not to have other project team members attend.  This has advantages and disadvantages.  I have control of the information and the flow and we can talk more freely.  But it can be intimidating if there are several owner representatives and there is always the risk of filtering information too much.  I will make exceptions when a team member has a specific contribution (to support a technical discussion, for example) or if I particularly trust members of the project team.  The owner can invite anyone they choose to this meeting and when this happens the meeting becomes more a stakeholder meeting than just a Client Project Meeting.

The purpose of the Client Project Meeting is to deliver the project status and to receive any changes in direction or commitment.  The most recently published project status report is the document of record, even if it is a week old, which it can often be.  It is important to have, maintain, and deliver “one version of the truth.”  I start with the latest published PSR, then discuss developments since it was published, which can help foreshadow the content of the next PSR and prepare the stage for bad news that may be brewing.

The component activities for the Client Project Meeting are:  Prepare and distribute the meeting agenda (one business day in advance);  Prepare the meeting package (agenda, project status report, change requests needing approval, deliverables needing approval, etc.);  Conduct the Client Project Meeting;  Publish meeting minutes (within one business day);  and Update issue, change, acceptance, risk, and commitment logs.

On a good week, the Client Project Meeting can bolster your ego, with lots of praise and acclamation.  On a bad week, you may feel like a cheap cut of beef, dropped in the coals, left too long, then squeezed through the wringer.  Good or bad, I always walk out of these meetings counting my fingers and toes.  It was a good Client Project Meeting if they’re all still there.

Obviously there are many options for the Client Project Meeting;  the decision of who attends, alone, changes the tone of the meeting considerably.  What are your experiences, good and bad, with other approaches to the Client Project Meeting?

The Project Manager’s Cycle – Review Commitments

“Yes, Anita, your family needs you at this time of loss.  My thoughts are with you and your family.  Do what you need to do and take all the time you need.”

With this post we conclude the “behind the scenes” activities of The Project Manager’s Cycle.  You won’t find this activity in A Guide to the Project Management Body of Knowledge (PMBoK).  This activity is performed during the Managing & Controlling practices of the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI), for example, the CMMI for Development, which can be downloaded.

I often take for granted the people that make commitments enabling my project to advance and succeed.  It is humbling to be reminded of the ephemeral nature of their commitments, including:

·         The Sponsor, for committing to the all-important budget

·         Owner(s), for committing resources, for committing to the requirements and for committing to success by running political interference

·         Resource Managers, for committing team members when needed

·         Project Team Members, for committing to their estimates, schedules and deliverables

·         Vendors, for committing more than just the terms of the contract or SOW, but to committing their organization’s reputation to our project success

Commitments are universally conditional (implicitly if not explicitly).  You have money as long as market conditions are the same and you maintain the ROI;  you have political protection as long as it in your Owner’s best interest to provide it;  you have resources and team members as long as the priority is the same and project schedule is consistent.

Because commitments are conditional, they are revocable.  Therefore, the savvy project manager will track all commitments made to and for the project and regularly reassess their reliability.  This is especially important when the project deviates from plan.  Which is why this is probably the highest priority for a project manager taking on a troubled or recovery project.  After all, the commitments are not just made to the project – they are made to the Project Manager.  And when these key stakeholders lose confidence in the PM’s ability to deliver, those commitments will dry up.

Have you taken a project commitment for granted that came back to cost you?  What did you learn?

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 – Review Risks & Mitigation Actions

“Jack, we’ve allocated five days in the plan for you to review each of the major deliverables,” Alice, the Sr Project Manager, explained to the Executive VP (HR), during the schedule review.  “If you can complete those reviews and provide signoff within three days, we have the opportunity to knock two weeks off the schedule.  However, if you take longer, that will push out the Go Live date.”

With this post, we reach the midpoint of The Project Manager’s Cycle where this action and the next few actions are deceptively easy to describe, but are considerably more complex to practice.  As a reminder, this series describes the Monitor and Control activities that the project manager repeats each project reporting cycle.

Project Risk Management is, of course, a process documented in A Guide to the Project Management Body of Knowledge (PMBoK) and includes the Monitor and Control Risks activity.  The activity I’m describing in this post is similar to the PMBoK equivalent.  At its simplest, this activity assumes risk identific-ation, quantific-ation, prioritize-ation, and mitigatin-ation have been done and all you do is “process” the risk mitigations assigned to you on the risk register and follow up with others to make sure they are “processing” the risk mitigations assigned to them.

But as someone I admire would say, that’s not “the way of the project manager.”  It’s certainly not all that is required for a best practice.  For example, as you review the risk mitigation actions assigned to you and you get others to review the actions assigned to them, you naturally reassess the risk itself and the risk response;  if anything has changed (assumptions, probability, or impact, for example), then you transition into risk analysis or risk response planning.  Further, processing the risk response actions works best as a team exercise, and a superior project manager will involve all appropriate stakeholders in the activity.

If risk response is required, take appropriate action.  For a seasoned project manager, this means delegating any product work.  Also follow up with everyone else who has a risk response action assigned to them.  Verify their action plan, determine status and issues affecting their risk response, and gently nudge them if necessary.

 If there is an effect on the project, then consider use of contingency reserves (risk buffers), escalation, or project change management.

Have I left anything out?  What else is in your cycle of weekly activities for reviewing risks and risk responses?

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?

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?