Project Management Plan Workbook

7/27/2019 Project Management Plan Workbook

1/50

PPREPARATIONREPARATION WWORKBOOKORKBOOK

FORFOR

PROJECT MANAGEMENT PLANPROJECT MANAGEMENT PLAN

(PMP)(PMP)

REVISION: 1.1


2/50

WORKBOOKFORPREPARATIONOFTHE PROJECT MANAGEMENT PLAN I

REVISION HISTORY..............................................................................................I

ABOUT THIS DOCUMENT PREPARING THE PROJECT MANAGEMENT PLAN.............II

STARTING WITH THE TITLE PAGE........................................................................V

1.0 PROJECT OVERVIEW .....................................................................................1

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...............................5

3.0 SCOPE .........................................................................................................7

4.0 PROJECT DELIVERABLES AND METHODOLOGY................................................9

5.0 PROJECT WORK...........................................................................................19

6.0 PROJECT MANAGEMENT AND CONTROLS......................................................22

7. 0 PROJECT CLOSE.........................................................................................37

ATTACHMENTS.................................................................................................37

REVISION HISTORYREVISION HISTORY

RREVISIONEVISION NNUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0 July 27th, 2007 DoIT Project Management Office Revision

2.0

2.1

2.2

I


3/50

WORKBOOKFORPREPARATIONOFTHE PROJECT MANAGEMENT PLAN II

ABOUT THIS DOCUMENT PREPARING THE PROJECTABOUT THIS DOCUMENT PREPARING THE PROJECT

MANAGEMENT PLANMANAGEMENT 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 2007Project Oversight Process Memorandum DoIT, July 2007

1 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.

2 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.

3 A project plan includes at least other plans for issue escalation, change control,

communications, deliverable review and acceptance, staff acquisition, and risk management.

4 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 toensure 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.

5 Project product means the final project deliverables as defined in the project plan meeting all

agreed and approved acceptance criteria.

6 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 PLANNINGCONCEPTS BEHIND PROJECT MANAGEMENT PLANNING

WWHATHATISISAAPROJECTPROJECT??

0 A project is a temporary endeavor undertaken to create a unique product, service orresult PMBOK

WWHATHATISIS PPROJECTROJECT MMANAGEMENTANAGEMENT??

Is about how we create and manage a temporaryorganization to deliver the unique

product, service or result!

II


4/50

WORKBOOKFORPREPARATIONOFTHE PROJECT MANAGEMENT PLAN III

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!

PPROJECTROJECTMANAGEMENTMANAGEMENT QQUESTIONSUESTIONS

1 What is the unique product, service or result?

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

3 How do we know when we are finished?

4 Who is doing what for whom?

5 How do we know how we are doing?

6 How do we handle uncertainty or conflict?

UUNIQUENIQUE PPRODUCTRODUCT, S, SERVICEERVICEORORRRESULTESULT

0 Product what are we trying to accomplish and how will we know when we are

finished?

7 Product Development

Project Objectives-> Business Requirements -> System Requirements-> Architecture->

Solution Design-> Build-> Pilot-> Deploy

Quality of Product

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

Success Criteria

8 Deployment of Product

9 Resource Requirements and staffing for new product

10 Deployment Plan and Transition To Operations

11 Operations and Support for product

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

WWHOHOISISDOINGDOING WWHATHATFORFORWWHOMHOM??

7 Roles and Responsibilities

III


5/50

WORKBOOKFORPREPARATIONOFTHE PROJECT MANAGEMENT PLAN IV

0 For Whom

0 Project Sponsor

1 Project Funding Source

2 End User

3 Beneficiaries of new solution

1 W ho

0 Project Team

1 Subject Matter Experts

2 Vendors

3 Operations

HHOWOWAREAREWEWEDOINGDOING??

8 Time

9 Calendar of tasks, task targets

0 Work Breakdown Structure What needs to be done

1 Time estimation how much time will be needed?

10 Budget

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

