Saturday, August 30, 2014

Communicating and Working the Plan

You have heard the comments from others, especially senior management. "Project management (PM) is simple blocking and tackling.” “All a PM has to do is work the plan.” Wow!! If it was that simple, the failure rate would not be over 80%, would it? What we PMs have to understand is that senior management sees PMs in the spectrum of their world. EVERYBODY reports to them. For a PM, the resources report to the project, not the PM. That is a major difference and one that has to be explained to senior management. However, I do believe that if a PM develops a plan that includes budget, scope, resource needs, and the risks, along with the schedule, then that should be part of the explanation. The major part of the explanation is communicating the plan to management and then working the plan.  

Communicating the plan, especially the risks 

The major communication device to the project sponsor and senior management is the status report. Basically, all of the completed tasks, the risks and issues, as well as the upcoming tasks must be communicated in two pages. Whether the status report is called the RAG (Red, Amber, and Green) report or the RYG (Red, Yellow, and Green) report, a picture of the project is worth a thousand words. The PM must remember the audience for this report. Yes, we like the project schedule, the budget, and especially the risks and issues lists. But the sponsor and senior management want one or, at the most, two reports. I strongly suggest that the two most important reports during the execution and monitoring phases of the project are the status report and the risk and issues list. These two reports are what the sponsor and senior management understand. The status report is direct and short. The initial portion of the status report should have a short status of the project, for example “the report is on schedule.”  

The risks and issues report is the report that the PM will be utilizing the most. This report is where the PM should spend most of the time explaining the issue(s) and the resolution of the issue(s) and the possible risks and how they will be mitigated. The PM must keep the sponsor and senior management keenly focused on the risks of the project so as to avoid surprises. I have written about the risk and issues list before on my blog on 6/23/12 What I have stated is still true today. It is the most important tool for the PM in explaining the risks to the team.  

What to do if a risk becomes an issue 

On the risks and issues list, there should be mitigation to a risk if the risk becomes an issue. During the building of the schedule by the team, the PM should have led the team to identify the risks and the probability that the risks would happen and what the impact would be. Along with that calculation there should be the resolution to the risk if it becomes an issue. That solution must be identified and communicated to the team, especially to the project sponsor, and the sponsor must have buy-in to that solution. 

I have discussed communication of the risks and issues list in a previous blog posted  

Failure is not an option

We have all heard that over 80% of projects “fail” to meet the project's original goal.  What PMs fail to do is effectively communicate the risks and then the solutions. PMs also fail to communicate the change request effectively. Once a solution is communicated to the sponsor, senior management, and the team, the PM must guide them through how the solutions may change the project’s end date and possibly add to the budget. Once the PM communicates the change to the team, the PM must document it in a change request and present it to the change review board (CRB) and senior management.  Once this is done, the project is no longer a “failure” or going RED. The project is re-scoped and re-balanced to include this necessary change with a change in the end date and resources. 
If the PM can communicate these necessary steps and options to the team, sponsor, and senior management, then the project will not fail.

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.

Saturday, August 2, 2014

Developing the Plan

During a discussion with a colleague, the topic of the project schedule vs. the project plan came up. The first thing I did was thank my colleague for correctly stating that the tool we Project Managers (PM) use--MS Project--is the schedule, NOT the plan. When I state this, I usually get a glazed look from folks who are not PMs or do not completely understand a PM's role in the overall project plan. So a discussion is necessary to answer the question, “What is a project plan?”  The first thing we must do as PMs is stop using the term “project plan” when we really mean the project schedule. Now, we can begin the discussion of what is in the project plan.
Which tools make up the plan?
The first tools the PM must receive are the Statement of Work (SOW), and included within it, the Scope Statement, or in other words, what the project is delivering. We are all familiar with the term, “What is in scope.” Well, the scope comes from the SOW. What I like to do is begin the kickoff meeting with the client by reviewing the SOW and highlighting what is in scope and most importantly, what is out of scope. The SOW that includes the scope statement is the PM's first and most likely most important tool. This is the compass that the PM must use to begin building the rest of the project.
The next tool is what we use to organize or fill the roles necessary to deliver the project. We sometimes call this the Human Resource (HR) Plan. But I like calling it the Resource Plan because we all know if this is an Information Technology (IT) project, the resources could be new hardware or software. This plan should highlight what talents and technology are needed for the project. It should also note if the resources are already “in-house” or if there is a need for a third-party consultant or a purchase of hardware and/or software. Once these resource needs are identified, then the PM can work with management to fill those needs.
The communication plan, which includes the contact list, can then be developed. Also, the PM must have at the ready tools that will become important during the project, such as the risks and issues list and the change request.
Once these tools are established, the PM can then meet with Human Resources to begin building the schedule. This is another common fallacy that must be dispelled: the schedule is not built by the PM alone. On the contrary, the schedule is built by the team. You see, it is the team that puts together the tasks of the project, links the resources to the respective tasks, and then places a schedule for that task, creating the whole MS Project schedule. When this schedule is put together, then reality sets in regarding delivering the project on-time, within scope, and within budget. It is at this time that the first change request may be written and submitted.

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.