· Web view“Project manager” is a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan,

PIPELINEPIPELINE SAFETYSAFETY BUREAUBUREAU

O ONLINENLINE P PIPELINEIPELINE I INSPECTIONNSPECTION D DATAATA RREPORTINGEPORTING S SYSTEMYSTEM

PROJECT MANAGEMENT PLAN PROJECT MANAGEMENT PLAN (PMP)(PMP)

EXECUTIVE SPONSOR – JOHNNY MONTOYA, CHIEF OF STAFF

BUSINESS OWNER - JASON MONTOYA

PROJECT MANAGER – NANDA KUMAR

ORIGINAL PLAN DATE: NOVEMBER 21, 2011REVISION DATE: NOVEMBER 3, 2011

REVISION: 0.1

PROJECT MANAGEMENT PLAN FOR PIPELINE SAFETY BUREAU

REVISION HISTORY............................................................................................................................................. III

PREPARING THE PROJECT MANAGEMENT PLAN................................................................................................. IV

ABOUT THIS DOCUMENT................................................................................................................................... IV

PROJECT OVERSIGHT PROCESS MEMORANDUM – DOIT, JULY 2007.................................................................................... IV

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

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT....................................................................................................11.2 FUNDING AND SOURCES...........................................................................................................................................11.3 CONSTRAINTS........................................................................................................................................................11.4 DEPENDENCIES.......................................................................................................................................................11.5 ASSUMPTIONS...................................................................................................................................................21.6 INITIAL PROJECT RISKS IDENTIFIED...........................................................................................................................2

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................3

2.1 STAKEHOLDERS......................................................................................................................................................32.2 PROJECT GOVERNANCE STRUCTURE...........................................................................................................................4

2.2.1 Describe the organizational structure – Org Chart.....................................................................................42.2.2 Describe the role and members of the project steering committee...........................................................42.2.3 Organizational Boundaries, interfaces and responsibilities.......................................................................5

2.3 EXECUTIVE REPORTING............................................................................................................................................5

3.0 SCOPE........................................................................................................................................................... 6

3.1 PROJECT OBJECTIVES..............................................................................................................................................63.1.1 Business Objectives....................................................................................................................................63.1.2 Technical Objectives..................................................................................................................................6

3.2 PROJECT EXCLUSIONS..............................................................................................................................................73.3 CRITICAL SUCCESS FACTORS.....................................................................................................................................7

4.0 PROJECT DELIVERABLES AND METHODOLOGY...............................................................................................7

4.1 PROJECT MANAGEMENT LIFE CYCLE..........................................................................................................................74.1.1 Project Management Deliverables.............................................................................................................84.1.2 Deliverable Approval Authority Designations............................................................................................94.1.3 Deliverable Acceptance Procedure...........................................................................................................10

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................104.2.1 Technical Strategy...................................................................................................................................104.2.2 Product and Product Development Deliverables......................................................................................104.2.3 Deliverable Approval Authority Designations..........................................................................................114.2.4 Deliverable Acceptance Procedure...........................................................................................................11

5.0 PROJECT WORK........................................................................................................................................... 11

5.1 WORK BREAKDOWN STRUCTURE (WBS)..................................................................................................................115.2 SCHEDULE ALLOCATION -PROJECT TIMELINE..............................................................................................................125.3 PROJECT BUDGET.................................................................................................................................................135.4 PROJECT TEAM....................................................................................................................................................13

5.4.1 Project Team Organizational Structure....................................................................................................135.4.2 Project Team Roles and Responsibilities..................................................................................................14

5.5 STAFF PLANNING AND RESOURCE ACQUISITION................................................................................................155.5.1 Project Staff.............................................................................................................................................155.5.2 Non-Personnel resources.........................................................................................................................15

5.6 PROJECT LOGISTICS.........................................................................................................................................15

REVISION: 1.0 DOIT-PMO-TEM-020 i OF vi


5.6.1 Project Team Training..............................................................................................................................15

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................16

6.1 RISK AND ISSUE MANAGEMENT..............................................................................................................................166.1.1 Risk Management Strategy......................................................................................................................166.1.2 Project Risk Identification........................................................................................................................166.1.3 Project Risk Mitigation Approach............................................................................................................166.1.4 Risk Reporting and Escalation Strategy...................................................................................................166.1.5 Project Risk Tracking Approach................................................................................................................176.1.6 ISSUE MANAGEMENT..............................................................................................................................17

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V...........................................................................................186.3 SCOPE MANAGEMENT PLAN..................................................................................................................................19

6.3.1 Change Control........................................................................................................................................206.4 PROJECT BUDGET MANAGEMENT............................................................................................................................21

6.4.1 Budget Tracking.......................................................................................................................................226.5 COMMUNICATION PLAN........................................................................................................................................22