0 How much money have we spent?

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

11 Quality and IV&V

0 Are we doing what we have set out to do?

12 Metrics

0 How many changes are we making?

HHOWOWWELLWELLORGANIZEDORGANIZEDAREAREWEWE

13 Are we meeting with stake holders and team members?

IV


6/50

WORKBOOKFORPREPARATIONOFTHE PROJECT MANAGEMENT PLAN V

14 Have we identified possible roadblocks?

15 Do we document disagreements and work towards resolutions?

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

17 Do we keep stake holders informed?

PPROJECTROJECT MMANAGEMENTANAGEMENT PPLANLAN

0 Is about how we create and manage a temporaryorganization to deliver the unique

product, service or result!

1 Is not a Microsoft Project file -MS Project is a scheduling aid

STARTING WITH THE TITLE PAGESTARTING WITH THE TITLE PAGE

Even the title page has significant information, and assumptions. It tells us what the project callsitself, 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 TITLETHE 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 OWNERTHE EXECUTIVE SPONSOR AND BUSINESS OWNER

Project sponsorship is about the resources required to do the project, whether they are thefinancial resources from state or federal funding/appropriation or from the agencys own

operating funds.

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

project.

The following are some key responsibilities of project sponsorship:

Appoint an appropriately skilled project manager

Understand the project complexity

Champion the project and the team

Formally manage the project scope

Provide guidance for business strategies

V


7/50


8/50

WORKBOOKFORPREPARATIONOFTHE PROJECT MANAGEMENT PLAN 1

1.0 PROJECT OVERVIEW1.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, thefuture state, and the need.

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT1.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 agencyhas to solve the problem through an IT solution. Briefly present essentials to relay the

problem and opportunity presented including the agencys 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 eliminatethe 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


9/50


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 persons attention to sell the problem and the solution to the problem.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCES

This question is also asked in the request for certification and release of funds document. A project isnot 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).

SOURCESOURCE AMOUNTAMOUNT ASSOCIATEDASSOCIATED

RESTRICTIONSRESTRICTIONSAPPROVERSAPPROVERS

1.3 CONSTRAINTS1.3 CONSTRAINTS

Constraints are factors that restrict the project by scope, resource, or schedule. Constraints caninclude 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 teams options.

Contractual provisions will generally be considered constraints.

NNUMBERUMBER DDESCRIPTIONESCRIPTION

1.4 DEPENDENCIES1.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 cars gas tank, which usually meansfinding an open gas station, having cash or a credit card with which to pay for the gas.

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

is: Mandatory dependencies are dependencies that are inherent to the work being done.

D- Discretionary dependencies are dependencies defined by the project management

team. This may also encompass particular approaches because a specific sequence of

activities is preferred, but not mandatory in the project life cycle.

PAGE 2


10/50


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 cars 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.

NUMBERNUMBER DESCRIPTIONDESCRIPTION TYPE M,D,ETYPE M,D,E

1.51.5 ASSUMPTIONSASSUMPTIONS

Assumptions may contain little or significant amount of risk. We can assume that members ofour 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 assumevendors 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, orcertain. Assumptions generally involve a degree of risk. They may be documented here andconverted 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.


1.6 INITIAL PROJECT RISKS IDENTIFIED1.6 INITIAL PROJECT RISKS IDENTIFIED

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

PAGE 3


11/50


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 reducesthe 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 risks characteristics and explain why this risk is perceived to havethe 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 therisk, or to reduce its impact on the project.

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

[Risk 1 Name]

Description -Probability and Impact

Mitigation Strategy

Contingency Plan

PAGE 4


12/50


[Risk 2 Name]

Description -Probability and Impact

Mitigation Strategy

Contingency Plan

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL2.0 PROJECT AUTHORITY AND ORGANIZATIONAL

STRUCTURESTRUCTURE

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 thehierarchical configuration of those groups. It exists to clarify interaction with the project team.

