Preparation Workbook

Preparation Workbook

for

PROJECT MANAGEMENT PLAN
(PMP)

Revision: 1.1

Work Book for Preparation of the Project Management Plan1

Revision History

About This Document – Preparing the Project Management plan

Project Oversight Process Memorandum – DoIT, July 2007

Concepts behind project management planning

What is a project?

What is Project Management?

Project management Questions

Unique Product, Service or Result

Who is doing What for Whom?

How are we doing?

How well organized are we

Project Management Plan

Starting with the Title Page

The Title

The Executive Sponsor and Business owner

The Project Manager

What is the Original Plan Date and why the Revision Date and Revision number?

The importance of Revision History

1.0 Project Overview

1.1 Executive Summary- rationale for the Project

1.2 funding and sources

1.3 constraints

1.4 dependencies

1.5 ASSUMPTIONS

1.6 Initial Project RisksIdentified

2.0 Project Authority and Organizational Structure

2.1 Stakeholders

2.2 Project Governance Structure

2.2.1 Describe the organizational structure – Org Chart

2.2.2 Describe the role and members of the project steering committee

2.2.1 Organizational Boundaries, interfaces and responsibilities

2.3 Executive Reporting

3.0 Scope

3.1 Project Objectives

3.1.1 Business Objectives

3.1.2 Technical Objectives

3.2 Project exclusions

3.3 Critical Success Factors

4.0 Project Deliverables and methodology

4.1 Project Management Life Cycle

4.1.1 Project Management Deliverables

4.1.2 Deliverable Approval Authority Designations

4.1.3 Deliverable Acceptance Procedure

4.2 PRODUCT LIFE CYCLE

4.2.1 Technical Strategy

4.2.2 Product and Product Development Deliverables

4.2.3 Deliverable Approval Authority Designations

4.2.4 Deliverable Acceptance Procedure

5.0 Project Work

5.1 Work Breakdown Structure (WBS)

5.2 Schedule allocation -Project Timeline

5.3 Project Budget

5.4 Project Team

5.4.1 Project Team Organizational Structure

5.4.2 Project Team Roles and Responsibilities

5.5 STAFF PLANNING AND Resource ACQUISITION

5.5.1 Project Staff

5.5.2 Non-Personnel resources

5.6 PROJECT LOGISTICS

5.6.1 Project Team Training

6.0 Project Management and Controls

6.1 RISK AND Issue Management

6.1.1 Risk Management Strategy

6.1.2 Project Risk Identification

6.1.3 Project Risk Mitigation Approach

6.1.4 Risk Reporting and Escalation Strategy

6.1.5 Project Risk Tracking Approach

6.1.6 ISSUE MANAGEMENT

6.2 INDEPENDENT Verification And Validation - Iv&V

6.3 Scope Management Plan

6.3.1 CHANGE CONTROL

6.4 Project Budget Management

6.4.1 Budget Tracking

6.5 Communication Plan

6.5.1 Communication Matrix

6.5.2 Status Meetings

6.5.3 Project Status Reports

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)

6.6.1 Baselines

6.6.2 Metrics Library

6.7 QUALITY OBJECTIVES AND CONTROL

6.7.1 Quality Standards

6.7.2 Project and Product Review and Assessments

6.7.3 Agency/Customer Satisfaction

SSTANDARDS

6.7.4 Product Deliverable Acceptance Process

6.8 CONFIGURATION MANAGEMENT

6.8.1 Version Control

6.8.2 Project Repository (Project Library)

6.9 PROCUREMENT MANAGEMENT PLAN

7. 0 Project Close

7.1 Administrative Close

7.2 Contract Close

AttachmentS

Attachment A Acronyms, abbreviations and definitions

Definitions

Revision History

Revision Number / Date / Comment
1.0 / July 27th, 2007 / DoIT Project Management Office Revision
2.0
2.1
2.2

About This Document – Preparing the Project Management plan

This workbook is built around helping the project manager and the project team to use the Project Management Plan in support of successful projects.

Project Oversight Process Memorandum – DoIT, July 2007

“Project management plan” is a formal document approved by the executive sponsor and the Department and developed in the plan phase used to manage project execution, control, and project close.

The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost and schedule baselines.

A project plan includes at least other plans for issue escalation, change control, communications, deliverable review and acceptance, staff acquisition, and risk management.

“Project manager” means a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department.

Project product” means the final project deliverables as defined in the project plan meeting all agreed and approved acceptance criteria.

“Product development life cycle” is a series of sequential, non-overlapping phases comprised of iterative disciplines such as requirements, analysis and design, implementation, test and deployment implemented to build a product or develop a service.

