P R E PA R A TION WOR K BOOK
FOR
P R O JE C T M A N A GEM E N T PLA N
(PMP)
REVISION: 1.1
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
i
REVISION HISTORY................................................................................................................................................ III
ABOUT THIS DOCUMENT – PREPARING THE PROJECT MANAGEMENT PLAN ........................................................ IV
PROJECT OVERSIGHT PROCESS MEMORANDUM – DOIT, JULY 2007 ...................................................................................... IV
CONCEPTS BEHIND PROJECT MANAGEMENT PLANNING ......................................................................................................... IV
What is a project? ............................................................................................................................................... iv
What is Project Management? ........................................................................................................................... iv
Project management Questions ........................................................................................................................... v
Unique Product, Service or Result ........................................................................................................................ v
Who is doing What for Whom? ............................................................................................................................ v
How are we doing? ............................................................................................................................................. vi
How well organized are we ................................................................................................................................. vi
Project Management Plan ................................................................................................................................. vii
STARTING WITH THE TITLE PAGE .........................................................................................................................VII
THE TITLE ................................................................................................................................................................... VII
THE EXECUTIVE SPONSOR AND BUSINESS OWNER............................................................................................................... VII
THE PROJECT MANAGER .............................................................................................................................................. VIII
WHAT IS THE ORIGINAL PLAN DATE AND WHY THE REVISION DATE AND REVISION NUMBER? .................................................... VIII
THE IMPORTANCE OF REVISION HISTORY ......................................................................................................................... VIII
1.0 PROJECT OVERVIEW ......................................................................................................................................... 1
1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT ......................................................................................................1
1.2 FUNDING AND SOURCES .............................................................................................................................................2
1.3 CONSTRAINTS ..........................................................................................................................................................2
1.4 DEPENDENCIES .........................................................................................................................................................2
1.5 ASSUMPTIONS.....................................................................................................................................................3
1.6 INITIAL PROJECT RISKS IDENTIFIED..............................................................................................................................3
2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE .............................................................................. 5
2.1 STAKEHOLDERS ........................................................................................................................................................5
2.2 PROJECT GOVERNANCE STRUCTURE .............................................................................................................................6
2.2.1 Describe the organizational structure – Org Chart .....................................................................................6
2.2.2 Describe the role and members of the project steering committee ............................................................7
2.2.1 Organizational Boundaries, interfaces and responsibilities ........................................................................7
2.3 EXECUTIVE REPORTING..............................................................................................................................................7
3.0 SCOPE .............................................................................................................................................................. 7
3.1 PROJECT OBJECTIVES ................................................................................................................................................7
3.1.1 Business Objectives .....................................................................................................................................8
3.1.2 Technical Objectives ....................................................................................................................................8
3.2 PROJECT EXCLUSIONS ................................................................................................................................................9
3.3 CRITICAL SUCCESS FACTORS .......................................................................................................................................9
4.0 PROJECT DELIVERABLES AND METHODOLOGY ................................................................................................. 9
4.1 PROJECT MANAGEMENT LIFE CYCLE ..........................................................................................................................10
4.1.1 Project Management Deliverables ............................................................................................................13
4.1.2 Deliverable Approval Authority Designations ...........................................................................................14
4.1.3 Deliverable Acceptance Procedure ............................................................................................................14
4.2 PRODUCT LIFE CYCLE .........................................................................................................................................14
I
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
ii
4.2.1 Technical Strategy .....................................................................................................................................17
4.2.2 Product and Product Development Deliverables .......................................................................................17
4.2.3 Deliverable Approval Authority Designations ...........................................................................................18
4.2.4 Deliverable Acceptance Procedure ............................................................................................................18
5.0 PROJECT WORK .............................................................................................................................................. 19
5.1 WORK BREAKDOWN STRUCTURE (WBS) ....................................................................................................................19
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE ................................................................................................................19
5.3 PROJECT BUDGET ...................................................................................................................................................20
5.4 PROJECT TEAM ......................................................................................................................................................21
5.4.1 Project Team Organizational Structure .....................................................................................................21
5.4.2 Project Team Roles and Responsibilities ...................................................................................................21
5.5 STAFF PLANNING AND RESOURCE ACQUISITION..................................................................................................21
5.5.1 Project Staff ...............................................................................................................................................21
5.5.2 Non-Personnel resources ...........................................................................................................................22
5.6 PROJECT LOGISTICS ......................................................................................................................................22
5.6.1 Project Team Training ...............................................................................................................................22
6.0 PROJECT MANAGEMENT AND CONTROLS ...................................................................................................... 23
6.1 RISK AND ISSUE MANAGEMENT ..............................................................................................................................23
6.1.1 Risk Management Strategy .......................................................................................................................23
6.1.2 Project Risk Identification ..........................................................................................................................23
6.1.3 Project Risk Mitigation Approach ..............................................................................................................27
6.1.4 Risk Reporting and Escalation Strategy.....................................................................................................27
6.1.5 Project Risk Tracking Approach .................................................................................................................28
6.1.6 ISSUE MANAGEMENT ................................................................................................................................28
6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V .............................................................................................29
6.3 SCOPE MANAGEMENT PLAN ....................................................................................................................................29
6.3.1 CHANGE CONTROL ....................................................................................................................................29
6.4 PROJECT BUDGET MANAGEMENT..............................................................................................................................31
6.4.1 Budget Tracking ........................................................................................................................................31
6.5 COMMUNICATION PLAN ..........................................................................................................................................31
6.5.1 Communication Matrix .............................................................................................................................32
6.5.2 Status Meetings ........................................................................................................................................32
6.5.3 Project Status Reports ...............................................................................................................................32
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) ......................................................................................32
6.6.1 Baselines....................................................................................................................................................33
6.6.2 Metrics Library ..........................................................................................................................................33
6.7 QUALITY OBJECTIVES AND CONTROL ................................................................................................................33
6.7.1 Quality Standards ......................................................................................................................................33
6.7.2 Project and Product Review and Assessments ..........................................................................................34
6.7.3 Agency/Customer Satisfaction ..................................................................................................................34
SSTANDARDS ...........................................................................................................................................................34
6.7.4 Product Deliverable Acceptance Process ...................................................................................................35
6.8 CONFIGURATION MANAGEMENT .....................................................................................................................36
6.8.1 Version Control ..........................................................................................................................................36
6.8.2 Project Repository (Project Library) ...........................................................................................................36
6.9 PROCUREMENT MANAGEMENT PLAN ..............................................................................................................36
7. 0 PROJECT CLOSE ............................................................................................................................................. 37
7.1 Administrative Close .....................................................................................................................................37
II
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
iii
7.2 Contract Close ..............................................................................................................................................37
ATTACHMENTS .................................................................................................................................................... 37
ATTACHMENT A ACRONYMS, ABBREVIATIONS AND DEFINITIONS............................................................................................37
DEFINITIONS ...............................................................................................................................................................38
REVISION HISTORY
REVISION NUMBER
DATE
COMMENT
1.0
July 27th, 2007
DoIT Project Management Office Revision
2.0
2.1
2.2
III
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
iv
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 temporary organization to deliver the unique
product, service or result!
IV
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
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
V
v
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
vi
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?
VI
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
vii
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 temporary organization to deliver the unique
product, service or result!
Is not a Microsoft Project© file -MS Project © is a scheduling aid
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
VII