2.1 STAKEHOLDERS2.1 STAKEHOLDERSList 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 projects 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


13/50


NAMENAME SSTAKETAKEININ PPROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

2.2 PROJECT GOVERNANCE STRUCTURE2.2 PROJECT GOVERNANCE STRUCTURE

2.2.1 D2.2.1 DESCRIBEESCRIBETHETHEORGANIZATIONALORGANIZATIONALSTRUCTURESTRUCTURE O ORGRG CCHARTHART

A key element in the project governance is the Organization chart for the project.Describe theprocess 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.

PAGE 6


14/50


2.2.2 D2.2.2 DESCRIBEESCRIBETHETHEROLEROLEANDANDMEMBERSMEMBERSOFOFTHETHEPROJECTPROJECTSTEERINGSTEERINGCOMMITTEECOMMITTEE

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 andquality 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 O2.2.1 ORGANIZATIONALRGANIZATIONAL BBOUNDARIESOUNDARIES,, INTERFACESINTERFACESANDANDRESPONSIBILITIESRESPONSIBILITIES

Use this section to describe any special considerations regarding contact between the projectteam, 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, ad-

hoc meetings, electronic mail, and phone conversations. Interaction may occur directly betweenthe 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 REPORTING2.3 EXECUTIVE REPORTING

Use this section to describe the method that will be used to effectively disseminate informationto 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 todevelop a detail communication plan as part of the project plan.

Keep In mind here the projects 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 SCOPE3.0 SCOPE

3.1 PROJECT OBJECTIVES3.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 thatthe system performs as intended and contains no unnecessary elements?

PAGE 7


15/50


3.1.1 B3.1.1 BUSINESSUSINESS OOBJECTIVESBJECTIVES

Business objectives are the high level business requirements of the project. The following tablecomes from a requirement collection template. It suggests the ingredients of a well written

business objective.

Description

Rationale

Acceptance/Fi

t Criteria

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 T3.1.2 TECHNICALECHNICAL OOBJECTIVESBJECTIVES

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 hows of the project.

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 Objectivespresented.

Parent

Requirement

#

Description

Rationale

Source Source

Document

Acceptance/Fi

t Criteria

PAGE 8


Bus. Objective 1


Tech. Objective 1


16/50


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 ahierarchical manner: The following is an example of such a presentation of technical objectives.


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 EXCLUSIONS3.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 FACTORS3.3 CRITICAL SUCCESS FACTORSIdentify 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.

NUMBERNUMBER DESCRIPTIONDESCRIPTION

QUALITY METRICS1

4.0 PROJECT DELIVERABLES AND METHODOLOGY4.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 orcustomer). Analyze the project scope and objectives outlined in the Project Proposal and Charter

to develop a list of deliverables.

PAGE 9


17/50


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 NewMexico Project Management Methodology distinguishes between the project and the product.

Project Deliverables relate to how we conduct the business of the project. Product Deliverablesrelate 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 attributesback to our initial requirements

4.1 PROJECT MANAGEMENT LIFE CYCLE4.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 Institutes PMBOK.

Key Project Deliverables of each of these five processes are identified as including the

following:

PAGE 10


18/50


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 ManagementIssues 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


19/50


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 tothe 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 includesactivity 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. TheQuality 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 appropriateresponse 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 andservices from sources external to the projects organization. It includes procurement planning,

solicitation planning, solicitation, source selection, contract administration, and contract closeout.

PAGE 12


20/50


4.1.1 P4.1.1 PROJECTROJECT MMANAGEMENTANAGEMENT DDELIVERABLESELIVERABLES

Project Deliverables are work products or artifacts that are driven by the project management

methodology requirements and standard project management practices regardless of the productrequirements of the project. Examples are project, phase, and iteration plans, and project

schedules. Project Deliverables must be reviewed and approved by the projects Executive

Sponsor prior to their implementation.