Concepts behind project management planning

What is a project?

“A project is a temporary endeavor undertaken to create a unique product, service or result” PMBOK©

What is Project Management?

Is about how we create and manage a temporaryorganization to deliver the unique product, service or result!

It is more about the temporary organization than the unique product, service or result. It is more about the interested parties, technical teams and the solution building process!

Project management Questions

What is the unique product, service or result?

What do we need to do to accomplish the goal or goals?

How do we know when we are finished?

Who is doing what for whom?

How do we know how we are doing?

How do we handle uncertainty or conflict?

Unique Product, Service or Result

Product – what are we trying to accomplish and how will we know when we are finished?

Product Development

Project Objectives-> Business Requirements -> System Requirements-> Architecture-> Solution Design-> Build-> Pilot-> Deploy

Quality of Product

Trace-ability and Quality Assurance-> Test Cases, Test Planes, Pilot and Deployment Success Criteria

Deployment of Product

Resource Requirements and staffing for new product

Deployment Plan and “Transition To Operations”

Operations and Support for product

Cost- What is the estimated cost of creating and implementing?

Who is doing What for Whom?

Roles and Responsibilities

For Whom

Project Sponsor

Project Funding Source

End User

Beneficiaries of new solution

Who

Project Team

Subject Matter Experts

Vendors

Operations

How are we doing?

Time

Calendar of tasks, task targets

Work Breakdown Structure – What needs to be done

Time estimation – how much time will be needed?

Budget

Do we have funding for project and product development, implementation and on-going support?

How much money have we spent?

Are we spending the right amount of money for specific tasks?

Quality and IV&V

Are we doing what we have set out to do?

Metrics

How many changes are we making?

How well organized are we

Are we meeting with stake holders and team members?

Have we identified possible roadblocks?

Do we document disagreements and work towards resolutions?

Do we secure formal approval of changes and requirements from stakeholders?

Do we keep stake holders informed?

Project Management Plan

Is about how we create and manage a temporaryorganization to deliver the unique product, service or result!

Starting with the Title Page

Even the title page has significant information, and assumptions. It tells us what the project calls itself, who the project benefits, who is running the project, and if the Project Charter has been revised during the project, which is okay and expected.

The Title

Does the title convey to the reader the essence of the project? Is the title of the project required by any funding considerations?

The Executive Sponsor and Business owner

Project sponsorship is about the resources required to do the project, whether they are the financial resources from state or federal funding/appropriation or from the agency’s own operating funds.

Many State of New Mexico projects list the agency Cabinet Secretary as the Executive Sponsor and a combination of the agency CIO and business process owner as the business owners of the project.

The following are some key responsibilities of project sponsorship:

Appoint an appropriately skilled project manager
Understand the project complexity
Champion the project and the team
Formally manage the project scope
Provide guidance for business strategies
Approve plans, schedules and budgets
Ensure sustained buy-in
Ensure timely availability of resources
Review project progress

Both executive sponsor and business owner are listed. While both may sit on the project steering committee, usually the business owner is more involved in the project after the project charter is established. More discussion on the steering committee will be covered under 6.2 Project Governance Plan.

The Project Manager

According to the “IT PROJECT OVERIGHT PROCESS” memorandum from Roy Soto, Secretary of the Department of Information Technology:

What is the Original Plan Date and why the Revision Date and Revision number?

As the project develops and the sponsors, project manager and team learn about the project, it is expected that the content of the project charter will change. Because the project charter is so critical to the agreements between the sponsors and the project, change management should be followed once the project charter is a signed document.

The importance of Revision History

Although not on the title page there is a revision history table in the template. This should be used as tracking device to capture the nature of changes made to the project charter document. Used in conjunction with change management, the process will facilitate the response to such questions as when did this get added to the project?

Work Book for Preparation of the Project Management Plan1

1.0 Project Overview

The Project Overview sets the stage for the details of the project and begins the “story” of the project and plan. It states the vision for the project (and larger effort, if applicable) in terms of a business need – not a solution. It answers “What is the specific answer that will move the business owner from the current state to a valuable future state?” The Project Overview describes the difference (gap) between the current state and future state in terms of the business need. The content structure order is the introduction, which provides background, the current state, the future state, and the need.

1.1 Executive Summary- rationale for the Project

In this section should be enough information to portray the situation or problem that the project results will resolve, without getting into too much detail.

Some suggestions:

The Business Problem and Opportunity section of the one page business case

Briefly explain the business problem faced by the agency and the opportunity the agency has to solve the problem through an IT solution. Briefly present essentials to relay the problem and opportunity presented including the agency’s business performance, mission, goals, objectives, and strategic plan and, if any, cross agency collaborations and impacts

