Project Management Plan Workbook

(1)

P

REPARATION

W

ORKBOOK

FOR

PROJECT MANAGEMENT PLAN

(PMP)

(2)

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 HISTORY

R

REVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0 July 27th_{, 2007} _{DoIT Project Management Office Revision}

2.0 2.1 2.2

(3)

ABOUT THIS DOCUMENT – PREPARING THE PROJECT

MANAGEMENT PLAN

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

Project Oversight Process Memorandum – DoIT, July 2007

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 to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department.

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 PLANNING

W

WHATHATISISAAPROJECTPROJECT??

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

W

WHATHATISIS P PROJECTROJECT M MANAGEMENTANAGEMENT??

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

(4)

is more about the interested parties, technical teams and the solution building process!

P

PROJECTROJECTMANAGEMENTMANAGEMENT Q QUESTIONSUESTIONS

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?

U

UNIQUENIQUE P PRODUCTRODUCT, S, SERVICEERVICEOROR R RESULTESULT

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?

W W

HOHOISISDOINGDOING W W HATHATFORFOR WW HOMHOM??

7 Roles and Responsibilities

(5)

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

H

HOWOWAREAREWEWEDOINGDOING??

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-going support?

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?

H

HOWOWWELLWELLORGANIZEDORGANIZEDAREAREWEWE

13 Are we meeting with stake holders and team members?

(6)

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?

P

PROJECTROJECT M MANAGEMENTANAGEMENT P PLANLAN

0 Is about how we create and manage a temporary organization 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 PAGE

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

THE TITLE

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

THE EXECUTIVE SPONSOR AND BUSINESS OWNER

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

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

The following are some key responsibilities of project sponsorship:

• Appoint an appropriately skilled project manager

• Understand the project complexity

• Champion the project and the team

• Formally manage the project scope

• Provide guidance for business strategies

(7)

• Approve plans, schedules and budgets

• Ensure sustained buy-in

• Ensure timely availability of resources

• Review project progress

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

THE PROJECT MANAGER

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

“Project manager” means a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely

completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department.

WHAT IS THE ORIGINAL PLAN DATE AND WHY THE REVISION DATE

AND REVISION NUMBER?

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

THE IMPORTANCE OF REVISION HISTORY

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

(8)

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

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT

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

Some suggestions:

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

• Briefly explain the business problem faced by the agency and the opportunity the agency has to solve the problem through an IT solution. Briefly present essentials to relay the problem and opportunity presented including the agency’s business performance,

mission, goals, objectives, and strategic plan and, if any, cross agency collaborations and impacts

The Problem Statement-Recommendation approach:

• A problem statement that outlines what the existing situation is and how the business of the agency is being negatively impacted

• A brief “root cause” analysis listing factors that if resolved by the project would eliminate the problem, thus benefiting the agency.

• The project recommendation as the solution, stating clearly that the solution will address the root cause issues of the problem, resolving the problem and eliminating the negative impact to the agency.

The current state-future state- need approach

• The current state with its issues is described

• The ideal future state is described as if the solution were in place

• The need provides a description of the gap and tells how the work of the project will resolve the gap between the current and future states

(9)

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

1.2 FUNDING AND SOURCES

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

restrictions, and who the approvers are for the specific sources).

SOURCE

SOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED

RESTRICTIONS

RESTRICTIONS APPROVERS

APPROVERS

1.3 CONSTRAINTS

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

N

NUMBERUMBER DDESCRIPTIONESCRIPTION

1.4 DEPENDENCIES

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

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

• Mandatory dependencies are dependencies that are inherent to the work being done. • D- Discretionary dependencies are dependencies defined by the project management

team. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

(10)

activities and non-project activities such as purchasing/procurement

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

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

NUMBER

NUMBER DESCRIPTIONDESCRIPTION TYPE M,D,ETYPE M,D,E

1.5

1.5 ASSUMPTIONS

ASSUMPTIONS

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

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

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

N

1.6 INITIAL PROJECT RISKS IDENTIFIED

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

(11)

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

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

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

Description - Probability Impact

Mitigation Strategy Contingency Plan

Risk Name – should easy reflect the challenge without detail

Description - Describe the risk’s characteristics and explain why this risk is perceived to have

the potential to affect the outcome of the project.

Probability and Impact - - Probability should be measured as the likelihood of that the risk will