Description - Deliverable description conveys the features and/or the functions that will beincluded 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 tomeasures 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, andprocesses used to develop the deliverable must compliment the executive sponsors 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 executivesponsor.

4.1.1.1 [Deliverable 1 Name]

Description - Deliverable Acceptance Criteria - .

Standards for Content and Format -

Quality Review -


Description - Deliverable Acceptance Criteria -

PAGE 13


21/50



Quality Review -

4.1.2 D4.1.2 DELIVERABLEELIVERABLE AAPPROVALPPROVAL AAUTHORITYUTHORITY DDESIGNATIONSESIGNATIONS

Complete the following table to identify the deliverables this project is to produce, and to namethe 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 wheneach deliverable was approved.

DDELIVERABLEELIVERABLE

NNUMBERUMBERDDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W(WHOHO

CANCANAPPROVEAPPROVE))DDATEATE

AAPPROVEDPPROVED

PRJ-DEL-001 Project Management Plan (PMP)

4.1.3 D4.1.3 DELIVERABLEELIVERABLE AACCEPTANCECCEPTANCE PPROCEDUREROCEDURE

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 forreview, 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 CYCLE4.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 OVERSIGHTPROCESS Memorandum

Phase Summary of Phase Key Deliverables

PAGE 14


22/50


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 aredetermined by the control needs of the organization or organizations involved in the

project. Project Management Institutes 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 andcontrol 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 thisapproach. 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


23/50


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



Build

Systems Design Documents applied

Training Materials ready



Pilot Acceptance CriteriaPilot


Training Materials ready



Pilot Run, Evaluated

Pilot Acceptance

Deploy


Training Materials Used

Deployment and transition to operations plan

Operations and Support Plan

Close

PAGE 16


24/50


Systems Acceptance by Operations

4.2.1 T4.2.1 TECHNICALECHNICAL SSTRATEGYTRATEGY

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 P4.2.2 PRODUCTRODUCTANDAND PPRODUCTRODUCT DDEVELOPMENTEVELOPMENT DDELIVERABLESELIVERABLES

Product Deliverables are work products or artifacts that are driven by the product managementmethodology 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 projects ExecutiveSponsor prior to their implementation.

Description - Deliverable description conveys the features and/or the functions that will beincluded 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 teamknow 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 formatthat 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 sponsors 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


25/50


cycle and the number of exceptions reported by Quality Control and eventually the executive

sponsor.


Description - Deliverable Acceptance Criteria - .


Quality Review - .


Description - Deliverable Acceptance Criteria -


Quality Review -

4.2.3 D4.2.3 DELIVERABLEELIVERABLE AAPPROVALPPROVAL AAUTHORITYUTHORITY DDESIGNATIONSESIGNATIONS

Complete the following table to identify the deliverables this project is to produce, and to namethe 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.

DDELIVERABLEELIVERABLE

NNUMBERUMBERDDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W(WHOHO

CANCANAPPROVEAPPROVE))DDATEATE

AAPPROVEDPPROVED

PRJ-DEL-001 Project Management Plan (PMP)

4.2.4 D4.2.4 DELIVERABLEELIVERABLE AACCEPTANCECCEPTANCE PPROCEDUREROCEDURE

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 forreview, 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


26/50


5.0 PROJECT WORK5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)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 definitionof 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 workpackages 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.

IdentifierWork PackageDescription

Definition/Objective Milestone/Deliverable

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE5.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-levelGantt chart can be used to meet the timeline requirement.

Please provide a more detailed project schedule as an attachment to this plan

Identifier Task/ActivityName ResourceName Milestone(Y/N) Effort/Duration Start Finish DependentTask

PAGE 19


27/50


5.3 PROJECT BUDGET5.3 PROJECT BUDGETCosts 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; includebreakdowns 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 EstimatedBudget

Umbrella Tasks

Phase 1

Project Preparation

& Planning

Project plan

Project Schedule

Phase 2

Phase 3

Phase 4

Project Closing

TOTALS

