Practical Project Management

Developing the Project Plan

The Project Plan is the document used to manage project execution. It defines the project ‘What, Why, Who, When, Where, and How’. It is a text document (not to be confused with a Microsoft Project Plan) which states how the project intends to achieve its objectives. It helps other internal and external organizations understand what they need to do and when in support of the project.

Although the project manager has primary responsibility for producing the Project Plan, it should be developed as a partnership between the business and technology organizations.
A well-drafted Project Plan would include the following sections.

This section details the background and purpose of the document, its structure, the intended audience, and the reader’s obligations. One of the obligations should be to require formal approval from project stakeholders and that should be directly stated.

The Project Plan will be distributed to a wider audience than may have participated in the Project Charter and stakeholder analysis exercises. For this reason, incorporate the completed Project Charter in its entirety in this section. This gives project newcomers a brief, comprehensive overview of the project and sets the stage for the rest of the Project Plan.

This section uses a combination of significant events and the list of key deliverables developed in the Project Charter and sets forth projected beginning and ending dates for each. This information sets expectations as to when components of the project work are to be started and completed. At this early stage of the project, these may merely be best estimates based on the preliminary Work Breakdown Structure (see 11.0 WBS).

This section describes the project organization and how the project will interact with the day-to-day organization. Every organization is unique in the way it organizes projects, and this section will reflect those particulars. At a minimum, one should provide specific role and responsibility information for the project sponsor, the project manager, the project core team, any management oversight or steering committees, and required business and technical resources. List each resource role, the responsibilities of the role, the skills required, and the projected start date. A project organization chart could also be included.

Change is inevitable. Change can hurt the project. The Scope Management and Change Control section documents how the project will manage change. It is critical to identify the project’s process for submitting, logging, approving, and adopting change requests. By defining this process early, the same rules are communicated to all project participants.

Stakeholders provided feedback regarding project quality during the stakeholder analysis. The core team should be able to come up with other ideas. Generally, quality can be defined for an end deliverable, such as the software product, or it can be applied to a process. From a deliverable perspective, quality can be measured in several ways; developing reusable code, specifying throughput performance, or requiring the software to conform to organizational standards. As for process quality, it can be defined as how the project will conduct a given process so as to produce quality results.

This section articulates the project’s early understanding of risk. The project size and complexity will be the main drivers of this activity. The objective at this stage is to identify the threats to ‘avoid’ by formally building tasks into the project execution processes to eliminate the probability of the risk occurring.

To promote project visibility throughout its life cycle, it is necessary to communicate, communicate, and then communicate some more. The Communication Plan documents the information the project will capture and disseminate about project activities. Depending on the practices within the organization, some of it may be pre-defined, yet other forms may be dictated by the wishes of the stakeholders. Give the stakeholders what they want the way they want it. This simple action will elicit their support for the duration of the project. The Communication Plan should also include project document standards and information about the online project document repository location.

This matrix is a visual representation of the information collected and disseminated as documented in the Communication Plan. It is a simple tool to develop, easy to read, and it conveys a significant amount of information. The information presented is the stakeholders, the communication vehicles, the frequency of the distribution, and the media type of the distributed information.

10.0 Deliverables / Responsibility Matrix.

This matrix has the same format as the Communication Matrix, but is focused solely on deliverables. The purpose of this matrix is to document for each deliverable the project stakeholder or participant responsible for creating the deliverable, actively supporting the creation, reviewing it, and approving it.
Key:
P = Primary creator
A = Approver of outcome
R = Reviewer of outcome
S = Support of del. creation

Even if it is a preliminary draft, include the WBS in the Project Plan. The more information presented, the better stakeholders will understand the impact to their respective areas. Identify assigned resources to the extent possible. Use the WBS to populate the Milestone start and end dates in section 3.0.

Finalizing the Project Plan

Depending on the number of project participants and stakeholders, it may require several reviews to cover the entire document with everyone. During these reviews, listen carefully to the feedback and negotiate appropriate changes to the document.
Upon completion of the reviews, update the document identifying the revisions, and re-distribute the Project Plan for approval.
All stakeholders should approve the Project Plan in writing.
Post the signatures in the project repository. It is now a matter of executing the plan.
I carry the Project Plan with me and refer to it often throughout the project. I use it to keep participants focused on the agreed upon project mission, objectives, and processes.

2004 © Douglas Arnstein, Absolute Consulting Group, Inc. All rights reserved.

About the author:

Douglas Arnstein, PMP,
is the President of Absolute Consulting Group, a Management consulting firm.
He has over 25 years of professional experience encompassing process improvement initiatives, organizational management, project management, project risk management, systems design and development, and professional development seminars design and development.
Mr. Arnstein has a B.S. in Human Relations and Organizational Behavior from the University of San Francisco.
He is a member of Project Management Institute, the Commonwealth Club of California, and holds a Passport membership with the National Speakers Association Northern California Chapter.
Mr. Arnstein has spoken at PMI national and local chapter Symposia from 2000-2003, the Association of Information Technology Professionals Region 5 conference in 2002, and the Banker’s Association of Foreign Trade conference in 1997.

Douglas Arnstein is a consultant, speaker, and trainer whose compelling motivation is helping organizations develop their project management capabilities and improve their performance through effective use of their information systems.
Mr. Arnstein can be reached at
415-291-9252 (USA)
Email
Absolute Consulting Group, Inc.
absolute-consulting.com

Comments (0)

Name

Comment

smaller | bigger

Add Comment