The Problem Statement-Recommendation approach:

A problem statement that outlines what the existing situation is and how the business of the agency is being negatively impacted
A brief “root cause” analysis listing factors that if resolved by the project would eliminate the problem, thus benefiting the agency.
The project recommendation as the solution, stating clearly that the solution will address the root cause issues of the problem, resolving the problem and eliminating the negative impact to the agency.

The current state-future state- need approach

The current state with its issues is described
The ideal future state is described as if the solution were in place
The need provides a description of the gap and tells how the work of the project will resolve the gap between the current and future states

The “elevator speech” approach

Imagine that you are in an elevator with the executive sponsor or Cabinet Secretary and can take advantage of the few minutes to pitch the project. You have a limited amount of that person’s attention to sell the problem and the solution to the problem.

1.2 funding and sources

This question is also asked in the request for certification and release of funds document. A project is not a project unless it has actually funding. Provide the funding source(s), amount(s), any restrictions, and who the approvers are for the specific sources).

Source / Amount / Associated restrictions / Approvers

1.3 constraints

Constraints are factors that restrict the project by scope, resource, or schedule. Constraints can include parameters that force the project or work effort to fit a particular timeframe. They lead us into a certain way of doing things.Constraints limit the project management team’s options. Contractual provisions will generally be considered constraints.

Number / Description

1.4 dependencies

Literally dependencies are items required for something else to happen. My success in being able to drive for hundreds of miles is to have enough gas in my car’s gas tank, which usually means finding an open gas station, having cash or a credit card with which to pay for the gas.

The table in this section asks for a reference number, a description and whether the dependency is:

Mandatory dependencies are dependencies that are inherent to the work being done.
D- Discretionary dependencies are dependencies defined by the project management team. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.
E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement

By way of simplification, having enough gas in my car’s gas tank would be Mandatory; a specific gas station might be considered External, as our favorite corner gas station might not be open; Cash or credit card would be Discretionary.

Dependencies help the reader and the project manager/team view the playing field realistically. A back-ordered part becomes a dependency for meeting a project schedule.

Number / Description / Type M,D,E

1.5 ASSUMPTIONS

Assumptions may contain little or significant amount of risk. We can assume that members of our teams will always show up, and that the project manager will stay through the project, but people get sick, or get better offers.

Here is an exercise. List all of the people, factors, and things we take for granted around the project environment that if they were not there would negatively impact the project. We assume vendors will stay in business, and that their key technical staff will remain in place.

Assumptions are planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here and converted to formal risks.Assumptions define conditions not known but under which the project is planned, budgeted, and managed. They can include anything that supports the scope. Aim to tie risks to assumptions and place risks in risk documentation.

Number / Description

1.6 Initial Project Risks Identified

In this section identify and describe how each risk will be managed. Include the steps that will be taken to maximize activity that will result in minimizing probability and impact of each risk.

Section 6.1 Risk Management calls for an understanding of how the project will be handling risks.

Projects By their temporary nature and unique outcomes are risky –Project management reduces the impact of the threats by making them explicit and the working on reducing their impacts or by eliminating those Risks are always around. A project is not judged on how many risks are identified, but by its strategy and success at planning through the risks.

See 6.1.2 Project Risk Identification for a listing of typical project risks.

Description - / Probability / Impact
Mitigation Strategy
Contingency Plan

Risk Name – should easy reflect the challenge without detail

Description - Describe the risk’s characteristics and explain why this risk is perceived to have the potential to affect the outcome of the project.

Probability and Impact - Probability should be measured as the likelihood of that the risk will occur. Impact should be measured in terms of deviations from the schedule, effort, or costs from the schedule if risks occur.

Probability Levels: Certain, Expected, Likely, Possible, Unlikely
Impact Levels: Very High, High, Medium, Low, Very Low

Mitigation Strategy - Identify what actions can be taken in order to reduce the probability of the risk, or to reduce its impact on the project.

Contingency Plan Identify what actions will be taken when the risk materializes and threatens the scope, budget, or the schedule of the project.

[Risk 1 Name]

Description - / Probability and Impact
Mitigation Strategy
Contingency Plan

[Risk 2 Name]

Description - / Probability and Impact
Mitigation Strategy
Contingency Plan

2.0 Project Authority and Organizational Structure

The Project Organization describes the roles and responsibilities of the project team. It also identifies the other organizational groups that are part of the project and graphically depicts the hierarchical configuration of those groups. It exists to clarify interaction with the project team.