5.4 PROJECT TEAM5.4 PROJECT TEAM

PAGE 20


28/50


5.4.1 P5.4.1 PROJECTROJECT TTEAMEAM OORGANIZATIONALRGANIZATIONAL SSTRUCTURETRUCTURE

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 peoples 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 beused for management reporting.

5.4.2 P5.4.2 PROJECTROJECT TTEAMEAM RROLESOLESANDAND RRESPONSIBILITIESESPONSIBILITIES

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 havea specific role.

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL

AAREAREA

5.5 STAFF PLANNING AND RESOURCE ACQUISITION5.5 STAFF PLANNING AND RESOURCE ACQUISITION

Complete the chart below identifying the project team members and details concerning theirproject commitment. Type should be State, Contract, Customer (Business Owner), or Vendor.

5.5.1 P5.5.1 PROJECTROJECT SSTAFFTAFF

Resource

Cost

Estimate

Estimated

Hours Availability Skill Set Work Product/Deliverable

PAGE 21


29/50


5.5.2 N5.5.2 NONON-P-PERSONNELERSONNELRESOURCESRESOURCES

Use this section to list services or product (HW/SW and such) needed for project

ResourceCostEstimate

Estimatedunits/hours Availability Source

WorkProduct/Deliverable

5.6 PROJECT LOGISTICS5.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 isrelated to logistics. Training specifically related to project team members should be included

here.

5.6.1 P5.6.1 PROJECTROJECT TTEAMEAM TTRAININGRAINING

Describe training if any needed by project team members. This is not to include training for endusers, system administrators or business owners; those should be handled within a training

document or part of the transition to operations planning.

Resource

Cost

Estimate

Estimated

Hours Availability Skill Set Work Product/Deliverable

6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1 RISK AND ISSUE MANAGEMENT

PMBOK:

PAGE 22


30/50


Risk: An uncertain event or condition that, if it occurs, has a positive or negative effect on a

projects objectives.

Issue: A point or matter in question or dispute, or a point or matter that is not settled and isunder discussion or over which there are opposing views or disagreements.

Both Risks and Issues can significant impact a projects success, and both should be handled insimilar ways.

Project Management IS Risk Mitigation. Is about how we create and manage a

temporaryorganization to deliver the unique product, service or result!

By providing structure to the temporary organization and the solutiondevelopment/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 effectivelydealing with specific risk.

6.1.1 R6.1.1 RISKISKMMANAGEMENTANAGEMENT SSTRATEGYTRATEGY

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 ifneeded 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 P6.1.2 PROJECTROJECT RRISKISKIIDENTIFICATIONDENTIFICATION

Organizational

Project Organization

Resource

Staff, Skills, Etc

External Risks

Vendors, suppliers

Planning Risks

Uncertainty, Complexity

Technical Risks Requirements, Reliability

Organizational Risks

Poor Initiation

Sponsor Changes

PAGE 23


31/50


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

Team Morale

Ineffective Communication

External Risks

Vendor/Supplier

PAGE 24


32/50


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

Poor Communications

Poorly Run or attended meetings

No record keeping

PAGE 25


33/50


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


34/50


6.1.3 P6.1.3 PROJECTROJECT RRISKISKMMITIGATIONITIGATION AAPPROACHPPROACH

6.1.4 R6.1.4 RISKISKRREPORTINGEPORTINGANDAND EESCALATIONSCALATION SSTRATEGYTRATEGY

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 Risk Probability Impact R

1 Example Certain High 0

PAGE 27


35/50


6.1.5 P6.1.5 PROJECTROJECT RRISKISKTTRACKINGRACKING AAPPROACHPPROACH

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 Contingency

Plan

Mitigation

Plan

1 Example Certain High 0.7125

6.1.6 ISSUE MANAGEMENT6.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:

IssueNo. Issue

PersonResponsible

Date OpenMonth/Day

1 Example ProjectManager

03/

Issue Form

IssueNo.

(FromIssue

Log)

