Sunday, March 13, 2011

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?

Saturday, March 12, 2011

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?

Sunday, March 6, 2011

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?