occur. Impact should be measured in terms of deviations from the schedule, effort, or costs from the schedule if risks occur.

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

Mitigation Strategy - Identify what actions can be taken in order to reduce the probability of the

risk, or to reduce its impact on the project.

Contingency Plan Identify what actions will be taken when the risk materializes and threatens

the scope, budget, or the schedule of the project.

[Risk 1 Name]

Description - Probability and Impact Mitigation Strategy Contingency Plan

(12)

[Risk 2 Name]

Description - Probability and Impact Mitigation Strategy Contingency Plan

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL

STRUCTURE

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

2.1 STAKEHOLDERS

List all of the major stakeholders in this project, and state why they have a stake. Stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.

The PMBOK© of the Project Management Institute defines project stakeholders:

“Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. They also exert influence over the project’s objectives and outcomes.” This all encompassing definition would have us think about such stakeholders as:

• Cabinet Secretaries

• Agency Division directors

• CIO-IT Leads

• Project Manager

• IT operations staff

• Business process owners

• System user representatives

• Key project team members

• Training staff

(13)

NAME

NAME SSTAKETAKEININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

2.2 PROJECT GOVERNANCE STRUCTURE

2.2.1 D

2.2.1 DESCRIBEESCRIBETHETHEORGANIZATIONALORGANIZATIONALSTRUCTURESTRUCTURE – O – ORGRG C CHARTHART

A key element in the project governance is the Organization chart for the project.Describe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations. Describe at a high-level how issues will be escalated and resolved and how change requests will be processed.

(14)

2.2.2 D

2.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 and quality of the project, deal with issues escalated to them, and also to accept or deny project team recommendations especially in go-no go decision matters.

2.2.1 O

2.2.1 ORGANIZATIONALRGANIZATIONAL B BOUNDARIESOUNDARIES, , INTERFACESINTERFACESANDANDRESPONSIBILITIESRESPONSIBILITIES

Use this section to describe any special considerations regarding contact between the project team, the project manager, and individuals from various organizations involved in the project: “The key interface between the organizations is between the Project Manager from the DoIT and the Project Managers from Contracting Vendor and between the Project Manager and the

assigned Team Leaders.. The primary methods utilized will be the Status Report/Briefing, ad-hoc meetings, electronic mail, and phone conversations. Interaction may occur directly between the technical components of all teams. However, overall task direction can only come from the Project Manager. Final decisions will be made at the Steering Committee level.”

2.3 EXECUTIVE REPORTING

Use this section to describe the method that will be used to effectively disseminate information to the project ‘s Executive Sponsor and/or the Business Owner and other governing bodies such as the Office of the Chief Information Officer and the Information Technology Commission. Indicate how, when, what type of information, to whom, and how often project related

information will be conveyed. This section does not replace the need for the project manager to develop a detail communication plan as part of the project plan.

Keep In mind here the project’s obligation: “. For all projects that require Department oversight, the lead agency project manager shall submit an agency approved project status report on a monthly basis to the Department.” PROJECT OVERSIGHT PROCESS memorandum

3.0 SCOPE

3.1 PROJECT OBJECTIVES

As the project progresses it must be able to answer the following question as “Yes!”:” Has the project established the ability to verify that business requirements can be traced through

technical design, system building or software coding/ configuration and test phases to verify that the system performs as intended and contains no unnecessary elements?”

(15)

3.1.1 B

3.1.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES

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

Description <Enter concise description of requirement>

Rationale <Provide a brief rationale, and or business value for the requirement.>

Acceptance/Fi

t Criteria <Provide a target that makes it possible to test if requirement was satisfied>

The typical problems with business objectives include:

• Lumping more than one objective into a business objective

• Use of too many loose phrases such as more, better, improve, fix, solve

3.1.2 T

3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES

Technical objectives relate to the technical issues or goals the project is to accomplish. These maybe related to acquisition of hardware, software, consulting, training, application development and other “how’s” of the project.

The business requirement table presented in the section above is useful here as well, with one addition, the parent Objective/ requirement which should be one of the Business Objectives presented.

Parent Requirement #

<Enter the unique id #(s) for each requirement that this requirement supports (This field will be empty for high level requirements e.g., business

requirements)>

Description <Enter concise description of requirement>

Rationale <Provide a brief rationale, and or business value for the requirement.>