ResponsibleParty (From

Issue Log)

Level(High,Medium,

Low)

Class(Impact

Area)

DateOpened(FromIssue

Log)

Date

Closed Originator1 Project Manager 03/15/07

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-complian

Resolution

Hiring a contractor could resolve this delay at a cost less than the fine for non-complian

PAGE 28


36/50


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 beused 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&V6.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 theproducts 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 PLAN6.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 CHANGE6.3.1 CHANGE CONTROLCONTROL

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 thatwe document and discuss the change process with the executive sponsor.

PAGE 29


37/50


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 tothe project plan.

A project might want to formalize Change Management through a form such as shown below:

PPROJECTROJECT CCHANGEHANGE RREQUESTEQUEST

PROJECT:PROJECT:

AGENCY: DATE:

PROJECTMANAGER:

PROJECT #:

AGENCYAND PROJECT INFORMATION:

REQUESTED BY: DATE:

AUTHORIZED BY: DATE:

DESCRIPTION:

PAGE 30


38/50


IMPACT: Technical Schedule Cost Other

ACTION PLAN:

MARKONE:

THIS CHANGE: Is Is NOT Within Scope.

THIS CHANGEIS: Accepted Denied On Hold Delayed

6.4 PROJECT BUDGET MANAGEMENT6.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, processingcycles, 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 B6.4.1 BUDGETUDGET TTRACKINGRACKING

6.5 COMMUNICATION PLAN6.5 COMMUNICATION PLAN

Communication planning involves determining the information and communication needs of thestakeholders, 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


39/50


6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION MMATRIXATRIX

6.5.2 S6.5.2 STATUSTATUS MMEETINGSEETINGS

6.5.3 P6.5.3 PROJECTROJECT SSTATUSTATUS RREPORTSEPORTS

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)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, resourceusage, 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 CaseStatus Critical Paths Tested Problem Report Status ReviewsCompleted Change RequestStatus

Incremental Capability Build Content Component Build Content Function

Resources and Cost Personnel Effort Staff Experience StaffTurnover

Financial Performance Earned Value Cost

Availability Resource Availability Dates Resource Utilization

Growth and Stability Product Size and Stability Lines of Code Components Database Size

PAGE 32


40/50


Functional Size and Stability Requirements Function Points Change Request Workload

Product Quality Defects Problem Reports DefectDensity

Complexity Cyclomatic Complexity

Rework Rework Size Rework Effort

Development Performance Process Maturity Capability Maturity Model Level

Productivity Product Size/Effort Ratio Functional Size/Effort Ratio

6.6.1 B6.6.1 BASELINESASELINES

6.6.2 M6.6.2 METRICSETRICS LLIBRARYIBRARY

6.7 QUALITY OBJECTIVES AND CONTROL6.7 QUALITY OBJECTIVES AND CONTROL

Quality Management includes the processes required to ensure that the project will satisfy theneeds 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 Q6.7.1 QUALITYUALITY SSTANDARDSTANDARDS

Describe the agency, industry or regulatory project performance standards that will be followed andassessed by the project. These quality standards will be used to assess whether the quality objectiveswere achieved.

Identify each of the project quality standards that are directly related to the project and not to theperformance of the actual product and/or service. For each quality standard, identify the tracking tool ormeasure such as number of project reviews or Project Status.

From another states planning process

No. 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

PAGE 33


41/50


No. Quality Standard Tracking Tool or Measure

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 ChangeRequest

6.7.2 P6.7.2 PROJECTROJECTANDAND PPRODUCTRODUCT RREVIEWEVIEWANDAND AASSESSMENTSSSESSMENTS

Review Type Quality Standard Tools Reviewer Reports

Requirements

Plans

Milestones

Testing

6.7.3 A6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMERSSATISFACTIONATISFACTION

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 wouldbe 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:

SSSTANDARDSSTANDARDSNot

Applicable

Strongly

Disagree