6.5.1 Communication Matrix............................................................................................................................226.5.2 Status Meetings.......................................................................................................................................236.5.3 Project Status Reports..............................................................................................................................23

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................236.6.1 Baselines..................................................................................................................................................246.6.2 Metrics Library.........................................................................................................................................24

6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................246.7.1 quality Standards.....................................................................................................................................246.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................256.7.3 Agency/Customer Satisfaction.................................................................................................................256.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................26

6.8 CONFIGURATION MANAGEMENT...................................................................................................................266.8.1 Version Control........................................................................................................................................276.8.2 Project Repository (Project Library).........................................................................................................27

6.9 PROCUREMENT MANAGEMENT PLAN............................................................................................................27

7. 0 PROJECT CLOSE........................................................................................................................................... 28

7.1 Administrative Close........................................................................................Error! Bookmark not defined.7.2 Contract Close.................................................................................................Error! Bookmark not defined.

ATTACHMENTS................................................................................................................................................. 29

REVISION: 1.0 DOIT-PMO-TEM-020 ii OF vi


REVISION HISTORYREVISION HISTORY

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0 April 10, 2012 Original PRC/Pipeline Safety Bureau Project PMP Doc

2.0 June 2012 Added

2.1

2.2

REVISION: 1.0 DOIT-PMO-TEM-020 iii OF vi


PREPARING THE PROJECT MANAGEMENT PLANPREPARING THE PROJECT MANAGEMENT PLAN

The workbook for preparation of the Project Management Plan is built around helping the project manager and the project team to use the Project Management Plan in support of successful projects. Please refer to it while developing this PMP for your project.

ABOUT THIS DOCUMENTABOUT THIS DOCUMENT

Project Oversight Process Memorandum – DoIT, July 2007Project Oversight Process Memorandum – DoIT, July 2007

“Project management plan” is a formal document approved by the executive sponsor and the Department and developed in the plan phase used to manage project execution, control, and project close.

The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost and schedule baselines.

A project plan includes at least other plans for issue escalation, change control, communications, deliverable review and acceptance, staff acquisition, and risk management.

“Project manager” is a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department.

“Project product” consists of the final project deliverables as defined in the project plan meeting all agreed and approved acceptance criteria.

“Product development life cycle” is a series of sequential, non-overlapping phases comprised of iterative disciplines such as requirements, analysis and design, implementation, test and deployment implemented to build a product or develop a service.

REVISION: 1.0 DOIT-PMO-TEM-020 iv OF vi


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.

1.1 1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECTEXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The Project Management Plan is for consolidation and upgrading of the existing Pipeline Inspection System into a Web Portal. Currently, the Pipeline Safety Bureau has a mechanism where the inspectors fill out the applications on a word document and paper, the inspections results are submitted to the agency only on the arrival of the inspector. The web portal application will allow the user to save, retrieve and submit the inspection results over the web and also enable the user to send supporting documents and files to the bureau.Apart from being a user friendly enhancement in the bureau, it a cost effective process which has been already presented to the Commission.

The original project converted a 21 page compliance inspection MS Word document into a web based on-line/data collection application using existing hardware. The additional scope will be to convert the remaining 26 forms.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCES

SOURCESOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

Federal Funds Pipeline Safety Fund

$150,000.00 EXPIRING JUNE 30, 2012

PRC

Federal Funds Pipeline Safety Fund

$155,000.00 EXPIRING JUNE 30, 2013

PRC

1.3 CONSTRAINTS1.3 CONSTRAINTSConstraints are factors that restrict the project by scope, resource, or schedule.

NNUMBERUMBER DDESCRIPTIONESCRIPTION

1 The appropriate funds for phase 1 will expire on June 30, 2012. The current fund request will be used for the development and implementation of web based data reporting system.

2 The appropriate funds for phase 2 will expire on June 30, 2012. The current fund request will be used for the development and implementation of web

PAGE | 1



based data reporting system.

1.4 DEPENDENCIES1.4 DEPENDENCIESTypes include the following and should be associated with each dependency listed.

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.

E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement

NUMBENUMBERR

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

1 PIPELINE SAFETY INSPECTORS M

1.5 1.5 ASSUMPTIONSASSUMPTIONSAssumptions are planning factors that, for planning purposes, will be considered true, real, or certain.


1 CURRENT SERVERS WILL HANDLE THE LOAD OF THE NEW APPLICATION.

1.6 INITIAL PROJECT RISKS IDENTIFIED1.6 INITIAL PROJECT RISKS IDENTIFIEDIn 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.

Risk 1

PAGE | 2


Funding expires prior to completion of the project including all phases.

Probability Impact

Mitigation Strategy:The Agile Project management methodology will be used. The Agile method allows a component of the project to be delivered at the end of each Sprint; allowing for a portion of the project to be completely delivered if the project deadline has not been met before the funding expires.