Source <Name of Reqmnt. Provider> Source Document

Acceptance/Fi t Criteria

N

NUMBERUMBER DDESCRIPTIONESCRIPTION Bus. Objective 1

N

NUMBERUMBER DDESCRIPTIONESCRIPTION Tech. Objective 1

(16)

Because technical objectives should be trace-able to specific Business Objective, when there is more than one business objective, it would be advisable to present the technical objectives in a hierarchical manner: The following is an example of such a presentation of technical objectives.

N

Bus. Objective 1 Reduce cost of government operations through IT

Tech. Objective 1 Identity Management and Directory Services

Tech. Objective 2 Common Business Functions and data interchange and discovery methodology for all agencies to access and use for report creation.

Bus. Objective 2 Reduce cost of IT operations through an enterprise Model

Tech. Objective 4 Common IT service architecture and operating environment, including Standards, SLA (Service Level Agreements) approach, governance model and improved funding mechanism

3.2 PROJECT EXCLUSIONS

The project should list items, features, would like to haves that stakeholders might associate with this project but that the project would not be providing.

3.3 CRITICAL SUCCESS FACTORS

Identify the critical success factors for achieving success in this project. Metric are key to understanding the ability of the project to meet the end goals of the Executive Sponsor and the Business Owner, as well as the ability of the project team to stay within schedule and budget.

NUMBER

NUMBER DESCRIPTIONDESCRIPTION QUALITY METRICS

1

4.0 PROJECT DELIVERABLES AND METHODOLOGY

A deliverable is any measurable, tangible, verifiable outcome, result, or item that is required to complete a project or part of a project. The term is often used more narrowly in reference to an external deliverable (i.e. this deliverable is subject to approval by the project sponsor or

customer). Analyze the project scope and objectives outlined in the Project Proposal and Charter to develop a list of deliverables.

(17)

In its efforts to move from the high level business objectives to the desired end product/service the project team will need to deliver specific documents or work products. The State of New Mexico Project Management Methodology distinguishes between the project and the product. Project Deliverables relate to how we conduct the business of the project. Product Deliverables relate to how we define what the end result or product will be, and trace our stakeholder

requirements through to product acceptance, and trace our end product features and attributes back to our initial requirements

4.1 PROJECT MANAGEMENT LIFE CYCLE

The project should present here a summary of its approach, and its phases:

Phase Summary of Phase Key Deliverables

Here is some background:

