Project Management Plan 1
Project Management Plan 1
Project Management Plan 1
TABLE OF CONTENTS
INTRODUCTION................................................................................. 1
CURRENT STATE...............................................................................1
FUTURE STATE..................................................................................1
NEED..................................................................................................1
2.0 Scope......................................................................................... 1
2.1 PROJECT JUSTIFICATION......................................................................1
2.2 PROJECT OBJECTIVES..........................................................................1
2.2.1 BUSINESS OBJECTIVES......................................................................................1
2.2.2 TECHNICAL OBJECTIVES...................................................................................1
2.3 DELIVERABLES......................................................................................1
2.3.1 PROJECT MANAGEMENT DELIVERABLES........................................................1
2.3.1.1 [DELIVERABLE 1 NAME].............................................................................1
2.3.1.2 [DELIVERABLE 2 NAME].............................................................................2
2.3.2 PRODUCT DELIVERABLES.................................................................................2
2.3.2.1 [DELIVERABLE 1 NAME].............................................................................2
2.3.2.2 [DELIVERABLE 2 NAME].............................................................................2
2.3.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS...................................2
2.3.4 DELIVERABLE ACCEPTANCE PROCEDURE.......................................................2
ii
5.3 CONSTRAINTS........................................................................................4
5.4 DEPENDENCIES......................................................................................4
5.4.1 MANDATORY DEPENDENCIES............................................................................4
5.4.2 DISCRETIONARY DEPENDENCIES......................................................................4
5.4.3 EXTERNAL DEPENDENCIES...............................................................................4
iii
7.0 Glossary.................................................................................... 8
7.1 ACRONYMS AND ABBREVIATIONS........................................................8
7.2 DEFINITIONS..........................................................................................8
iii
iv
LIST OF FIGURE
Error! No table of figures entries found.
iv
LIST OF APPENDICE
Appendix A: Work Breakdown Structure
Appendix B: Project Schedule
Appendix C: Form
Appendix D:
Appendix E:
Appendix F:
Appendix G:
Appendix H:
vi
vi
vii
REVISION HISTORY
Revision Number
1.0
Date
September 25, 2003
Comment
Original Scope1
2.0
February 5, 2004
PMO Refinement
This document is a reference from the New Mexico Office of the Chief Information Officer (OCIO)
Program Management Office (PMO) created as part of the strategic continuous process improvement
initiative. Questions or recommendations for improvement of this document may be forwarded to any
OCIO PMO member.
vii
2.0 SCOPE
2.1 PROJECT JUSTIFICATIO
2.2 PROJECT OBJECTIVES
2.2.1 BUSINESS OBJECTIVE
NUMBER
Bus. Objective 1
DESCRIPTION
DESCRIPTION
2.3 DELIVERABLES
2.3.1 PROJECT MANAGEMENT DELIVERABLE
2.3.1.1 [DELIVERABLE 1 NAME
Description-
Deliverable Acceptance Criteri Standards for Content and Forma Quality Revie -
Deliverable Acceptance Criteria Standards for Content and Format Quality Review -
Deliverable Acceptance Criteria Standards for Content and Format Quality Review -
Deliverable Acceptance Criteria Standards for Content and Format Quality Review -
DELIVERABLE
Project Management Plan (PMP)
APPROVERS (WHO
CAN APPROVE)
DATE
APPROVED
NAME
ORGANIZATION
TITLE
4.2 CUSTOMER
4.3 PROJECT TEAM
4.3.1 PROJECT TEAM ORGANIZATIONAL BREAKDOWN STRUCTUR
4.3.2 PROJECT TEAM ROLES AND RESPONSIBILITIE
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
MANAGER
5.2 ASSUMPTION2
NUMBER
DESCRIPTION
5.3 CONSTRAINT3
NUMBER
DESCRIPTION
5.4 DEPENDENCIES
5.4.1 MANDATORY DEPENDENCIES
NUMBER
DESCRIPTION
DESCRIPTION
DESCRIPTION
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.
3
Constraints are factors that will limit the project management teams options. Contractual provisions will
generally be considered constraints.
Associated Deliverables
Umbrella Tasks
Phase 1
Project
Preparation &
Planning
Project plan
Project Schedule
Phase 2
Phase 3
Phase 4
Project Closing
TOTALS
Estimated Budget
7.0 GLOSSARY
7.1 ACRONYMS AND ABBREVIATIONS
OCIO
IPP
PMI
PMBOK
PMC
PMO
PMP
QM
WBS
7.2 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]
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.
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.
10
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
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 organizations
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 ABTs
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.
11
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.
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.
12
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.)
Team
A collection of people, often drawn from diverse but related groups, assigned to perform
a well-defined 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 mastersubordinate 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.
13