Contingency Plan:The pipeline safety bureau will request the Agency to fund the project or a portion of the project.

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL 2.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 the hierarchical configuration of those groups. It exists to clarify interaction with the project team.

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

NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Jason Marks

Patrick H. Lyons

Douglas J. Howe

Theresa Becenti – Aguilar

Ben L. Hall

Constitutional regulatory authority over the business of insurance; elective office.

Public Regulation Commission

Commissioner

Jason Montoya and Pipeline Safety Inspectors

Primary point of contact within the Pipeline Safety Bureau for it projects.

PRC Pipeline Safety Bureau

Bureau Chief

Matthew Lovato Acting Administrative Services Director.

PRC ASD PRC CFO

PAGE | 3


NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Nanda Kumar IT OPERATIONS STAFF PRC ASD IT Division

PRC CIO

2.2 PROJECT GOVERNANCE STRUCTURE2.2 PROJECT GOVERNANCE STRUCTURE2.2.1 D2.2.1 DESCRIBEESCRIBE THETHE ORGANIZATIONALORGANIZATIONAL STRUCTURESTRUCTURE – O – ORGRG C CHARTHART

PAGE | 4


2.2.2 D2.2.2 DESCRIBEESCRIBE THETHE ROLEROLE ANDAND MEMBERSMEMBERS OFOF THETHE PROJECTPROJECT STEERINGSTEERING COMMITTEECOMMITTEE

Executive Level The point person for the project within the highest level of the Public Regulation Commission or Pipeline Safety.

Responsibilities include: Champion the project Consider potential changes facing the organization and assess

the organizational impact Decide which changes will be instituted, communicate

priorities and provide resources to ensure success Responsible for creating an environment that enables changes to be made on time and within budget Participate in planning sessions Ultimate project responsibility

PAGE | 5


Steering Committee Member

Is chartered to provide governance over the direction and support of the project.

Responsibilities include: Attend and participate in meetings Review and accept deliverables Review and provide comment on presented documentation Balance larger picture versus details of the project Review project funding and expenditures Champion the project Contribute to lessons learned

Project Managers, DBA and the Developers

Responsible for oversight and management of project teams.

Responsibilities include: Close coordination of all facets of the project Work jointly on management of project tasks Coordination of resources and responsibilities from respective

areas

2.2.3 O2.2.3 ORGANIZATIONALRGANIZATIONAL B BOUNDARIESOUNDARIES, , INTERFACESINTERFACES ANDAND RESPONSIBILITIESRESPONSIBILITIES

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: Boundary, interface and responsibilities at the interface

2.3 EXECUTIVE REPORTING2.3 EXECUTIVE REPORTINGThe CIO or project managers will compile monthly status reports for review by Project Executives and the Project Steering Committee. These reports will include a general status update of the project, milestones (achieved, in progress), major risks, change requests, and any other items needing executive review.

Project status will be reviewed with CIO (IT) on a bi-weekly basis.

3.0 SCOPE3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1 PROJECT OBJECTIVES

PAGE | 6


3.1.1 B3.1.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES


Business Objective 1 To develop a web based application to gather, review and store the data electronically and convert paper records to electronic format and move towards a full paperless environment.

Business Objective 2 Design the application which allows the Pipeline Inspectors to store and the inspection forms at different instances during the inspection. The session will enable the Inspectors to come back resume the inspection from the last login session.

Business Objective 3 Develop a feedback system in the Bureau which allows the Inspectors to submit the Inspection results remotely. The results will be submitted to the QA/QC team to comment and correct the results.

Business Objective 4 Design a module which would inform/ highlight the inspector about the exact inspection procedure which has a query raised by a QA/QC official.

3.1.2 T3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


Tech Objective 1 Review, inventory and document the existing business processes, types of documents stored, archival requirements for each document type, and the computing systems utilized by the PRC Pipeline Safety Bureau.

Direct interviews with selected PSB and IT staff members will be conducted. This review will encompass the current state of paper and electronic document handling, and associated computing systems develop the web based data reporting system.

Tech Objective 2 Inspection files and documents will be secure and efficient as the activity will be logged electronically.

Tech Objective 3 Reduce the load on internal State staff for maintenance and support.

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONS

PAGE | 7


The major exclusion will be the in house inspection report submission; currently after each inspection all the inspectors come and report the inspection results to the QA QC team. With the web based application the inspection results can be submitted over the web.

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. See also section 6.7 Quality Objectives and Controls.

NUMBERNUMBER DESCRIPTIONDESCRIPTION

QUALITY METRICS 1 END USER

The Pipeline Safety Inspectors will able to do the inspection and record the data electronically and can submit the data for review immediately.

QUALITY METRICS 2 BUSINESS PROCESSES

