Overview of this Document This document is a collection of thoughts and quick notes on the topic of creating a Project Plan. This is not a project plan, nor is this document comprehensive. I have delved deeper into the structure of a Project Plan in two other documents:

• Project Management Office Quick Reference
• Six Sigma Quick Reference

Communications Management Plan
The Project Plan is a composite drawn from the supporting project documents. One of the most important parts of a project plan is the communications management plan. At the simplest, a communications management plan can be a table or matrix of documents and responsibilities. Larger projects require a much more complex document that defines not just the "what" but the policies and procedures that govern the communication. The following table illustrates a simple communications management plan as a matrix.

Who Creates This	Who Receives This	What is it Called	When	Why	How is it Sent
Project Manager	All Stakeholders	Project Milestones	Monthly	To track progress and see accomplishments.	Web Site
Project Manager	Authors	Project Status Report	Weekly	To measure progress and check Earned Value.	Web Site
Project Manager	Project Team	Status Meeting Agenda	Ad hoc	To ensure that the weekly status meetings are productive and efficient.	Email
Project Manager	Project Team	Status Meeting Minutes	Ad hoc	To document agreements and action items.	Web Site
Responsible Contributor	Responsible Contributor	Change Notification	Ad hoc	To notify each other of status changes on specific documents.	Email
Responsible Contributor	Responsible Contributor	Formal Acceptance	Ad hoc	Notification that a document or set of documents has been created,reviewed, revised and formally accepted.	Email

Organizational Policies
The depth and breadth of the project plan will vary depending upon the complexity of the project and on the maturity of the supporting processes already established in the organization. For example, a project might be required to define rules regarding document retention within the project plan. Or, the project plan might reference an PMO (Program Management Office) policy that defines the rules for document retention on all projects. Or the project plan might reference an organizational policy that defines document retention rules for the corporation. It is more expedient and more consistent to reference defined organizational policies rather than trying to create all of that structure within the project plan.

Change and Configuration Management
If change management and configuration management are not already documented through organizational policies, then they must be defined in the Project Plan. Personally, I find the PMI definitions of these topics a bit weak. I recommend turning to the ITIL defintions, instead, after you have passed your PMP certification.

Both change and configuration management begin with a baseline to describe the agreed deliverables. Both require processes to detect attempts to change the project or product. Both require that requests to change go through a review cycle.

In my experience companies tend to adopt an extreme position regarding change management. Either the process is ignored or the process is excessive. I recommend taking a light weight approach. Most managers already have all the authorization that is required to implement many types of change. Adding more process on top of that authorization detracts from their ownership. I recommend establishing graduated levels for change authorization. Give the employees the freedom to innovate within a defined scope. Acknowledge the authority managers and project managers already have to implement change up to a certain budgetary criteria. Then document a process for changes that exceed those limits.

Organizational Chart An organizational chart graphically represents the formal structure for the project. It is helpful in expressing the idealistic organizational structure and should be included in the Project Charter and Project Plan. An example of an organizational chart is shown, below.

Responsibility Assignment Matrix
One of the most commonly used forms for a Responsibility Assignment Matrix (RAM) is an RASCI Chart. The definitions commonly used for the RASCI are:

• R  -  Responsible. The person assigned to ensure this work is completed.
• A  -  Accountable. The person in charge of the budget or resources.
• S  -  Supportive. A resource assigned to do some of the work.
• C  -  Consulted. Somone assigned to provide input and advice.
• I  -  Informed. Someone that must be fed information.