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.