The following is a description of a Project Management Life Cycle based on the PMI (Project Management Institute’s PMBOK©.

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

(18)

Initiating:

Project Charter Project Scope

Business Requirements – Business Case Assumptions

Constraints

Authorization to proceed with planning

Planning:

Project Plan

Critical success factors Work Break down Structures Project Schedule

Controlling:

Performance/Status Reports Corrective Action

Measurement Metrics Plan Change Requests Product Change Request Risk Management Issues Management

Execution:

Actual efforts

Project Deliverables completion

Closing:

Deliverable or Product Acceptance Lessons Learned

As a companion to the five major project processes, PMI through the PMBOK has instituted nine management focuses that will be followed in this project:

(19)

The purpose of integration management is to ensure coordination of the different elements of a project to achieve the needs and expectations of project stakeholders. It includes project plan development, project plan execution, and integrated overall change control.

Scope Management

The purpose of scope management is to ensure the work performed in a project is necessary to the successful completion. It includes initiation, scope planning, scope definition, scope verification, and scope change control.

Time Management

The purpose of time management is to ensure a project completes in a timely manner. It includes activity definition, activity sequencing, activity duration estimating, schedule development, and schedule control.

Cost Management

The purpose of cost management is to ensure a project completes within its approved budget. It includes resource planning, cost estimating, cost budgeting, and cost control.

Quality Management

The purpose of quality management is to ensure the products and services produced by a project satisfy the needs for which the project was undertaken. Quality – the satisfaction of project needs – is a measure of adherence to stated requirements combined with fitness for use. The Quality Management Knowledge Area includes quality planning, quality assurance, and quality control.

Human Resource Management

The purpose of human resource management is to ensure effective use of the people involved in a project. It includes organizational planning, staff acquisition, and team development.

Communications Management

The purpose of communications management is to ensure timely and effective flow of information for a project. It includes communication planning, information distribution, performance reporting, and administrative closure.

Risk Management

The purpose of risk management is to ensure the identification, analysis, and appropriate response to the risks encountered by a project. It includes risk management planning, risk

identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control.

Procurement Management

The purpose of procurement management is to ensure effective acquisition of products and services from sources external to the project’s organization. It includes procurement planning, solicitation planning, solicitation, source selection, contract administration, and contract closeout.

(20)

Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project. Examples are project, phase, and iteration plans, and project schedules. Project Deliverables must be reviewed and approved by the project’s Executive Sponsor prior to their implementation.

Description - Deliverable description conveys the features and/or the functions that will be

included in the project product. Each deliverable is a subsidiary element of the project product (final deliverable), each with its own separate but interdependent deliverable scope

Deliverable Acceptance Criteria - Acceptance Criteria are quantifiable measures of the success

of each deliverable (or set of deliverables). Its how the executive sponsor and the project team know when a deliverable is acceptable and can be approved. Acceptance criteria are similar to measures of success except they are for a specific deliverable. The criteria may include

functional and technical testing and utility verification at defined points in the process; methodology and criteria should be published.

Standards for Content and Format - Standards for Content and Format describe the format

that the executive sponsor can expect to receive the deliverable. This section ensures that the deliverable will be usable to meet its objective upon delivery. The tools, techniques, and

processes used to develop the deliverable must compliment the executive sponsor’s environment and enable the executive sponsor to use the deliverable

Quality Review - Quality review provides the opportunity for peer and cross-discipline reviews

of the deliverable. This process will improve the Quality Control metrics by reducing the testing cycle and the number of exceptions reported by Quality Control and eventually the executive sponsor.

4.1.1.1 [Deliverable 1 Name]

Description - Deliverable Acceptance Criteria - . Standards for Content and Format -

Quality Review -

4.1.1.2 [Deliverable 2 Name]

(21)

Standards for Content and Format - Quality Review -

4.1.2 D

4.1.2 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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.

D

DELIVERABLEELIVERABLE

N

NUMBERUMBER

D

DELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CAN

CANAPPROVEAPPROVE))

D DATEATE

A

APPROVEDPPROVED PRJ-DEL-001 Project Management Plan (PMP)

4.1.3 D

4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Describe the process that this project will use for the formal acceptance of all deliverables. Generally, a Deliverable Acceptance Form is utilized with specific timeframes allowed for review, approval, rework, etc. Issues identified in this Deliverable Acceptance Procedure should follow the Issues Escalation Process that is defined in a later section.

4.2 PRODUCT LIFE CYCLE

This section is intended to have the project present the product development life cycle. “During the project management lifecycle, agencies shall select and implement a phase product

development lifecycle methodology approved by the Department.” PROJECT OVERSIGHT PROCESS Memorandum

(22)

example is presented here. What is a product life cycle?

“A collection of generally sequential project phases whose name and number are determined by the control needs of the organization or organizations involved in the project. “ Project Management Institute’s PMBOK Guide 2000, Glossary p. 205 .

The Product Life Cycle includes identifiable and distinct phases, each of which encompasses the critical five project management processes. Each phase has its own initiation, plan, execute and control aspects and each will have its own close process. The close process or gate will include project approval to enter the next phase of the project.

Where the DoIT Project Management Office has not yet published product life cycle

development templates to use, projects have used documents similar to those mentioned in this approach. The following is a high level description of project document-deliverables per phase

Initiation

Product development Rationale End Vision and purpose

Project Scope

Plan

Work Breakdown Schedules Project Schedule

Business Requirements Initial technical requirements

Initial deployment and transition to operations plan Initial Operations and Support Plan

(23)

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 Criteria

Pilot

Systems Design Documents applied Training Materials ready

Pilot Run, Evaluated Pilot Acceptance

Deploy

Systems Design Documents applied Training Materials Used

Deployment and transition to operations plan Operations and Support Plan

(24)

4.2.1 T

4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

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 P

4.2.2 PRODUCTRODUCTANDAND P PRODUCTRODUCT D DEVELOPMENTEVELOPMENT D DELIVERABLESELIVERABLES

Product Deliverables are work products or artifacts that are driven by the product management methodology requirements and standard project management practices regardless of the product requirements of the project. Examples are project, phase, and iteration plans, and project schedules. Product Deliverables must be reviewed and approved by the project’s Executive Sponsor prior to their implementation.