Appropriate project implementation will assure consistent application of business processes, promote supervision, and provide ready access to necessary information

QUALITY METRICS 3 IT OPERATIONS AND STAFFING

The system selected and implemented should run on hardware, operating system and databases that are the same as or similar to those which are already implemented within the agency in order to leverage the existing knowledge and abilities of IT support staff.

4.0 PROJECT DELIVERABLES AND METHODOLOGY4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables

InitiatingScope engagement with client and formulate strategic relationship.

Project Charter, Assumptions, Constraints, Contract

PlanningDefining project parameters and building shared vision for solution delivery.

Project Plan, Work Breakdown Structure, Project Schedule

Executing Delivering the solution in phases Complete work and deliverables (Enhancements, System Testing, Training, Acceptance Testing,

PAGE | 8


Implementation)

Controlling (Monitoring)Monitoring the execution and controlling variances to quality, time, and scope.

Status Reports, Maintain Schedule, Risk/Issue Management, Quality Assurance, Variance Analysis

ClosingConclusion and closure of project activities following deployment of solution.

Product Acceptance, Transition to Operations and Support

4.1.1 P4.1.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

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.

4.1.1.1 Facilitate Task Coordination for a Secure Online Data Gathering and Reporting System

Task Coordination and Meetings with Key Staff Members to Facilitate a Design of an Online Data Gathering and Reporting Information System.

Deliverable Acceptance Criteria: – Documents meets NM DoIT standards, where specified. When DoIT standards do not exist,

Standards for Content and Format - - Where possible, DoIT templates, and enclosed guidelines will be used. When a DoIT template is not available, Contractor will submit their template for approval by the project management team.

Quality Review -.User Acceptance Test

4.1.1.2 Gather Requirements and Document Workflow for a Secure Online Data Gathering and Reporting System Programming Services

Gather Requirements and Workflow Information to Design a Secure Data Gathering and Reporting Information System.




4.1.1.3 Testing of a Secure Online Data Gathering and Reporting System

PAGE | 9


Gather Requirements and Workflow Information to Design a Secure Data Gathering and Reporting Information System.




4.1.1.4 Gather Requirements and Document Workflow for a Secure Online Data Gathering and Reporting System Programming Services

Testing a Secure Online Data Gathering and Reporting Information System.




4.1.1.5 Deployment of a Secure Online Data Gathering and Reporting System

Deploy a Secure Online Data Gathering and Reporting Information System.




4.1.2 D4.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.

PAGE | 10


DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

PRJ-DEL-001 Project Management Plan (PMP)

4.1.3 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Upon completion of agreed upon Deliverables as set forth in Contract and Exhibit A of the contract, the Contractor shall submit a Payment Invoice with the Deliverable, or description of the Deliverable, to the Project Manager. Each Payment Invoice shall be for the fixed Deliverable price as set forth in Contract and Exhibit A of the contract, less retainage, if applicable.

4.2 PRODUCT LIFE CYCLE4.2 PRODUCT LIFE CYCLE “During the project management lifecycle, agencies shall select and implement a phase product development lifecycle methodology approved by the Department.” PROJECT OVERSIGHT PROCESS Memorandum

Phase Summary of Phase Key Deliverables

Phase 1 Deliver Base functionality as outlined in Contract 12-430-P612-14533.

Convert a 25 page compliance inspection MS Word document into a web based on-line/data collection application

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

The application will be built on Microsoft Visual Studio 4.0 Framework and will be deployed on existing Hardware.

4.2.2 P4.2.2 PRODUCTRODUCT ANDAND 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.

Refer 4.1.1

4.2.3 D4.2.3 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.

PAGE | 11


DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

1 Foundation and Report 1 Agency CIO

2 Reports 2 - 26 Agency CIO

4.2.4 D4.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Upon completion of agreed upon Deliverables as set forth in Contract and Exhibit A of the contract, the Contractor shall submit a Payment Invoice with the Deliverable, or description of the Deliverable, to the Project Manager. Each Payment Invoice shall be for the fixed Deliverable price as set forth in Contract and Exhibit A of the contract, less retainage, if applicable.

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. Describe the work activities that comprise the work breakdown structure (WBS) or the work packages within the WBS. Identify the WBS element or other work package identifier and provide a general description of the tasks or activities, the definition or objectives, and the milestones and deliverables of each work package.

Use the chart below for highest level presentation, and provide a more detailed WBS as an attachment to this project plan.

PAGE | 12


Identifier Work Package Description Definition/Objective Milestone/Deliverable

WB1 Project Management Plans As per the Contract 12-430-P612-14533.

Plan acceptance.Signed Deliverable Acceptance Form

WB2 Phase 1 Requirements Definition

As per the Contract 12-430-P612-14533.

Signed Deliverable Acceptance Form

WB3 Phase 1 Design As per the Contract 12-430-P612-14533.