Understand the project complexity

Champion the project and the team

Formally manage the project scope

Provide guidance for business strategies
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN

Approve plans, schedules and budgets

Ensure sustained buy-in

Ensure timely availability of resources

Review project progress
viii
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:
“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.
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?
VIII
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
1
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
PAGE 1
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN

2
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.

PAGE 2
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.
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN

3
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.
PAGE 3
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
4
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
PAGE 4
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT 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.
2.1 STAKEHOLDERS
List all of the major stakeholders in this project, and state why they have a stake. Stakeholders are
individuals and organizations that are actively involved in the project, or whose interests may be
positively or negatively affected as a result of project execution or project completion. They may also
exert influence over the project and its results.
The PMBOK© of the Project Management Institute defines project stakeholders:
“Project stakeholders are individuals and organizations that are actively involved in the
project, or whose interests may be affected as a result of project execution or project
completion. They also exert influence over the project’s objectives and outcomes.”
This all encompassing definition would have us think about such stakeholders as:
 Cabinet Secretaries

Agency Division directors

CIO-IT Leads

Project Manager

IT operations staff

Business process owners

System user representatives

Key project team members

Training staff
The Various stake holders should also have their stake in the project spelled out.
PAGE 5
5
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
NAME
STAKE IN PROJECT
6
ORGANIZATION
TITLE
2.2 PROJECT GOVERNANCE STRUCTURE
2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART
A key element in the project governance is the Organization chart for the project. Describe the
process that is going to be used to manage the scope of the project. Make sure to address
managing stakeholder expectations. Describe at a high-level how issues will be escalated and
resolved and how change requests will be processed.
Executive Sponsor
Business owner(s)
Project Steering Commitee
Project Manager
User
Representative
PAGE 6
Business Process
Owners
Operations Team
Application support
team
Vendor team
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
7
2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE
In many projects the business owners sit as the members of the steering committee. The role of
the steering committee is set the tone for the project, manage the project charter authorizing the
role of the project manager, manage the scope of the project in terms of cost, schedule and
quality of the project, deal with issues escalated to them, and also to accept or deny project team
recommendations especially in go-no go decision matters.
2.2.1 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES
Use this section to describe any special considerations regarding contact between the project
team, the project manager, and individuals from various organizations involved in the project:
“The key interface between the organizations is between the Project Manager from the DoIT and
the Project Managers from Contracting Vendor and between the Project Manager and the
assigned Team Leaders.. The primary methods utilized will be the Status Report/Briefing, adhoc meetings, electronic mail, and phone conversations. Interaction may occur directly between
the technical components of all teams. However, overall task direction can only come from the
Project Manager. Final decisions will be made at the Steering Committee level.”
2.3 EXECUTIVE REPORTING
Use this section to describe the method that will be used to effectively disseminate information
to the project ‘s Executive Sponsor and/or the Business Owner and other governing bodies such
as the Office of the Chief Information Officer and the Information Technology Commission.
Indicate how, when, what type of information, to whom, and how often project related
information will be conveyed. This section does not replace the need for the project manager to
develop a detail communication plan as part of the project plan.
Keep In mind here the project’s obligation: “. For all projects that require Department oversight,
the lead agency project manager shall submit an agency approved project status report on a
monthly basis to the Department.” PROJECT OVERSIGHT PROCESS memorandum
3.0 SCOPE
3.1 PROJECT OBJECTIVES
As the project progresses it must be able to answer the following question as “Yes!”:” Has the
project established the ability to verify that business requirements can be traced through
technical design, system building or software coding/ configuration and test phases to verify that
the system performs as intended and contains no unnecessary elements?”
PAGE 7
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
8
3.1.1 BUSINESS OBJECTIVES
NUMBER
DESCRIPTION
Bus. Objective 1
Business objectives are the high level business requirements of the project. The following table
comes from a requirement collection template. It suggests the ingredients of a well written
business objective.
<Enter concise description of requirement>
Description
Rationale
<Provide a brief rationale, and or business value for the requirement.>
Acceptance/Fi
t Criteria
<Provide a target that makes it possible to test if requirement was satisfied>
The typical problems with business objectives include:
 Lumping more than one objective into a business objective