DisagreeSomewhat

Agree

AgreeStrongly

Agree

PAGE 34


42/50


0 1 2 3 4 5

The level ofbusiness or agency

knowledge of [projects name] meets yourexpectations.

[Projects name] performs in aprofessionaland cooperative manner.

The level ofcommunications by

[projects name], both written and oral,

meet your expectations.

[Projects name] project team works well

with you and your staff.

[Projects name] project management

team is accessible when you need them.

[Projects name] provides adequate

information and trainingresulting in

effective knowledge transfer.

[Projects name] completes project taskswithin the agreed upon schedule.

The level oftechnical or businessexpertise of [projects name] meets yourexpectations.

You are receivingfull value from the

[projects name] project management

team.

The overall service provided by [projects

name] is fully meeting your expectations.

6.7.4 P6.7.4 PRODUCTRODUCT DDELIVERABLEELIVERABLE AACCEPTANCECCEPTANCE PPROCESSROCESS

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


43/50


Deliverable Final Approval Process Customer Acceptance Criteria

6.8 CONFIGURATION MANAGEMENT6.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 teamawareness are critical.

6.8.1 V6.8.1 VERSIONERSION CCONTROLONTROL

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 revisionnumber reflected. Best practice involves change management for documents, and a numbering

scheme such as 1.0, 2.0, 3.0 to reflect a projects phases and toll gates or approval processes per

phase.

6.8.2 P6.8.2 PROJECTROJECT RREPOSITORYEPOSITORY (P(PROJECTROJECT LLIBRARYIBRARY))

Provide to the Department all project management and product deliverables. Deliverables shall includebut 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. Thelead 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 PLAN6.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 closeoutshould 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


44/50


7. 0 PROJECT CLOSE7. 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 amandatory 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 A7.1 ADMINISTRATIVEDMINISTRATIVE CCLOSELOSE

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 phaseactivities 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 projectare contingent on the projects complexity and size. Project managers should work with the

projects project management consultant to tailor Project Close procedures to compliment the

projects objectives

7.2 C7.2 CONTRACTONTRACT CCLOSELOSE

Contract close is similar to administrative close in that it involves product and processverification for contract close.

Projects that have been certified need to complete the required DoIT project closure

certification processes.

ATTACHMENTSATTACHMENTS

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 DEFINITIONSATTACHMENT A ACRONYMS, ABBREVIATIONS AND DEFINITIONS

PMI Project Management Institute.

PMBOK Project Management Body of Knowledge

PMO Program Management Office

PAGE 37


45/50


PMP Project Management Plan

WBS Work Breakdown Structure

DEFINITIONSDEFINITIONS

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 criteriaand 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 thereafterserves 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 anddocument 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 teams options. Contract provisions will

generally be considered constraints.

Contingency PlanningThe development of a management plan that identifies alternative strategies to be used to ensureproject 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


46/50


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, DiscretionaryDependencies 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 alsoencompass 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 tocomplete an activity or other project element.

Duration CompressionShortening 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 isdeployed 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 insequence, 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


47/50


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 PlanA 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 ofperforming 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 measureprogress.

Non-technical Requirements

Agreements, conditions, and/or contractual terms that affect and determine the management

activities of an architectural and software project.

Performance ReportingCollecting and disseminating performance information. This includes status reportingmeasurement, 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 providestechnical 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


48/50


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 PlanA formal, approved document used to guide both project execution and project control. Theprimary 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 performingactivities 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.

Project Sponsor

The individual that provides the primary sponsorship for an approved project. This individualwill 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


49/50


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 PlanThe 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 mayalso exert influence over the project and its results.

StandardMandatory 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 visiblecheckpoint into the status of the project. Tasks have readiness criteria (preconditions) and

completion criteria (post conditions). (see activity for contrast.)

PAGE 42


50/50


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 RequirementsThose 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 thedevelopment 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 workscope of the project. Each descending level represents an increasingly detailed definition of the

project work.