Design acceptance.Signed Deliverable Acceptance Form

WB4 Phase 1 Development As per the Contract 12-430-P612-14533.


WB5 Phase 1 Testing As per the Contract 12-430-P612-14533.


WB6 Phase 1 Implementation As per the Contract 12-430-P612-14533.


WB7 Phase 2 – Reports 2-26 As per the Contract TBD Signed Deliverable Acceptance Form

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE5.2 SCHEDULE ALLOCATION -PROJECT TIMELINEThe project timeline is a high-level view of project activities with a focus on project milestones. The project timeline does not replace the need for a detailed project schedule and it is to highlight key events such as deliverable due dates and when go/no-go decisions are made.

The table below should provide a high level view of the project time line, or a summary-level Gantt chart can be used to meet the timeline requirement.

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

PAGE | 13

Beltemacchi, Laura, 06/13/12,

How about added the schedule from the cert form? (See on next page) This one is out of date.


MMAJORAJOR D DELIVERABLEELIVERABLE S SCHEDULECHEDULE ANDAND P PERFORMANCEERFORMANCE M MEASURESEASURES

MMAJORAJOR P PROJECTROJECT D DELIVERABLEELIVERABLE ANDAND PPERFORMANCEERFORMANCE M MEASUREEASURE

DDUEUE D DATEATE PPROJECTROJECT PPHASEHASE

Phase 1: Form 1

Project Coordination 12/02/11 Planning & Im-plementation

Gather Requirements 1/13/12 Planning

Design and Develop 2/24/12 Implementation

Testing 3/22/12 Implementation

Deploy 05/16/12 Implementation

Total

Phase 2: Form 2 - 26

Project Coordination 12/02/11 Planning & Im-plementation

Gather Requirements 1/13/12 Planning

Design and Develop 2/24/12 Implementation

Testing 3/22/12 Implementation

Deploy 05/16/12 Implementation

Total

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; 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).

PAGE | 14


Identifier Work Package or Budget Category Cost

PHASE 1 As per the Contract 12-430-P612-14533. $150,000

PHASE 2 As per the Contract TBD $155,000

Totals $305,000

5.4 PROJECT TEAM5.4 PROJECT TEAM5.4.1 P5.4.1 PROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL S STRUCTURETRUCTURE

The Organizational Structure (OS) is a hierarchical configuration defining levels of program management and may identify all project personnel. The OS should be simple and straightforward. Include role names and people’s names. Consider identifying the core project team by shading their respective boxes on the chart. On complex projects, consider using a second OS to identify core project team. The OS can also be used for management reporting.

PAGE | 15


5.4.2 P5.4.2 PROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES

List the team members, their role, responsibility and functional manager. Make sure to include a comprehensive listing including those from the organization managing the project, business members involved to ensure business objectives are met and the vendor members that may have a specific role.

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL AAREAREA

Business Owner Ensure all resources necessary for project success are provided by the appropriate Division. Ensure timely review of all documents.

Jason Montoya Pipeline Safety Division

IT PM Internal and external status reports, including budget updates.

Nanda Kumar All

DOC Tech Contractors




5.5 STAFF PLANNING AND RESOURCE ACQUISITION5.5 STAFF PLANNING AND RESOURCE ACQUISITIONComplete the chart below identifying the project team members and details concerning their project commitment. Project staff should include State, Contract, Customer (Business Owner), or Vendor team members

PAGE | 16


5.5.1 P5.5.1 PROJECTROJECT S STAFFTAFF

Resource Cost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Business Owner 0 160 Available Pipeline Safety

Ensure all resources necessary for project success are provided by the appropriate Division. Ensure timely review of all documents.

IT Project Manager 0 400 Available PMP Internal and external status reports, including budget updates. Contract Management.

5.5.2 N5.5.2 NONON-P-PERSONNELERSONNEL RESOURCESRESOURCES

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

Resource Cost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

None All hardware and software required for the end solution will be owned, installed and maintained by ACS and the cost will be included in hosting.

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

5.6.1 P5.6.1 PROJECTROJECT T TEAMEAM T TRAININGRAINING

Not applicable. End User, Administrator training only.

6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1 RISK AND ISSUE MANAGEMENTPMBOK©:

Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”

PAGE | 17


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

Both Risks and Issues can significant impact a project’s success, and both should be handled in similar ways.

6.1.1 R6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

Provide a detailed explanation on the strategy for how risks are identified, analyzed/ quantified, mitigated, reported, escalated and tracked. Included the use of tools such as project management software, forms, and templates. A separate risk management plan may also be developed if needed for the project and included as an Appendix to this document. If that is the case, a high level summary of this plan needs to be included here with the specific reference.

6.1.2 P6.1.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

The project team will perform a high-level risk assessment of the degree of risk that the project faces based on overall project characteristics, and will create an initial set of overall risks.