Use of too many loose phrases such as more, better, improve, fix, solve
3.1.2 TECHNICAL OBJECTIVES
Technical objectives relate to the technical issues or goals the project is to accomplish. These
maybe related to acquisition of hardware, software, consulting, training, application development
and other “how’s” of the project.
NUMBER
DESCRIPTION
Tech. Objective 1
The business requirement table presented in the section above is useful here as well, with one
addition, the parent Objective/ requirement which should be one of the Business Objectives
presented.
<Enter the unique id #(s) for each requirement that this requirement supports
Parent
(This field will be empty for high level requirements e.g., business
Requirement
requirements)>
#
<Enter concise description of requirement>
Description
Rationale
<Provide a brief rationale, and or business value for the requirement.>
Source
<Name of Reqmnt. Provider>
PAGE 8
Source
Document
<filename>
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
Acceptance/Fi
t Criteria
9
<Provide a target that makes it possible to test if requirement was satisfied>
Because technical objectives should be trace-able to specific Business Objective, when there is
more than one business objective, it would be advisable to present the technical objectives in a
hierarchical manner: The following is an example of such a presentation of technical objectives.
NUMBER
DESCRIPTION
Bus. Objective 1
Reduce cost of government operations through IT
Tech. Objective 1
Identity Management and Directory Services
Tech. Objective 2
Common Business Functions and data interchange and discovery
methodology for all agencies to access and use for report creation.
Bus. Objective 2
Reduce cost of IT operations through an enterprise Model
Tech. Objective 4
Common IT service architecture and operating environment,
including Standards, SLA (Service Level Agreements) approach,
governance model and improved funding mechanism
3.2 PROJECT EXCLUSIONS
The project should list items, features, would like to haves that stakeholders might associate with
this project but that the project would not be providing.
3.3 CRITICAL SUCCESS FACTORS
Identify the critical success factors for achieving success in this project. Metric are key to
understanding the ability of the project to meet the end goals of the Executive Sponsor and the
Business Owner, as well as the ability of the project team to stay within schedule and budget.
NUMBER
DESCRIPTION
QUALITY METRICS
1
4.0 PROJECT DELIVERABLES AND METHODOLOGY
A deliverable is any measurable, tangible, verifiable outcome, result, or item that is required to
complete a project or part of a project. The term is often used more narrowly in reference to an
external deliverable (i.e. this deliverable is subject to approval by the project sponsor or
PAGE 9
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
10
customer). Analyze the project scope and objectives outlined in the Project Proposal and Charter
to develop a list of deliverables.
In its efforts to move from the high level business objectives to the desired end product/service
the project team will need to deliver specific documents or work products. The State of New
Mexico Project Management Methodology distinguishes between the project and the product.
Project Deliverables relate to how we conduct the business of the project. Product Deliverables
relate to how we define what the end result or product will be, and trace our stakeholder
requirements through to product acceptance, and trace our end product features and attributes
back to our initial requirements
4.1 PROJECT MANAGEMENT LIFE CYCLE
The project should present here a summary of its approach, and its phases:
Phase
Summary of Phase
Key Deliverables
Here is some background:
The following is a description of a Project Management Life Cycle based on the PMI (Project
Management Institute’s PMBOK©.
PAGE 10
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
Key Project Deliverables of each of these five processes are identified as including the
following:
Initiating:
Project Charter
Project Scope
Business Requirements – Business Case
Assumptions
Constraints
Authorization to proceed with planning
Planning:
Project Plan
Critical success factors
Work Break down Structures
Project Schedule
Controlling:
Performance/Status Reports
Corrective Action
Measurement Metrics
Plan Change Requests
Product Change Request
Risk Management
Issues Management
Execution:
Actual efforts
Project Deliverables completion
Closing:
Deliverable or Product Acceptance
Lessons Learned
As a companion to the five major project processes, PMI through the PMBOK has instituted
nine management focuses that will be followed in this project:
Integration Management
PAGE 11
11
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
12
The purpose of integration management is to ensure coordination of the different elements of a
project to achieve the needs and expectations of project stakeholders. It includes project plan
development, project plan execution, and integrated overall change control.
Scope Management
The purpose of scope management is to ensure the work performed in a project is necessary to
the successful completion. It includes initiation, scope planning, scope definition, scope
verification, and scope change control.
Time Management
The purpose of time management is to ensure a project completes in a timely manner. It includes
activity definition, activity sequencing, activity duration estimating, schedule development, and
schedule control.
Cost Management
The purpose of cost management is to ensure a project completes within its approved budget. It
includes resource planning, cost estimating, cost budgeting, and cost control.
Quality Management
The purpose of quality management is to ensure the products and services produced by a project
satisfy the needs for which the project was undertaken. Quality – the satisfaction of project
needs – is a measure of adherence to stated requirements combined with fitness for use. The
Quality Management Knowledge Area includes quality planning, quality assurance, and quality
control.
Human Resource Management
The purpose of human resource management is to ensure effective use of the people involved in
a project. It includes organizational planning, staff acquisition, and team development.
Communications Management
The purpose of communications management is to ensure timely and effective flow of
information for a project. It includes communication planning, information distribution,
performance reporting, and administrative closure.
Risk Management
The purpose of risk management is to ensure the identification, analysis, and appropriate
response to the risks encountered by a project. It includes risk management planning, risk
identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk
monitoring and control.
Procurement Management
The purpose of procurement management is to ensure effective acquisition of products and
services from sources external to the project’s organization. It includes procurement planning,
solicitation planning, solicitation, source selection, contract administration, and contract closeout.
PAGE 12
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
13
4.1.1 PROJECT MANAGEMENT DELIVERABLES
Project Deliverables are work products or artifacts that are driven by the project management
methodology requirements and standard project management practices regardless of the product
requirements of the project. Examples are project, phase, and iteration plans, and project
schedules. Project Deliverables must be reviewed and approved by the project’s Executive
Sponsor prior to their implementation.
Description - Deliverable description conveys the features and/or the functions that will be
included in the project product. Each deliverable is a subsidiary element of the project product
(final deliverable), each with its own separate but interdependent deliverable scope
Deliverable Acceptance Criteria - Acceptance Criteria are quantifiable measures of the success
of each deliverable (or set of deliverables). Its how the executive sponsor and the project team
know when a deliverable is acceptable and can be approved. Acceptance criteria are similar to
measures of success except they are for a specific deliverable. The criteria may include
functional and technical testing and utility verification at defined points in the process;
methodology and criteria should be published.
Standards for Content and Format - Standards for Content and Format describe the format
that the executive sponsor can expect to receive the deliverable. This section ensures that the
deliverable will be usable to meet its objective upon delivery. The tools, techniques, and
processes used to develop the deliverable must compliment the executive sponsor’s environment
and enable the executive sponsor to use the deliverable
Quality Review - Quality review provides the opportunity for peer and cross-discipline reviews
of the deliverable. This process will improve the Quality Control metrics by reducing the testing
cycle and the number of exceptions reported by Quality Control and eventually the executive
sponsor.
4.1.1.1 [Deliverable 1 Name]
Description -
Deliverable Acceptance Criteria - .
Standards for Content and Format -
Quality Review -
4.1.1.2 [Deliverable 2 Name]
Description -
PAGE 13
Deliverable Acceptance Criteria -
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
14
Standards for Content and Format Quality Review 4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
Complete the following table to identify the deliverables this project is to produce, and to name
the person or persons who have authority to approve each deliverable. Each deliverable should
be assigned a control number for tracking. The date approved column serves as a log of when
each deliverable was approved.
DELIVERABLE
NUMBER
DELIVERABLE
PRJ-DEL-001
Project Management Plan (PMP)
APPROVERS (WHO
CAN APPROVE)
DATE
APPROVED
4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE
Describe the process that this project will use for the formal acceptance of all deliverables.
Generally, a Deliverable Acceptance Form is utilized with specific timeframes allowed for
review, approval, rework, etc. Issues identified in this Deliverable Acceptance Procedure should
follow the Issues Escalation Process that is defined in a later section.
4.2 PRODUCT LIFE CYCLE
This section is intended to have the project present the product development life cycle. “During
the project management lifecycle, agencies shall select and implement a phase product
development lifecycle methodology approved by the Department.” PROJECT OVERSIGHT
PROCESS Memorandum
Phase
PAGE 14
Summary of Phase
Key Deliverables
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
15
The typical approach is one of the SDLC, solution/software development life cycle. One
example is presented here.
What is a product life cycle?
“A collection of generally sequential project phases whose name and number are
determined by the control needs of the organization or organizations involved in the
project. “ Project Management Institute’s PMBOK Guide 2000, Glossary p. 205
.
The Product Life Cycle includes identifiable and distinct phases, each of which encompasses the
critical five project management processes. Each phase has its own initiation, plan, execute and
control aspects and each will have its own close process. The close process or gate will include
project approval to enter the next phase of the project.
Where the DoIT Project Management Office has not yet published product life cycle
development templates to use, projects have used documents similar to those mentioned in this
approach. The following is a high level description of project document-deliverables per phase
Initiation
Product development Rationale
End Vision and purpose
Project Scope
Plan
Work Breakdown Schedules
Project Schedule
Business Requirements
Initial technical requirements
Initial deployment and transition to operations plan
Initial Operations and Support Plan
Define
PAGE 15
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
Analysis of the current state
Technical Requirements
Systems Specifications Requirements
Initial Training Requirements
System Architecture Document
System Use Cases where appropriate
Test Cases or system acceptance criteria
Revised deployment and transition to operations plan
Revised Operations and Support Plan
Design
Systems Design Documents
Training Curriculum
Revised deployment and transition to operations plan
Revised Operations and Support Plan
Build
Systems Design Documents applied
Training Materials ready
Revised deployment and transition to operations plan
Revised Operations and Support Plan
Pilot Acceptance Criteria
Pilot
Systems Design Documents applied
Training Materials ready
Revised deployment and transition to operations plan
Revised Operations and Support Plan
Pilot Run, Evaluated
Pilot Acceptance
Deploy
Systems Design Documents applied
Training Materials Used
Deployment and transition to operations plan
Operations and Support Plan
Close
PAGE 16
16
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
17
Systems Acceptance by Operations
4.2.1 TECHNICAL STRATEGY
Discuss the key technical strategies for achieving success in this project. Among these might be:

Build-reuse-buy approach

Commercial Off The Shelf –COTS- criteria development

Hardware-Operating System choices

New Mexico Enterprise IT Standards or exceptions or requests for new standards

Hosting location with justification

Outsourcing with justification

Adoption of new technologies
4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES
Product Deliverables are work products or artifacts that are driven by the product management
methodology requirements and standard project management practices regardless of the product
requirements of the project. Examples are project, phase, and iteration plans, and project
schedules. Product Deliverables must be reviewed and approved by the project’s Executive
Sponsor prior to their implementation.
Description - Deliverable description conveys the features and/or the functions that will be
included in the project product. Each deliverable is a subsidiary element of the project product
(final deliverable), each with its own separate but interdependent deliverable scope
Deliverable Acceptance Criteria - Acceptance Criteria are quantifiable measures of the success
of each deliverable (or set of deliverables). Its how the executive sponsor and the project team
know when a deliverable is acceptable and can be approved. Acceptance criteria are similar to
measures of success except they are for a specific deliverable. The criteria may include
functional and technical testing and utility verification at defined points in the process;
methodology and criteria should be published.
Standards for Content and Format - Standards for Content and Format describe the format
that the executive sponsor can expect to receive the deliverable. This section ensures that the
deliverable will be usable to meet its objective upon delivery. The tools, techniques, and
processes used to develop the deliverable must compliment the executive sponsor’s environment
and enable the executive sponsor to use the deliverable
Quality Review - Quality review provides the opportunity for peer and cross-discipline reviews
of the deliverable. This process will improve the Quality Control metrics by reducing the testing
PAGE 17
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
18
cycle and the number of exceptions reported by Quality Control and eventually the executive
sponsor.
4.2.2.1 [Deliverable 1 Name]
Description -
Deliverable Acceptance Criteria - .
Standards for Content and Format Quality Review - .
4.2.2.2 [Deliverable 2 Name]
Description -
Deliverable Acceptance Criteria Standards for Content and Format Quality Review -
4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
Complete the following table to identify the deliverables this project is to produce, and to name
the person or persons who have authority to approve each deliverable. Each deliverable should
be assigned a control number for tracking. The date approved column serves as a log of when
each deliverable was approved.
DELIVERABLE
NUMBER
DELIVERABLE
PRJ-DEL-001
Project Management Plan (PMP)
APPROVERS (WHO
CAN APPROVE)
DATE
APPROVED
4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE
Describe the process that this project will use for the formal acceptance of all deliverables.
Generally, a Deliverable Acceptance Form is utilized with specific timeframes allowed for
review, approval, rework, etc. Issues identified in this Deliverable Acceptance Procedure should
follow the Issues Escalation Process that is defined in a later section.
PAGE 18
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
19
5.0 PROJECT WORK
5.1 WORK BREAKDOWN STRUCTURE (WBS)
A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total
work scope of the project. Each descending level represents an increasingly detailed definition
of the project work. Include at least the highest level grouping for the project in this section
Describe the work activities that comprise the work breakdown structure (WBS) or the work
packages within the WBS. Identify the WBS element or other work package identifier and
provide a general description of the tasks or activities, the definition or objectives, and the
milestones and deliverables of each work package.
Identifier
Work Package
Description
Definition/Objective
Milestone/Deliverable
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE
The project timeline is a high-level view of project activities with a focus on project milestones.
The project timeline does not replace the need for a detailed project schedule and it is to
highlight key events such as deliverable due dates and when go/no-go decisions are made.
The table below should provide a high level view of the project time line, or a summary-level
Gantt chart can be used to meet the timeline requirement.
Please provide a more detailed project schedule as an attachment to this plan
Identifie Task/Activity Resource
r
Name
Name
PAGE 19
Milestone Effort/
Start Finish Dependent
(Y/N)
Duration
Task
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
20
5.3 PROJECT BUDGET
Costs estimates are the costs applied to an activity in a project by assigning resources with
associated rates or fees. Resources can include equipment, material, technology, processing
cycles, or people. The total cost is critical and should be consistent with the proposal; include
breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an
appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or
deliverable).
Identifier
Work Package or Budget Category
Cost
Or..
Phase / Activity
Associated Deliverables
Umbrella Tasks
Phase 1
Project Preparation
& Planning
Phase 2
Phase 3
Phase 4
Project Closing
PAGE 20
Project plan
Project Schedule
Estimated
Budget
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
Phase / Activity
Associated Deliverables
21
Estimated
Budget
TOTALS
5.4 PROJECT TEAM
5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE
Insert a graphical Organization Chart here. The Organizational Structure (OS) is a hierarchical
configuration defining levels of program management and may identify all project personnel.
The OS should be simple and straightforward. Include role names and people’s names.
Consider identifying the core project team by shading their respective boxes on the chart. On
complex projects, consider using a second OS to identify core project team. The OS can also be
used for management reporting.
5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES
List the team members, their role, responsibility and functional manager. Make sure to include a
comprehensive listing including those from the organization managing the project, business
members involved to ensure business objectives are met and the vendor members that may have
a specific role.
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
AREA
5.5 STAFF PLANNING AND RESOURCE ACQUISITION
Complete the chart below identifying the project team members and details concerning their
project commitment. Type should be State, Contract, Customer (Business Owner), or Vendor.
5.5.1 PROJECT STAFF
Resource
PAGE 21
Cost
Estimate
Estimated
Hours
Availability
Skill Set
Work Product/Deliverable
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
22
5.5.2 NON-PERSONNEL RESOURCES
Use this section to list services or product (HW/SW and such) needed for project
Resource
Cost
Estimated
Work
Estimate units/hours Availability Source Product/Deliverable
5.6 PROJECT LOGISTICS
Logistics describes how the project manager, project team, the business owner/customer and any
vendor resources will physically work together. Include anything to do with moving or starting
resources. Identify a role to coordinate logistics with the business owner/customer and vendors.
Logistics includes factors, issues, notes, etc. relating to operational details (space, materials,
access, etc.) at the customer or vendor site. It can also be used to describe the need and use of a
forthcoming logistics document. Cross-reference any risk, assumption or exclusion that is
related to logistics. Training specifically related to project team members should be included
here.
5.6.1 PROJECT TEAM TRAINING
Describe training if any needed by project team members. This is not to include training for end
users, system administrators or business owners; those should be handled within a training
document or part of the transition to operations planning.
Resource
PAGE 22
Cost
Estimate
Estimated
Hours
Availability
Skill Set
Work Product/Deliverable
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
23
6.0 PROJECT MANAGEMENT AND CONTROLS
6.1 RISK AND ISSUE MANAGEMENT
PMBOK©:
Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on a
project’s objectives.”
Issue: “A point or matter in question or dispute, or a point or matter that is not settled and is
under discussion or over which there are opposing views or disagreements.”
Both Risks and Issues can significant impact a project’s success, and both should be handled in
similar ways.
•
Project Management IS Risk Mitigation. Is about how we create and manage a
temporary organization to deliver the unique product, service or result!
•
By providing structure to the temporary organization and the solution
development/deployment process we reduce the risk of counterproductive Chaos.
•
By communicating with stakeholders we keep them in the loop, and often involve them
in risk mitigation or lessening its impact
•
By acknowledging that there is risk, we can structure ways of avoiding or effectively
dealing with specific risk.
6.1.1 RISK MANAGEMENT STRATEGY
Provide a detailed explanation on the strategy for how risks are identified, analyzed/ quantified,
mitigated, reported, escalated and tracked. Include the use of tools such as project management
software, forms, and templates. A separate risk management plan may also be developed if
needed for the project and included as an Appendix to this document. If that is the case, a high
level summary of this plan needs to be included here with the specific reference.
6.1.2 PROJECT RISK IDENTIFICATION
•
Organizational
– Project Organization
•
Resource
– Staff, Skills, Etc
•
External Risks
– Vendors, suppliers
•
Planning Risks
– Uncertainty, Complexity
•
Technical Risks
PAGE 23
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
– Requirements, Reliability
Organizational Risks
•
Poor Initiation
•
Sponsor Changes
•
Priorities Change
•
Unrealistic Deadline
•
Funding
•
Lack of internal stakeholder support
•
Delayed Approval/Decisions
•
Lack of Technical or business direction
•
Project Manager Experience or inexperience
•
No organization history
•
No established project templates or processes
•
No organizational understanding of RISK
Resource Risks
•
Lack of Resources
•
Staff Availability
•
Staff Inexperience
•
Holiday and Vacation
•
Personal or Family Illness
•
Retirement or resignations
•
Overbooking
•
Personalities
•
Ineffective training
•
Contractor or Consultant
PAGE 24
24
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
•
Team Morale
•
Ineffective Communication
External Risks
•
Vendor/Supplier
– Timing
– Quality
– Lack of incentive or penalty
•
Misunderstood requirements
•
Statement of Work incomplete
•
Too Many External vendors or suppliers
•
Weather Issues
•
Key Staff issues or sickness
•
Dependencies on other projects
•
Purchasing or hiring
Planning Risks
•
Lack of Planning
•
Lack of Anticipation
•
Poor Estimation
•
Lack of stakeholder involvement
•
Lack of end customer involvement
•
Poor Project Definition
•
Unrealistic expectations
•
Number of implementation sites
•
Training process
•
Government or Regulatory Changes
PAGE 25
25
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
•
Poor Communications
•
Poorly Run or attended meetings
•
No record keeping
Technical Risks
•
Incomplete Requirements
•
Scope Creep
•
No or Poor Change Management Process
•
Complex or Overly Complex Designs
•
Technology Readiness
•
Technical Dependencies
•
No Test Environment
•
Cutting Edge Components
•
Inadequate Documentation
•
Vendor Technical Support
•
Code or Patch directly to Production Environment
•
No Pilot
PAGE 26
26
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
27
6.1.3 PROJECT RISK MITIGATION APPROACH
6.1.4 RISK REPORTING AND ESCALATION STRATEGY
The DoIT Risk and Issue Log Template uses a calculation based on the following values:

