[INSERT PROJECT NAME] PROJECT MANAGEMENT PLAN (PMP) EXECUTIVE XECUTIVE S SPONSOR PONSOR – [ – [INSERT NSERT N N AME AME] BUSINESS USINESS O OWNER WNER - [ - [INSERT NSERT N N AME AME] PROJECT ROJECT M MANAGER ANAGER – [ – [INSERT NSERT N NAME AME] ORIGINAL RIGINAL P P LAN LAN D D ATE ATE : : [I [INSERT NSERT D D ATE ATE , S , S PELLED PELLED O O UT UT] REVISION EVISION D D ATE ATE : : [I [INSERT NSERT D DATE ATE , S , S PELLED PELLED O O UT UT] REVISION EVISION : : [I [INSERT NSERT N NUMBER UMBER]
Transcript
[INSERT PROJECT NAME]
PROJECT MANAGEMENT PLAN
(PMP)
EEXECUTIVEXECUTIVE S SPONSORPONSOR – [ – [IINSERTNSERT N NAMEAME]]
BBUSINESSUSINESS O OWNERWNER - [ - [IINSERTNSERT N NAMEAME]]
PPROJECTROJECT M MANAGERANAGER – [ – [IINSERTNSERT N NAMEAME]]
OORIGINALRIGINAL P PLANLAN D DATEATE: : [I[INSERTNSERT D DATEATE, S, SPELLEDPELLED O OUTUT]]
RREVISIONEVISION D DATEATE: : [I[INSERTNSERT D DATEATE, S, SPELLEDPELLED O OUTUT]]
RREVISIONEVISION: : [I[INSERTNSERT N NUMBERUMBER]]
Project Management Plan i
TABLETABLE OFOF CONTENTSCONTENTS
About This DocumentAbout This Document....................................................................................................................................viviRevision HistoryRevision History......................................................................................................................................................viivii1.01.0 Project OverviewProject Overview......................................................................................................................................11
1.11.1 IINTRODUCTIONNTRODUCTION..................................................................................................................................................................111.21.2 CCURRENTURRENT S STATETATE..............................................................................................................................................................111.31.3 FFUTUREUTURE S STATETATE..................................................................................................................................................................111.41.4 NNEEDEED....................................................................................................................................................................................................11
2.2.1 BUSINESS OBJECTIVES......................................................................................12.2.2 TECHNICAL OBJECTIVES...................................................................................1
2.4 W2.4 WORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS) (WBS)......................................................................................223.0 Overall Strategy3.0 Overall Strategy..............................................................................................................................................22
3.1 P3.1 PROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLE................................................................................................223.2 C3.2 CRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORS............................................................................................................................223.3 P3.3 PROJECTROJECT L LOGISTICSOGISTICS..........................................................................................................................................................333.4 P3.4 PROJECTROJECT P PRODUCTRODUCT L LIFEIFE C CYCLEYCLE M MODELODEL......................................................................................333.5 T3.5 TECHNICALECHNICAL S STRATEGYTRATEGY................................................................................................................................................33
4.3.1 PROJECT TEAM ORGANIZATIONAL BREAKDOWN STRUCTURE......................34.3.2 PROJECT TEAM ROLES AND RESPONSIBILITIES..............................................3
5.0 Project Management and Controls5.0 Project Management and Controls................................................................................335.1 S5.1 STAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITION..........................................................................................335.2 A5.2 ASSUMPTIONSSSUMPTIONS................................................................................................................................................................................44
5.5.3.1 [RISK 1 NAME].............................................................................................5PROBABILITY AND IMPACT -......................................................................................5
5.5.3.2 [RISK 2 NAME].............................................................................................5PROBABILITY AND IMPACT -......................................................................................55.5.4 PROJECT RISK MITIGATION APPROACH.........................................................55.5.5 RISK REPORTING AND ESCALATION STRATEGY.............................................55.5.6 PROJECT RISK TRACKING APPROACH.............................................................5
5.6 I5.6 INDEPENDENTNDEPENDENT V VERIFICATIONERIFICATION ANDAND V VALIDATIONALIDATION - IV&V - IV&V....................................555.7 S5.7 SCOPECOPE M MANAGEMENTANAGEMENT P PLANLAN................................................................................................................................555.8 I5.8 ISSUESSUE M MANAGEMENTANAGEMENT........................................................................................................................................................55
5.8.1 INTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS...........................55.8.2 EXTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS..........................5
5.9 P5.9 PROCUREMENTROCUREMENT M MANAGEMENTANAGEMENT P PLANLAN..................................................................................................555.10 C5.10 CHANGEHANGE C CONTROLONTROL..........................................................................................................................................................55
5.10.1 CHANGE CONTROL PROCESS..........................................................................55.10.2 CHANGE CONTROL BOARD (CCB).................................................................5
5.11 P5.11 PROJECTROJECT T TIMELINEIMELINE........................................................................................................................................................555.12 P5.12 PROJECTROJECT B BUDGETUDGET..............................................................................................................................................................66
5.12.1 BUDGET TRACKING.........................................................................................65.13 C5.13 COMMUNICATIONOMMUNICATION P PLANLAN..........................................................................................................................................66
5.13.1 COMMUNICATION MATRIX.............................................................................65.13.2 STATUS MEETINGS..........................................................................................65.13.3 PROJECT STATUS REPORTS............................................................................6
5.14 P5.14 PERFORMANCEERFORMANCE M MEASUREMENTEASUREMENT (P (PROJECTROJECT M METRICSETRICS))..........................................665.14.1 BASELINES........................................................................................................65.14.2 METRICS LIBRARY..........................................................................................6
5.15 Q5.15 QUALITYUALITY O OBJECTIVESBJECTIVES ANDAND C CONTROLONTROL............................................................................................665.15.1 CUSTOMER SATISFACTION..............................................................................65.15.2 DELIVERABLE DEFINITION..............................................................................65.15.3 DELIVERABLE QUALITY..................................................................................65.15.4 PROJECT/PRODUCT DELIVERABLE PRESENTATION......................................6
5.16 C5.16 CONFIGURATIONONFIGURATION M MANAGEMENTANAGEMENT..............................................................................................................665.16.1 VERSION CONTROL.........................................................................................65.16.2 PROJECT REPOSITORY (PROJECT LIBRARY).................................................6
6.1 A6.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE............................................................................................................................................776.2 C6.2 CONTRACTONTRACT C CLOSELOSE................................................................................................................................................................77
7.0 Glossary7.0 Glossary........................................................................................................................................................................887.1 A7.1 ACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONS................................................................................................................887.2 D7.2 DEFINITIONSEFINITIONS....................................................................................................................................................................................88
iii
Project Management Plan iv
LLISTIST OFOF F FIGURESIGURES
Error! No table of figures entries found.
iv
OCIO, 01/03/-1,
List the diagrams, tables, charts, and illustrations used the project plan.
Project Management Plan v
LLISTIST OFOF A APPENDICESPPENDICES
Appendix A: Work Breakdown Structure
Appendix B: Project Schedule
Appendix C: Forms
Appendix D:
Appendix E:
Appendix F:
Appendix G:
Appendix H:
v
OCIO, 01/03/-1,
All forms that will be used as a part of the management of the project and that are referenced in the PMP should be included as a part of Appendix C. This will include Deliverable Acceptance Form, Project Acceptance Form. Issue Escalation and Resolution Form, Change Request Form, Project Status Report. Also a Team Directory and a Calendar of Recurring Meetings are suggested.
OCIO, 01/03/-1,
There may be numerous appendices that are needed for a project. All appendices should be referenced in the PMP with a high level summary of the details contained in the appendices and should be listed here.
Project Management Plan vi
AABOUTBOUT T THISHIS D DOCUMENTOCUMENT
This document is a template that provides the industry accepted guidelines to plan, execute, control, and close a project. This document will need to be tailored and customized to the needs of the project; however, special care should be considered if major sections are “tailored out”.
1. “Tailoring” is the process that modifies the structural components of the template to the needs of a specific project. As an example, the Project Manager may have a standard appendix that does not apply to the project.
2. Customization is the mechanical task of inserting customer or project logos, deliverable identifiers, names, and so on, into a copy of the template. The copy then becomes the live version of the Project Management Plan for the project and will need to be updated, as project conditions require.
3. Any level of tailoring can be applied to the template, as long as the PMO is advised. This notification has several purposes:
a. It allows Quality Assurance to adjust checklists and questionnaires,
b. It allows the Program Management Office (PMO) to adjust its oversight and QA activities to the project’s plan,
c. It allows the PMO to advise the project team of the potential effects and risks that may occur if materials are omitted, and
d. It serves as a trigger for possible improvement of the template by the PMO.
4. Any highlighted text indicates that there are some brief instructions for the completion of that section.
vi
Project Management Plan vii
RREVISIONEVISION H HISTORYISTORY
Revision Number Date Comment1.0 September 25, 2003 Original Scope1
2.0 February 5, 2004 PMO Refinement
1 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.
2.2.1 B2.2.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES
NNUMBERUMBER DDESCRIPTIONESCRIPTION
Bus. Objective 1
2.2.2 T2.2.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES
NNUMBERUMBER DDESCRIPTIONESCRIPTION
Tech. Objective 1
2.3 D2.3 DELIVERABLESELIVERABLES
2.3.1 P2.3.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES
2.3.1.1 [DELIVERABLE 1 NAME]
Description - Deliverable Acceptance Criteria -
Standards for Content and Format - Quality Review -
1
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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
OCIO, 01/03/-1,
Insert the name of the deliverable
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Technical Objectives relate to the technical issues or goals that the project is to accomplish
OCIO, 01/03/-1,
The business objectives should relate to the Business Owner’s Strategic Plan
OCIO, 01/03/-1,
State the business benefits the project is to accomplish
OCIO, 01/03/-1,
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.
Project Management Plan
2.3.1.2 [DELIVERABLE 2 NAME]
Description - Deliverable Acceptance Criteria -
Standards for Content and Format - Quality Review -
2.3.2 P2.3.2 PRODUCTRODUCT D DELIVERABLESELIVERABLES
2.3.2.1 [DELIVERABLE 1 NAME]
Description - Deliverable Acceptance Criteria -
Standards for Content and Format - Quality Review -
2.3.2.2 [DELIVERABLE 2 NAME]
Description - Deliverable Acceptance Criteria -
Standards for Content and Format - Quality Review -
2.3.3 D2.3.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS
DDELIVERABLEELIVERABLE NNUMBERUMBER
DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))
DDATEATE AAPPROVEDPPROVED
PRJ-DEL-001 Project Management Plan (PMP)
2.3.4 D2.3.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE
2.4 W2.4 WORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS) (WBS)
3.0 O3.0 OVERALLVERALL S STRATEGYTRATEGY
3.1 P3.1 PROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLE
3.2 C3.2 CRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORS
2
OCIO, 01/03/-1,
Identify the critical success factors for achieving success in this project.
OCIO, 01/03/-1,
Discuss the key project management strategies for achieving success in this project.
OCIO, 01/03/-1,
The Overall Strategy is a high-level scheme and/or specific methodology used to guide the work effort for the project. It tells the story of how the project will be done. It may include what is to be done (actions/activities), why it is being done in this way, why doing it this way (logic, reasons, justifications) is recommended, and what the added value of the strategy and results are. Items to consider and identify either as separate sections or within one section for overall strategy are the details concerning project management strategy, project logistics, the product life cycle model and technical strategy. Describe the strategy/approach at the necessary and relevant level of detail for the specific project.
OCIO, 01/03/-1,
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 and include the detailed WBS as Appendix A.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Product Deliverables are tangible, verifiable work products that are directly driven by the project scope, business and technical objectives and product requirements. Include subordinate deliverables that comprise a major deliverable if the subordinate deliverables require reviewed and approval for acceptance. Examples are training documents and program, user manuals, Software Architecture Design, Data Modeling Schema, Content Management Application, or an Enterprise Portal System.
Project Management Plan
3.3 P3.3 PROJECTROJECT L LOGISTICSOGISTICS
3.4 P3.4 PRODUCTRODUCT L LIFEIFE C CYCLEYCLE M MODELODEL
3.5 T3.5 TECHNICALECHNICAL S STRATEGYTRATEGY
4.0 P4.0 PROJECTROJECT O ORGANIZATIONRGANIZATION
4.1 S4.1 STAKEHOLDERSTAKEHOLDERS
NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE
4.2 C4.2 CUSTOMERSUSTOMERS
4.3 P4.3 PROJECTROJECT T TEAMEAM
4.3.1 P4.3.1 PROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE
4.3.2 P4.3.2 PROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES
5.0 P5.0 PROJECTROJECT M MANAGEMENTANAGEMENT ANDAND C CONTROLSONTROLS
5.1 S5.1 STAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITION
3
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Insert a graphical Organization Chart here. The Organizational Breakdown Structure (OBS) is a hierarchical configuration defining levels of program management and may identify all project personnel. The OBS 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 OBS to identify core project team. The OBS can also be used for management reporting.
OCIO, 01/03/-1,
List the customers or end users of this product.
OCIO, 01/03/-1,
List all of the major stakeholders in this project, and state why they have a stake. Also, identify stakeholders required to sign-off on the PMP by an asterisk after their name. 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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Discuss the key technical strategies for achieving success in this project.
OCIO, 01/03/-1,
Identify the life cycle models being used to develop the project product or service, and discuss each of its phases.
OCIO, 01/03/-1,
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.
Project Management Plan
5.2 A5.2 ASSUMPTIONSSSUMPTIONS22
NNUMBERUMBER DDESCRIPTIONESCRIPTION
5.3 C5.3 CONSTRAINTSONSTRAINTS33
NNUMBERUMBER DDESCRIPTIONESCRIPTION
5.4 D5.4 DEPENDENCIESEPENDENCIES
5.4.1 M5.4.1 MANDATORYANDATORY D DEPENDENCIESEPENDENCIES
NNUMBERUMBER DDESCRIPTIONESCRIPTION
5.4.2 D5.4.2 DISCRETIONARYISCRETIONARY D DEPENDENCIESEPENDENCIES
NNUMBERUMBER DDESCRIPTIONESCRIPTION
5.4.3 E5.4.3 EXTERNALXTERNAL D DEPENDENCIESEPENDENCIES
NNUMBERUMBER DDESCRIPTIONESCRIPTION
5.5 R5.5 RISKISK M MANAGEMENTANAGEMENT
5.5.1 R5.5.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY
2 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 team’s options. Contractual provisions will generally be considered constraints.
4
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
Project Management Plan
5.5.2 P5.5.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION
5.5.3 P5.5.3 PROJECTROJECT R RISKISK A ANALYSISNALYSIS
5.5.3.1 [RISK 1 NAME]
Description - Probability and Impact -
Mitigation Strategy - Contingency Plan -
5.5.3.2 [RISK 2 NAME]
Description - Probability and Impact -
Mitigation Strategy - Contingency Plan -
5.5.4 P5.5.4 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH
5.5.5 R5.5.5 RISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY
5.5.6 P5.5.6 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH
5.6 I5.6 INDEPENDENTNDEPENDENT V VERIFICATIONERIFICATION ANDAND V VALIDATIONALIDATION - IV&V - IV&V
5.7 S5.7 SCOPECOPE M MANAGEMENTANAGEMENT P PLANLAN
5.8 I5.8 ISSUESSUE M MANAGEMENTANAGEMENT
5.8.1 I5.8.1 INTERNALNTERNAL I ISSUESSUE E ESCALATIONSCALATION ANDAND R RESOLUTIONESOLUTION P PROCESSROCESS
5.8.2 E5.8.2 EXTERNALXTERNAL I ISSUESSUE E ESCALATIONSCALATION ANDAND R RESOLUTIONESOLUTION P PROCESSROCESS
5.9 P5.9 PROCUREMENTROCUREMENT M MANAGEMENTANAGEMENT P PLANLAN
5.10 C5.10 CHANGEHANGE C CONTROLONTROL
5.10.1 C5.10.1 CHANGEHANGE C CONTROLONTROL P PROCESSROCESS
5.10.2 C5.10.2 CHANGEHANGE C CONTROLONTROL B BOARDOARD (CCB) (CCB)
5.11 P5.11 PROJECTROJECT T TIMELINEIMELINE
5
OCIO, 01/03/-1,
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. A summary-level Gantt chart can be used to meet the timeline requirement. The detailed project schedule should be referenced as Appendix B.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Describe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Identify what actions will be taken when the risk materializes and threatens the scope, budget, or the schedule of the project.
OCIO, 01/03/-1,
Identify what actions can be taken in order to reduce the probability of the risk, or to reduce its impact on the project.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Describe the risk’s characteristics and explain why this risk is perceived to have the potential to affect the outcome of the project.
OCIO, 01/03/-1,
Insert the name of the deliverable
OCIO, 01/03/-1,
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.
5.15.4 P5.15.4 PROJECTROJECT/P/PRODUCTRODUCT D DELIVERABLEELIVERABLE P PRESENTATIONRESENTATION
5.16 C5.16 CONFIGURATIONONFIGURATION M MANAGEMENTANAGEMENT
5.16.1 V5.16.1 VERSIONERSION C CONTROLONTROL
5.16.2 P5.16.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))
6
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
Describe 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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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.
OCIO, 01/03/-1,
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).
Project Management Plan
6.0 P6.0 PROJECTROJECT C CLOSELOSE
6.1 A6.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE
6.2 C6.2 CONTRACTONTRACT C CLOSELOSE
7
OCIO, 01/03/-1,
Contract close is similar to administrative close in that it involves product and process verification for contract close.
OCIO, 01/03/-1,
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 is contingent on the project’s complexity and size. Project managers should work with the project’s project management consultant to tailored Project Close procedures to compliment the project’s objectives
OCIO, 01/03/-1,
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.
Project Management Plan
7.0 G7.0 GLOSSARYLOSSARY
7.1 A7.1 ACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONS
OCIO Office of the Chief Information OfficerIPP Integrated Project PlanPMI Project Management Institute.PMBOK Project Management Body of KnowledgePMC Program Management ConsultantPMO Program Management OfficePMP Project Management PlanQM Quality ManagementWBS Work Breakdown Structure
7.2 D7.2 DEFINITIONSEFINITIONS
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]
8
Project Management Plan
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.
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.
9
Project Management Plan
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
Project Management Plan
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 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.
11
Project Management Plan
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
Project Management Plan
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 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.