This high-level risk assessment will be done at the beginning of the project start-up phase, and as per the project schedule, and more frequently if significant change causes major re-planning.

Everyone on the team is responsible to communicate any identified risks.

6.1.3 P6.1.3 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

For each identified risk a mitigation approach will be identified to minimize the likelihood of occurrence and impact on the project.

6.1.46.1.4 RRISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

The risks will be escalated for visibility or information if the Project Manager assesses that leadership needs awareness of the risk

Risks will be escalated for leadership action or resolution if

An effective risk response cannot be developed at the project manager level. A Contingency Plan has not been formulated within an acceptable timeframe (for

example, risk event is to occur within 30 days, the plan must be in place within 7 days; or, a risk event is to occur in 6 months, the risk plan should be in place with 30 days of the date the risk was identified).

An identified risk has not been acted upon within a maximum of two weeks from the date identified.

If escalation is considered necessary, leadership will be notified according to the project’s escalation path, indicating whether the risk is being escalated for action, resolution, visibility or information only. The Contingency Plan will be updated with the name and date that the escalation occurred. The risk will be tracked until closed.

PAGE | 18


6.1.56.1.5 PPROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

The following monitoring intervals will be applied at the execution phase and will conclude at Project Close Down:

• The status of risks and mitigating actions taken will be reviewed at a minimum monthly.• A status report on weekly basis is developed for active issues, risk activities and

emerging risks that will be provided to the CIO/ Project manager. • Risks that cannot be managed at the project level will be escalated to leadership for

action or resolution. • Risks associated with change requests and the impact on the project will be reviewed

during the project change control process.

During risk reviews, risks will be examined to determine if the status has changed, and to ensure the current analysis of the risk is valid. The impact, probability, and approach will be reviewed and updated – including the creation of Contingency Plans, if necessary.

Contingency Plans will be reviewed according to the documented frequency within the Risk

6.1.66.1.6 ISSUE MANAGEMENTISSUE MANAGEMENT

The continuous project tracking process will assist the team identify and highlight the problematic issues. The project status tracker sessions will facilitate the team to proactively identify, track, highlight and resolve the issues quickly.

6.1.6.1 Internal Issue Escalation and Resolution ProcessThis internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality. This process should be used for improving project processes as the project is executed and where the implementation of such improvements should not be postponed to Lessons Learned during Project Close.

PAGE | 19


6.1.6.2 External Issue Escalation and Resolution ProcessThe 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&VIndependent Verification and Validation (IV&V) means the process of evaluating a system to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the development organization. Describe the process that will be employed to meet IV&V requirements.

PAGE | 20


6.3 SCOPE MANAGEMENT PLAN6.3 SCOPE MANAGEMENT PLANScope management and change control are critical to maintaining schedule, achieving the desired outcomes on time, deploying on time, and delivering to the expected level of quality.

Project scope is not static and may evolve, which emphasizes the importance of proper scope control. Project scope management is conducted in the context of program-level integrated planning and dependency management, allowing alignment between individual stages of the project and other concurrent efforts to produce the desired project results.

The scope management process includes:

Maintaining contractual compliance and overseeing orderly revisions to the contract, if necessary, throughout project execution

Tracking contractual commitments and deliverables and monitoring progress toward completing them against contractual requirements and due dates

Identifying potential changes to project requirements, assessing the effect of each change about achieving the project’s final outcome within the stated time line, communicating with the customer, and revising the project plan accordingly

The scope management process defines project baselines about objectives, deliverables, expectations, and the overall effort at the onset of the project. Scope management is necessary to maintain and establish user expectations while also creating the schedule and key deliverables designated to meet project objectives.

The figure below illustrates the approach to scope management.

PAGE | 21


6.3.1 C6.3.1 CHANGEHANGE C CONTROLONTROL

6.3.1.1 Change Control ProcessThe Change Control Process defines how changes to project scope, schedule, and cost are identified and managed. Changes to requirements definition and software configuration follow this approach.

The key components of the change control process include the following:

Change request form

Change request tracking tools

Change control approval process

The change request form will include the required elements for executive level review and approval, including the following:

What is the requested change, including a summary of the required change?

Who is requesting the change? What is the start date for the change? What is the justification (reason and necessity)? What is the level of urgency for the required change? What elements of the system/project will be altered because of this change? What is the effect of the change on the project/program? What is the staffing plan associated with the change? What is the effect on the schedule for implementing the change? What is the cost effect to the project budget? What is the risk assessment and recommended approach to complete this change? Is it approved, denied, or deferred?

The figure below depicts the steps in the change management process.

PAGE | 22


6.3.1.2 Change Control Board (CCB)The Change Control Board (CCB) for the Pipeline Safety project will include the following participants who will be authorized to participate in to support review of and approval of changes to the project.