Probability Levels: Certain, Expected, Likely, Possible, Unlikely

Impact Levels: Very High, High, Medium, Low, Very Low
The following table suggests the values at which the risks should be tracked, reported and
escalated:
Minimum risk - Acceptable
Some risks - Monitor at PM/Team Level
High risks - Active monitoring with ongoing Contingency/Mitigation activity
Show stoppers - Active participation with steering committee to mitigate
This is an example of the calculation that indicates a serious risk that needs to be escalated to the
Steering Committee.
Number
1
PAGE 27
Risk
Example
Probability
Certain
Impact
High
Rating
0.7125
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
28
6.1.5 PROJECT RISK TRACKING APPROACH
In the DoIT Risk and Issue Template the risk log provides a risk log that not only calculates the
risk level, but also provides space for inputting the contingency and mitigation plan summary
highlights.
Number
Risk
Probability
Impact
Rating
1
Example
Certain
High
0.7125
Contingency Mitigation
Plan
Plan
6.1.6 ISSUE MANAGEMENT
For either type of issue, projects should consider using the DoIT Risk and Issue Log template as
is presented below:
Issue Log:
Issue
No.
1
Person
Responsible
Project
Manager
Issue
Example
Date Opened Month/Day/year
03/15/07
Issue Form
Issue
No.
(From
Issue
Log)
1
Responsible
Party (From
Issue Log)
Project Manager
Level
(High,
Medium,
Low)
Class
(Impact
Area)
Date
Opened
(From
Issue
Log)
03/15/07
Date
Closed
Originator
Status
(From
issue
Log)
Open
Issue (From Issue Log)
Example
Consequence(s)
If not resolved this issue could delay the project by 30 days, resulting in a fine for non-compliance
Resolution
Hiring a contractor could resolve this delay at a cost less than the fine for non-compliance
PAGE 28
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
29
6.1.6.1 Internal Issue Escalation and Resolution Process
This internal process is provided for issues that involve project resources, processes, procedures,
or methodology that should be resolved within the Division that is responsible for managing the
project without affecting the overall project schedule, cost, or quality. This process should be
used for improving project processes as the project is executed and where the implementation of
such improvements should not be postponed to Lessons Learned during Project Close.
6.1.6.2 External Issue Escalation and Resolution Process
The external process is provided for issues that involve project resources, processes, procedures,
or methodology that cannot be resolved within the Division that is responsible for managing the
project without affecting the overall project schedule, cost, or quality.
6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V
Independent Verification and Validation (IV&V) means the process of evaluating a system to
determine compliance with specified requirements and the process of determining whether the
products of a given development phase fulfill the requirements established during the previous
stage, both of which are performed by an organization independent of the development
organization. Describe the process that will be employed to meet IV&V requirements.
See Project Charter for Certification Workbook for some details.
6.3 SCOPE MANAGEMENT PLAN
Describe the process that is going to be used to manage the scope of the project. Make sure to
address managing stakeholder expectations.
6.3.1 CHANGE CONTROL
6.3.1.1 Change Control Process
Change Control establishes how change will be managed, including capturing, tracking,
communicating, and resolving change. Due to much ambiguity regarding change, it is vital that
we document and discuss the change process with the executive sponsor.
PAGE 29
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
30
<Project Name > Change Control Process
Process Flow between Core Team and Policy Stakeholders
Core Team
Project
Issue
Identified
Expanding
Scope, Cost, or
Timeline
NO
Project
Issue
Identified
Invoke
Change
Control
Process
Prioritize
Alternative
Solutions
Analyze
alternatives
and SOE
Document the
Request
Respond within
5 business days
YES
Change Control
Board
Deliver Change
Request Response
Document the
Request
Yes
Need more
Information?
CCB Analyzes
Solution
Alternatives and
Project Effect
(Scope, Cost,
Timeline)
Change involves
Process or
Procedure
Choices?
NO
Document the
Decision
YES
6.3.1.2 Change Control Board (CCB)
Insert a graphic or textual description identifying the Change Control Board (or function) for this
project. The CCB may be an individual or group of individuals authorized to approve changes to
the project plan.
A project might want to formalize Change Management through a form such as shown below:
PROJECT CHANGE REQUEST
PROJECT:
AGENCY:
DATE:
PROJECT
MANAGER:
PROJECT #:
AGENCY AND PROJECT INFORMATION:
REQUESTED BY:
DATE:
AUTHORIZED BY:
DATE:
DESCRIPTION:
PAGE 30
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
IMPACT:
31
Technical
Schedule
Cost
Is
Is NOT
Within Scope.
Accepted
Denied
On Hold
Other
ACTION PLAN:
MARK ONE:
THIS CHANGE:
THIS CHANGE IS:
6.4 PROJECT BUDGET MANAGEMENT
Costs estimates are the costs applied to an activity in a project by assigning resources with
associated rates or fees. Resources can include equipment, material, technology, processing
cycles, or people. The total cost is critical and should be consistent with the proposal; include
breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an
appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or
deliverable).
6.4.1 BUDGET TRACKING
6.5 COMMUNICATION PLAN
Communication planning involves determining the information and communication needs of the
stakeholders, executive sponsors, project team and others as needed. The communication plan
needs to address who needs what information, when they will need it, how it will be given to
them, and by whom. The complexity of the project may require a separate communication plan;
however a high level summary of that plan will need to be included here and a reference made to
the appropriate Appendix.
PAGE 31
Delayed
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
32
6.5.1 COMMUNICATION MATRIX
6.5.2 STATUS MEETINGS
6.5.3 PROJECT STATUS REPORTS
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)
The Project Manager and Executive Sponsor define the project metrics that will be used to
control the project. Each project will need to have an established metrics program. Metrics are
collected for measuring the progress of a project against its planned budget, schedule, resource
usage, and error rates, and of establishing a historical database, which will aid in planning and
forecasting future projects. At a minimum metrics must be established for time (schedule), cost
(budget) and quality.
Project Area
Category
Measure
Example used by another state:
Common Project Issue Area
Category
Measure
Schedule and Progress
Milestone Performance
• Milestone Dates
Work Unit Progress
• Component Status •
Requirement Status • Test Case
Status • Critical Paths Tested •
Problem Report Status • Reviews
Completed • Change Request
Status
Incremental Capability
• Build Content – Component •
Build Content – Function
Resources and Cost
Personnel
• Effort • Staff Experience • Staff
Turnover
Financial Performance
Availability
Growth and Stability
PAGE 32
Product Size and Stability
• Earned Value • Cost
• Resource Availability Dates •
Resource Utilization
• Lines of Code • Components •
Database Size
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
Functional Size and Stability
Product Quality
• Requirements • Function Points
• Change Request Workload
Defects
• Problem Reports • Defect
Density
Complexity
• Cyclomatic Complexity
Rework
Development Performance
33
• Rework Size • Rework Effort
Process Maturity
• Capability Maturity Model Level
Productivity
• Product Size/Effort Ratio •
Functional Size/Effort Ratio
6.6.1 BASELINES
6.6.2 METRICS LIBRARY
6.7 QUALITY OBJECTIVES AND CONTROL
Quality Management includes the processes required to ensure that the project will satisfy the
needs for which it was undertaken. It includes all activities of the overall management function
that determine the quality policy, objectives, quality assurance, quality control, and quality
improvement, within the quality system. If a separate Quality Plan is used, include a high level
summary in this document and refer to the appropriate appendix.
6.7.1 QUALITY STANDARDS
Describe the agency, industry or regulatory project performance standards that will be followed and
assessed by the project. These quality standards will be used to assess whether the quality objectives
were achieved.
Identify each of the project quality standards that are directly related to the project and not to the
performance of the actual product and/or service. For each quality standard, identify the tracking tool or
measure such as number of project reviews or Project Status.
From another state’s planning process
No.
PAGE 33
Quality Standard
Tracking Tool or Measure
1
Project phase is completed by the established finish date.
• Project Schedule
• Project Status
2
Project is completed within budget.
• Project Charter
• Project Status
3
Quarterly project reviews show contractors deliver requirements
specified in the contract by due dates or pay penalties.
• Vendor Contract
• Final Customer
Acceptance
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
34
4
Project issues are resolved and documented within 10 calendar days of
identification or extensions are justified.
• Issues Tracking
5
Project will be completed based on the original project scope and
approved scope changes.
• Project Charter
• Project Plan
• Control Change
Request
•
•
•
6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS
Review Type
Quality Standard
Tools
Reviewer
Reports
Requirements
Plans
Milestones
Testing
6.7.3 AGENCY/CUSTOMER SATISFACTION
The project manager should assess the on-going sense of the customer agency about how they
feel the project is going, and how team members are acting on the project. This feedback would
be helpful to the success of the project and the professional growth of the project team members.
Examples:
Areas of feedback
When
How Often
Agency awareness
Quality of communications
Manages project tasks
Productive Meetings
.
An example used by some State of New Mexico agencies:
SSTANDARDS
PAGE 34
Not
Applicable
Strongly
Disagree
Disagree
Somewhat
Agree
0
1
2
3
Agree
Strongly
Agree
4
5
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
35
The level of business or agency
knowledge of [project’s name] meets your
expectations.
[Project’s name] performs in a
professional and cooperative manner.
The level of communications by
[project’s name], both written and oral,
meet your expectations.
[Project’s name] project team works well
with you and your staff.
[Project’s name] project management
team is accessible when you need them.
[Project’s name] provides adequate
information and training resulting in
effective knowledge transfer.
[Project’s name] completes project tasks
within the agreed upon schedule.
The level of technical or business
expertise of [project’s name] meets your
expectations.
You are receiving full value from the
[project’s name] project management
team.
The overall service provided by [project’s
name] is fully meeting your expectations.
6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS
How the client takes procession of the product. Delivery of media; manuals; contracts; licenses;
services agreements; configuration settings; status of patches to COTS products; in-house or
vendor developed code; test cases, routines, and scripts; and other items required to operate the
product.
PAGE 35
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
Deliverable
Final Approval Process
36
Customer Acceptance Criteria
6.8 CONFIGURATION MANAGEMENT
Configuration Management determines how project information (files, reports, designs, memos,
documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control,
etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team
awareness are critical.
6.8.1 VERSION CONTROL
Documents should be tracked for version control, on the title page, and using a revision history
table such as used for this PMP. Document file names should have project name agency revision
number reflected. Best practice involves change management for documents, and a numbering
scheme such as 1.0, 2.0, 3.0 to reflect a project’s phases and toll gates or approval processes per
phase.
6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)
“Provide to the Department all project management and product deliverables. Deliverables shall include
but not limited to the project plan, project schedule, initial and periodic risk assessments, quality
strategies and plan, periodic project reports, requirements and design documents for entire project. The
lead agency must make available all deliverables in a repository with open access for the Department to
review” PROJECT OVERSIGHT PROCESS Memorandum.
6.9 PROCUREMENT MANAGEMENT PLAN
Projects often have some element of procurement, i.e. the requirement to purchase goods and/or
services from outside the organization. The procedures to be used to handle these procurements
should be included here. Activities such as a make-or-buy analysis; writing requirements;
solicitation planning, evaluation and selection; inspection and acceptance; contract closeout
should all be included.
State of New Mexico RFP, IT Contract and other procurement processes should be followed by
all state agencies’’ IT Projects.
PAGE 36
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
37
7. 0 PROJECT CLOSE
Project Close will always consist of administrative project activities and possibly contractual
project activities and an external vendor is employed. Completing both sets of activities is a
mandatory step in the project life cycle. Administrative activities complete the internal needs for
the Agency/Unit that is responsible for managing the project, such as lessons learned, recording
the last hours against the project, and providing transition for the staff to other assignments.
Contractual activities meet the contractual needs, such as executing a procurement audit and
formal acceptance of the project work products.
7.1 ADMINISTRATIVE CLOSE
Administrative Close occurs at both the end of phase and end of project. This closure consists of
verification that objectives and deliverables were met. Acceptance is formalized and phase
activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in
accordance with the WBS and should not be delayed to project end. At that point, the burden of
closing is too great and audits inaccurate. The specific project close activities for a given project
are contingent on the project’s complexity and size. Project managers should work with the
project’s project management consultant to tailor Project Close procedures to compliment the
project’s objectives
7.2 CONTRACT CLOSE
Contract close is similar to administrative close in that it involves product and process
verification for contract close.
Projects that have been certified need to complete the required DoIT project closure
certification processes.
ATTACHMENTS
Attachments are included for additional information, but are not formally considered part of
the Project Plan for approvals and change management purposes. Examples