Participant Position

Nanda Kumar CIO

Jason Montoya Business Owner

Matthew Lovato CFO

6.4 PROJECT BUDGET MANAGEMENT6.4 PROJECT BUDGET MANAGEMENTCosts estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

PAGE | 23


6.4.1 B6.4.1 BUDGETUDGET T TRACKINGRACKING

Monthly reports from the Administrative Services Division include the project budget and a expenditure, encumbered POs and unencumbered POs for the project to date.

6.5 COMMUNICATION PLAN6.5 COMMUNICATION PLANCommunication planning involves determining the information and communication needs of the stakeholders, executive sponsors, project team and others as needed. The communication plan needs to address who needs what information, when they will need it, how it will be given to them, and by whom. The complexity of the project may require a separate communication plan; however a high level summary of that plan will need to be included here and a reference made to the appropriate Appendix.

6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

DDESCRIPTIONESCRIPTION TTARGETARGET A AUDIENCEUDIENCE DDELIVERYELIVERY MMETHODETHOD

FFREQUENCYREQUENCY RRESPONSIBLEESPONSIBLE P PARTYARTY

Project Communications Initiation

Bureau Chief/ CIO(IT)

In person Feb 21st and 27th CIO and Developers.

Process Management Consolidation

To discuss project activities, progress, issues and results of measurement and analysis activities.

Event driven:

When new requirements are added, existing requirements are changed, etc

Meeting attendees: Bureau Chief, Pipeline Compliance Staff, CIO(IT)

The process flow expression discussions; Meeting minutes are stored in the project repository.

In person March 2nd CIO, Pipeline Officer, Bureau Chief and Developers

Process Inputs:

To discuss the forms and the process of the inspection flow.

Meeting attendees:

Compliance Officer, Pipeline supervisor and Bureau chief. Emails exchanged confirming the process initiations, operator information and the total forms.

Email/ Word document

March 6th Compliance Officer and Developer.

PAGE | 24


Process Management Steering Committee

To address the accomplishments and results of the project with the Bureau. These meetings address commitments, plans, risks, status of activities and significant issues for the project, as well as how the project fits into the current business environment and the communication of the results of measurement and analysis activities.

Meeting Attendees

Bureau Chief, Pipeline Safety, Pipeline Inspectors, Compliance Officer IT team, CIO (IT) and DOIT representative

Meeting minutes are stored in the project repository.

In person/ Web link for the published mock up screens.

April 4th Developers

6.5.2 S6.5.2 STATUSTATUS M MEETINGSEETINGS

IT team and CIO (IT) will meet weekly to review the current status of the project and progress, review risks, identify and resolve issues, and plan project activities. An agenda will be prepared and minutes of each status meeting will be maintained in the project archive.

6.5.3 P6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

The status report will document the current status of the project, including deliverables, invoices, work performed, key issues, and high risks.

The IT team will prepare and submit bi – weekly status reports to the CIO to report the DOIT representative and the Bureau Chief.

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, resource usage, and error rates, and of establishing a historical database, which will aid in planning and forecasting future projects. At a minimum metrics must be established for time (schedule), cost (budget) and quality.

PAGE | 25


6.6.1 B6.6.1 BASELINESASELINES

Project Area Category MeasureSchedule Time A metric to determine if the

project is on schedule.Budget Costs Are project deliverables

within budget?

6.6.2 M6.6.2 METRICSETRICS L LIBRARYIBRARY

Due to the simplicity of this project, cost and schedule metrics will be included in the status report.

6.7 QUALITY OBJECTIVES AND CONTROL6.7 QUALITY OBJECTIVES AND CONTROLQuality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control, and quality improvement, within the quality system. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.

6.7.1 6.7.1 QUALITYQUALITY S STANDARDSTANDARDS

Describe the agency, industry or regulatory project performance standards that will be followed and assessed by the project. These quality standards will be used to assess whether the quality objectives were achieved.

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

PAGE | 26


No. Quality Standard Tracking Tool or Measure

1 Deliverables conform to style and grammar standards? Technical Writer review of deliverables

2 Are project status reports accurate and completed on time?

Agency-approved Status Report Template, E-mail Transmittals, Status Log

3 Are project issues being handled within appropriate timeframes and being escalated as appropriate (avoiding stale issues)?

Issues Log, Status Meeting Minutes

4 Are risks reviewed regularly with mitigation plans developed for high impact/probable risks?

Risk Log, Status Meeting Minutes

5 Is the project schedule current on the progress of project activities?

Project Schedule, Status Meeting Minutes

•

6.7.2 P6.7.2 PROJECTROJECT ANDAND P PRODUCTRODUCT R REVIEWEVIEW AND ASSESSMENTSAND ASSESSMENTSPhase Gate Reviews and Technical Reviews will be used as a mechanism to verify quality on the project. Project artifacts are reviewed by the review teams and meetings are held to discuss the findings. For both Phases I and Phase II of the project, the following reviews will occur:

Plan At the end of Project Planning MeasureSchedule Time A metric to determine if the

project is on schedule.Budget Costs Are project deliverables

within budget?

Plan At the end of Project Planning Phase GateArchitecture At the completion of the Architecture Plan TechnicalDesign At the end of Design Phase Gate and TechnicalPre-Deploy At the end of Test, prior to Release Phase Gate and Technical

In addition, an Independent Verification and Validation (IV&V) auditor will periodically audit the quality of the project. The auditor will interface directly with the Agency IT PM to perform these audits. The following deliverables will be monitored: Project Management Plan Project Schedule Project Risk/Issue Log Project Certification documents with acceptance

PAGE | 27


High-level design document Requirements documentation Interface descriptions Project Status Reports

6.7.3 A6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMER S SATISFACTIONATISFACTION

The project manager should assess the on-going sense of the customer agency about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members.

Examples:

Areas of feedback When How Often

Agency awareness Weekly Project Status meeting Weekly

Quality of communications As part of weekly status reporting and status reporting

Weekly

Manages project tasks Weekly Project Status meeting Weekly

Productive Meetings Weekly Project Status meeting Weekly

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESSHow 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.

Deliverable Final Approval Process Customer Acceptance Criteria

UAT Business OwnerIT PMSponsor

Approvals via the Deliverable Acceptance form.

Reports, Documentation, and Training

Business OwnerIT PM

Approvals via the Deliverable Acceptance form.

PAGE | 28


6.8 CONFIGURATION MANAGEMENT6.8 CONFIGURATION MANAGEMENTConfiguration Management determines how project information (files, reports, designs, memos, documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control, etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team awareness are critical.

Configuration Management will be applied across the life cycle of the project to provide the appropriate level of control for all project configuration items.

Each of these groups, listed below, consist of formally controlled configuration items (CIs). Changes to these formally controlled items are managed via change control:

Proposal Documents

Estimate Documentation

Requirements Documentation

Statement of Work

Supplier Statement of Work

Architecture

Design Specifications

Application Source and Executables

Business Organization Components

Bills of Materials

Build Construction Guides

Deployment Sources

The project will use Microsoft Team Foundation Server (TFS) for source code configuration management. TFS will be configured to control all source code for the NM MVD project. All configuration items are controlled within the repository using labels to manage the baselines. The versioning of Configuration Items (CIs) is handled using the native versioning within TFS and the integrity of the data is maintained through the implementation of access controls to prevent unauthorized changes.

6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

For each deliverable, the document’s title, completion date, and version will be included on the cover page. Documents will also maintain a Revision History to record major changes and updates to each deliverable. The following versioning for document deliverables will be followed:

Versioning

PAGE | 29


Major Version Definition

1.X Internal Draft

2.X Client Ready Draft

3.0 Accepted Final Deliverable

Minor revisions also will be reflected with changes to the numbers to the right of the decimal.

6.8.2 P6.8.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))

The Project Library is an electronic storage place where all documentation relating to the project is stored and maintained. The Pipeline Safety Inspection Project repository provides project specific information. This is a single source of project information for all stakeholders. The repository includes the following information:

Project Management- Project Management Plan- Project Schedule- Project Budget- Project status reports and meeting minutes

Architecture Plan Requirements

- Requirements Traceability Matrix- Use Cases / User Interface (UI) Documents- Letters, Forms, Reports Definition

Design Deliverables Test Deliverables Implementation Plan and Deliverables

6.9 PROCUREMENT MANAGEMENT PLAN6.9 PROCUREMENT MANAGEMENT PLANProjects often have some element of procurement, i.e. the requirement to purchase goods and/or services from outside the organization. The procedures to be used to handle these procurements should be included here. Activities such as a make-or-buy analysis; writing requirements; solicitation planning, evaluation and selection; inspection and acceptance; contract closeout should all be included.

7. 0 PROJECT CLOSE7. 0 PROJECT CLOSEThe tasks currently identified with Project Close are delineated in 7.1 and 7.2.

7.1 A7.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE

PAGE | 30


Activity Responsible Party Date

Conclude Project Control Agency

Reassign Team Agency

Appoint Support Contacts Agency

7.2 C7.2 CONTRACTONTRACT C CLOSELOSE

Contract close will not occur until the end of the support and maintenance period in contract. A partial close will be performed at the end of system UAT, which will include:

Activity Responsible Party

Date

Verify Project Objectives were met Agency

Verify Project Implementation

Deliverables were met and accepted

Agency

Complete Plan Components Agency

Complete Project Communications Agency

ATTACHMENTATTACHMENTSSAttachments 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

PAGE | 31