Acronyms, abbreviations and definitions

Technical glossary of IT terms

Project Work breakdown schedule

Project timeline
ATTACHMENT A ACRONYMS, ABBREVIATIONS AND DEFINITIONS
PMI
Project Management Institute.
PMBOK
Project Management Body of Knowledge
PMO
Program Management Office
PAGE 37
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
PMP
Project Management Plan
WBS
Work Breakdown Structure
38
DEFINITIONS
Acceptance Criteria
The criteria that a system or component must satisfy in order to be accepted by a user, customer,
or other authorized entity. [IEEE-STD-610]
Acceptance Testing
Formal testing conducted to determine whether or not a system satisfies its acceptance criteria
and to enable the customer to determine whether or not to accept the system. [IEE-STD-610]
Assumptions
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, or converted to
formal risks.
Baseline
A specification or product that has been formally reviewed and agreed upon that thereafter
serves as the basis for further development, and that can be changed only through formal change
control procedures. [IEEE-STD-610]
Commitment
A pact that is freely assumed, visible, and expected to be kept by all parties.
Configuration Management (CM)
A discipline applying technical and administrative direction and surveillance to identify and
document the functional and physical characteristics of a configuration item, control changes to
those characteristics, record and report change processing and implementation status, and
verify compliance with specified requirements. [IEEE-STD-610]
Configuration Management Library System
The tools and procedures to access the contents of the software baseline library.
Constraints
Factors that will (or do) limit the project management team’s options. Contract provisions will
generally be considered constraints.
Contingency Planning
The development of a management plan that identifies alternative strategies to be used to ensure
project success if specified risk events occur.
Crashing
Taking action to decrease the total duration after analyzing a number of alternatives to
determine how to get the maximum duration compression for the least cost.
PAGE 38
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
39
Critical Path
The series of activities that determines the duration of the project. The critical path usually
defined as those activities with float less than or equal to specified value often zero. It is the
longest path through the project.
Dependencies, Discretionary
Dependencies defined by the project management team. They should be used with care and
usually revolve around current Best Practices in a particular application area. They are
sometimes referred to as soft logic, preferred logic, or preferential logic. This may also
encompass particular approaches because a specific sequence of activities is preferred, but not
mandatory in the project life cycle.
Dependencies, Mandatory
Dependencies that are inherent to the work being done. In some cases, they are referred to as
hard logic.
Dependency Item
A product, action, piece of information, etc., that must be provided by one individual or group to
a second individual or group so they can perform a planned task.
Deliverable
Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete
a project or part of a project that is subject to approval by the project sponsor or customer.
Duration
The number of work periods (not including holidays or other nonworking periods) required to
complete an activity or other project element.
Duration Compression
Shortening the project schedule without reducing the project scope. Often increases the project
cost.
End User
The individual or group who will use the system for its intended operational use when it is
deployed in its environment.
Effort
The number of labor units required to complete an activity or other project element. Usually
expressed as staff hours, staff days, or staff weeks.
Fast Tracking
Compressing the project schedule by overlapping activities that would normally be done in
sequence, such as design and construction.
Float
The amount of time that an activity may be delayed from its early start without delaying the
project finished date.
PAGE 39
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
40
Formal Review
A formal meeting at which a product is presented to the end user, customer, or other interested
parties for comment and approval. It can also be a review of the management and technical
activities and of the progress of the project.
Integrated Project Plan
A plan created by the project manager reflecting all approved projects and sub-projects.
Lessons Learned
The learning gained from the process of performing the project. Lessons learned may be
identified at any point during the execution of the project.
Method
A reasonably complete set of rules and criteria that establish a precise and repeatable way of
performing a task and arriving at a desired result.
Methodology
A collection of methods, procedures, and standards that defines an integrated synthesis of
engineering approaches to the development of a product.
Milestone
A scheduled event for which some individual is accountable and that is used to measure
progress.
Non-technical Requirements
Agreements, conditions, and/or contractual terms that affect and determine the management
activities of an architectural and software project.
Performance Reporting
Collecting and disseminating performance information. This includes status reporting
measurement, and forecasting.
Procurement Planning
Determining what to procure and when.
Product Scope
The features and functions that characterize a product or service.
Project Leader (Technical)
The leader of a technical team for a specific task, who has technical responsibility and provides
technical direction to the staff working on the task.
Project Management
The application of knowledge, skills, tools, and techniques to project activities to meet the
project requirements. Project Management is also responsible for the oversight of the
development and delivery of the architecture and software project.
Program
PAGE 40
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
41
A group of related projects managed in a coordinated way. Programs include an element of
ongoing work.
Program Management Office
An organizational entity responsible for management and oversight of the organization’s
projects. As a specific reference in this document, the Office of the Chief Information Officer.
Project Manager
The role with total business responsibility for an entire project. The individual who directs,
controls, administers, and regulates a project. The project manager is the individual ultimately
responsible to the customer.
Project Charter
A document issued by senior management that formally authorizes the existence of a project. It
provides the project manager with the authority to apply organizational resources to project
activities.
Project Management Plan
A formal, approved document used to guide both project execution and project control. 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. The Project Management Plan (PMP) is a project plan.
Project Schedule
A tool used to indicate the planned dates, dependencies, and assigned resources for performing
activities and for meeting milestones. Software products such as ABT’s Workbench and
Microsoft Project are tools used to develop project schedules.
Project Scope
The work that must be done to deliver a product with the specified features and functions.
Project Sponsor
The individual that provides the primary sponsorship for an approved project. This individual
will play a key role in securing funding, negotiating for resources, facilitating resolution of
critical organizational issues, and approving key project deliverables.
Quality
The degree to which a system, component, or process meets specified requirements.
The degree to which a system, component, or process meets customer or user needs or
expectations. [IEEE-STD-610]
Quality Management
The process of monitoring specific project results to determine id they comply with relevant
standards and identifying ways to eliminate causes of product non-compliance.
Risk
Possibility of suffering loss.
PAGE 41
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
42
Risk Management
An approach to problem analysis, which weighs risk in a situation by using risk probabilities to
give a more accurate understanding of, the risks involved. Risk Management includes risk
identification, analysis, prioritization, and control.
Risk Management Plan
The collection of plans that describes the Risk Management activities to be performed on a
project.
Risk Management
Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable
threshold.
Scope Change
Any change to the project scope. A scope change almost always requires an adjustment to the
project cost or schedule.
Software Life Cycle
The period of time that begins when a software product is conceived and ends when the software
is no longer available for use. The Software Life Cycle typically includes a concept phase,
requirements phase, design phase, implementation phase, test phase, installation, and checkout
phase, operation and maintenance phase, and, sometimes, retirement phase.
Stakeholder
Individuals and organizations that are actively involved in the project, or whose interests may be
positively or negatively affected as a result of project execution or project completion. They may
also exert influence over the project and its results.
Standard
Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to
software development
Statement of Work
A description of all the work required completing a project, which is provided by the customer.
System Requirements
A condition or capability that must be met or possessed by a system component to satisfy a
condition or capability needed by a user to solve a problem. [IEEE-STD-610]
Subproject
A smaller portion of the overall project.
Task
A sequence of instructions treated as a basic unit of work. [IEEE-STD-610]
A well-defined unit of work in the software process that provides management with a visible
checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and
completion criteria (post conditions). (see activity for contrast.)
PAGE 42
WORK BOOK FOR PREPARATION OF THE PROJECT MANAGEMENT PLAN
43
Team
A collection of people, often drawn from diverse but related groups, assigned to perform a welldefined function for an organization or a project. Team members may be part-time participants
of the team and have other primary responsibilities.
Technical Requirements
Those requirements that describe what the software must do and its operational constraints.
Examples of technical requirements include functional, performance, interface, and quality
requirements.
Traceability
The degree to which a relationship can be established between two or more products of the
development process, especially products having a predecessor-successor or master-subordinate
relationship to one another. [IEEE-STD-610]
Work Breakdown Structure
A deliverable-oriented grouping of project elements that organizes and defines the total work
scope of the project. Each descending level represents an increasingly detailed definition of the
project work.
PAGE 43