€¦ · web viewname stake in project organization title duffy rodriguez executive sponsor gsd...

GGENERALENERAL S SERVICESERVICES D DEPARTMENTEPARTMENT

AASSETSSET M MANAGEMENTANAGEMENT P PROJECTROJECT

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

EXECUTIVE SPONSOR – DUFFY RODRIGUEZ, GSD DEPUTY CABINET SECRETARY

BUSINESS OWNER – MICHAEL LUJAN, ASD DIRECTOR

PROJECT DIRECTOR – KAREN BALTZLEY, GSD CIO

PROJECT MANAGER – JOHN SALAZAR, CSW ENTERPRISES, LLC.

ORIGINAL PLAN DATE: JUNE 13, 2019

REVISION DATE: OCTOBER 10, 2019

REVISION: 1.0

PAGE | 1

REVISION HISTORY.............................................................................................................................................. 4

1.0 PROJECT OVERVIEW...................................................................................................................................... 5

1.1 Executive Summary- rationale for the Project...........................................................................................51.2 funding and sources..........................................................................................................................................61.3 constraints.........................................................................................................................................................61.4 Dependences.....................................................................................................................................................71.5 ASSUMPTIONS...................................................................................................................................................71.6 Initial Project Risks Identified..........................................................................................................................9

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...........................................................................11

2.1 Stakeholders....................................................................................................................................................112.2 Project Governance Structure.........................................................................................................................13

2.2.1 Describe the organizational structure – Org Chart...................................................................................132.2.2 Describe the role and members of the project steering committee.........................................................132.2.3 Organizational Boundaries, interfaces and responsibilities.....................................................................14

2.3 Executive Reporting.........................................................................................................................................15

3.0 SCOPE......................................................................................................................................................... 15

3.1 Project Objectives...........................................................................................................................................153.1.1 Business Objectives..................................................................................................................................15

3.2 Project exclusions............................................................................................................................................163.3 Critical Success Factors....................................................................................................................................16

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................17

4.1 Project Management Life Cycle.......................................................................................................................174.1.1 Project Management Deliverables...........................................................................................................184.1.2 Deliverable Approval Authority Designations..........................................................................................214.1.3 Deliverable Acceptance Procedure...........................................................................................................22

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................224.2.1 Technical Strategy...................................................................................................................................234.2.2 Product and Product Development Deliverables......................................................................................234.2.3 Deliverable Approval Authority Designations..........................................................................................274.2.4 Deliverable Acceptance Procedure...........................................................................................................27

5.0 PROJECT WORK........................................................................................................................................... 28

5.1 Work Breakdown Structure (WBS)..................................................................................................................285.2 Schedule allocation -Project Timeline.............................................................................................................325.3 Project Budget.................................................................................................................................................335.4 Project Team...................................................................................................................................................35

5.4.1 Project Team Organizational Structure....................................................................................................355.4.2 Project Team Roles and Responsibilities..................................................................................................36

5.5 STAFF PLANNING AND Resource Acquisition...................................................................................................375.5.1 Project Staff.............................................................................................................................................37

5.6 PROJECT LOGISTICS.........................................................................................................................................395.6.1 Project Team Training..............................................................................................................................40

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................41

6.1 Risk and issue Management............................................................................................................................416.1.1 Risk Management Strategy......................................................................................................................416.1.2 Project Risk Identification........................................................................................................................416.1.3 Project Risk Mitigation Approach............................................................................................................41

PAGE | 2

6.1.4 Risk Reporting and Escalation Strategy...................................................................................................426.1.5 Project Risk Tracking Approach................................................................................................................426.1.6 ISSUE MANAGEMENT..............................................................................................................................42

6.2 INDEPENDENT verification And Validation - Iv&V...........................................................................................436.3 Scope Management Plan.................................................................................................................................43

6.3.1 Change Control........................................................................................................................................436.4 Project Budget Management..........................................................................................................................44

6.4.1 Budget Tracking.......................................................................................................................................446.5 Communication Plan.......................................................................................................................................44

6.5.1 Communication Matrix............................................................................................................................456.5.2 Status Meetings.......................................................................................................................................466.5.3 Project Status Reports..............................................................................................................................46

6.6 Performance Measurement (Project Metric)..................................................................................................466.6.1 Baselines..................................................................................................................................................47

6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................476.7.1 quality Standards.....................................................................................................................................476.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................486.7.3 Agency/Customer Satisfaction.................................................................................................................48PRODUCT DELIVERABLE ACCEPTANCE PROCESS...............................................................................................496.7.5 Deliverable Acceptance Procedures.........................................................................................................50

6.8 CONFIGURATION MANAGEMENT...................................................................................................................516.8.1 Version Control........................................................................................................................................516.8.2 Project Repository (Project Library).........................................................................................................51

6.9 PROCUREMENT MANAGEMENT PLAN............................................................................................................52

7. 0 PROJECT CLOSE........................................................................................................................................... 52

ATTACHMENTS................................................................................................................................................. 52

APPENDIX A - ACRONYMS AND DEFINITIONS.....................................................................................................53

APPENDIX B – DELIVERABLE ACCEPTANCE FORM...............................................................................................62

Deliverable acceptance form.................................................................................................................................62

APPENDIX C – DELIVERABLE ACCEPTANCE LOG..................................................................................................63

Deliverable acceptance Log...................................................................................................................................63

APPENDIX D – PROJECT SCHEDULE.................................................................................................................... 64

Appendix e – Project Budget......................................................................................................................................66

PAGE | 3

REVISION HISTORYREVISION HISTORY

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

0.1 June 13, 2019 First Draft

1.0 October 10, 2019 Updated version to address comments and recommendations by DoIT EPMO

2.0

2.1

2.2

PAGE | 4

1.0 PROJECT OVERVIEW1.0 PROJECT OVERVIEW

1.11.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECTEXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The General Services Department (GSD) Statutory Mission is "to make state government more efficient and responsive through consolidating certain state government service functions; and to establish a single, unified department to administer laws as relating to services for governmental entities..." (Section 9-17-2 NMSA 1978). GSD's organizational mission is "to deliver innovative, responsive, cost-effective trusted services and solutions to exceed the diverse needs of state agencies."GSD is responsible for managing diverse assets throughout the State with a significant portfolio of assets under its care and control. This extensive inventory includes assets such as: real property, the state fleet, and equipment associated with enterprise operations. By statute, GSD is charged with managing these assets, which forms an integral part of providing quality services to the State.

In accordance with Section 12-6-10 NMSA 1978, GSD is to promulgate regulations requiring state agencies to account for and control fixed assets. GSD needs to implement a systematic and well-documented method for accounting for fixed assets with appropriate controls on access and authorization of transactions. GSD has an obligation to ensure that the current assets are managed efficiently and effectively.

GSD is interested in securing funding to move forward with the implementation of a fixed asset management system that has been tested within State government. At present, at least three of the State's largest agencies are successfully utilizing the SHARE Asset Management (AM) module. This request will enable the use of this module for GSD.

The Administrative Services Division (ASD) in GSD will provide professional guidance regarding the conversion and migration of fixed asset data from the COTS fixed asset system currently in use to the SHARE AM module. GSD will work with the Department of Information Technology (DoIT) SHARE team to configure SHARE AM to meet GSD business requirements.

The project will not require additional hardware or software products and will utilize the following PeopleSoft modules currently deployed and operational in the state of New Mexico: Asset Management; Purchasing; Accounts Payable; Project Costing and General Ledger. The project will utilize the existing PeopleSoft (SHARE) computing infrastructure housed at the Simms Data Center. Since there are already two large agencies using AM, the addition of GSD will only strengthen the value of the IT investment through enterprise models that improve and streamline the Executive Branch services.

PAGE | 5

The objective of this SHARE AM deployment for GSD is to focus on implementing the functionality needed to streamline the current business process related to fixed assets. This will improve accuracy, timeliness, and data integrity and enable GSD to meet industry best practices and standards, integrate and reconcile multi-site data, and provide real-time information needed for GSD to operate at peak performance.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCES

SOURCESOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

Laws of 2019, Chapter 271, Section 7, Item 11

$550,000.00 House Bill 2 – To implement the statewide human resources, accounting and management reporting system asset management module.

Department of Finance and Administration (DFA), and Legislative Finance Committee (LFC)

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

NNUMBERUMBER DDESCRIPTIONESCRIPTION

1 The project schedule coincides with a busy period for GSD/ASD employees as they will be working on Fiscal Year closeout. There may be some contention for resources as the SMEs are asked to participate in the project as well as carry out their daily tasks.

2 The project schedule will be carried out during the 2019 holiday season. There will be limited resource ability as staff will be absent due to vacation schedules.

3 DoIT resources, required to support the project, will be occupied with 2019 1099 and W2 processes during the January 2020 timeframe.

PAGE | 6

1.4 DEPENDENCES1.4 DEPENDENCESTypes 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. Migration of current data from legacy SunSystem application.

M

2. Maintenance of the SHARE system after go-live. Reporting Issues Escalation Plan for Reported Issues

D

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


1. The AM module is already activated in SHARE. Per earlier research, no additional hardware or software will be required.

2. All SHARE related support costs are already being incurred in annual fee being assessed to the agencies.

3. The existing SHARE configuration and documented business processes will be the baseline for configuring the GSD SHARE AM module.

4. Outside of GSD specific interfaces and reports, customizations will only be considered when required to meet statutory/regulatory requirements.

5. GSD will be responsible for data extraction for conversion from the legacy system and provide data in the format required by Deloitte.

6. GSD will be responsible for cleansing of existing data with guidance from Deloitte based on SHARE requirements.

PAGE | 7


7. Fully depreciated assets will not be converted into SHARE.

8. Both assets and accumulated depreciation will be converted, Purchase Orders and Vouchers will not be converted.

PAGE | 8

1.6 INITIAL PROJECT RISKS IDENTIFIED1.6 INITIAL PROJECT RISKS IDENTIFIEDThe following list identifies and describes how each risk will be managed. Steps that will be taken to maximize activity that will result in minimizing probability and impact of each risk are included.

Risk 1 – Fixed Asset Data Not Successfully MigratedDescription -

If the fixed asset data is not successfully migrated to the SHARE AM module, the project will be delayed, and additional costs may be incurred resulting in exceeding the requested appropriation amount.

Probability – MEDIUM Impact – MEDIUM

Mitigation Strategy –Follow the methodology used by previous agencies that has proven to be successful in migrating their fixed asset data to the SHARE AM module and hire PeopleSoft professionals experienced with the financial and AM modules. Contingency Plan - Identify data that can be migrated and use a phased approach until all data is migrated successfully.

RISK 2 – DATA INTEGRITY Description -

If data integrity does not exist at the time of migration, a reliable data transfer will be negatively impacted.

Probability – MEDIUM Impact – MEDIUM

Mitigation Strategy –All data currently contained in the legacy application must be analyzed and properly formatted prior to migrating to the SHARE AM. Data integrity must be validated by PeopleSoft consultants and GSD subject matter experts (SMEs). Contingency Plan - Contract with existing legacy system vendor to develop scripts to fix data anomalies before migrating data to the SHARE AM database.

Risk 3 – Data MappingDescription -

If the fields of data in the legacy application cannot be mapped fully to SHARE AM, some existing data will not be able to be migrated.

Probability - MEDIUM Impact – LOW

Mitigation Strategy –GSD SMEs will identify the required minimum fields of data needed to capture and maintain appropriate records of fixed assets and in conjunction with PeopleSoft consultants, specify fields to be populated. Contingency Plan – GSD will keep supplemental data from the legacy system in a Historical database for view only purposes.

PAGE | 9

RISK4 – RELIANCE ON OUTSOURCED RESOURCES TO ACCOMPLISH PROJECT GOALS

Description - Reliance on outsourced resources to accomplish project goals

Probability – MEDIUM Impact – LOW

Mitigation Strategy – Critical tasks will be assigned to GSD personnel. Closely manage external vendor contract deliverables. Monitor project budget and associated expenses, Contingency Plan - GSD SMEs and TSSB staff members will be assigned primary roles for completing tasks with the vendor providing guidance.

Risk5 – Limited GSD staff resourcesDescription - Limited GSD Resources

Probability – MEDIUM Impact – LOW

Mitigation Strategy – Advise GSD Senior Management of the priority and garner their support to allow additional resources to be provided to the project. Contingency Plan - Involve junior level resources who may be able to contribute their time to the project.

PAGE | 10

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURESTRUCTURE

2.1 STAKEHOLDERS2.1 STAKEHOLDERS

The following is a list all of the major stakeholders in this project, and their roles.

NAMENAME STAKE IN PROJECTSTAKE IN PROJECT ORGANIZATIONORGANIZATION TITLETITLE

Duffy Rodriguez Executive Sponsor GSD Deputy Cabinet Secretary

Michael Lujan Business Owner GSD/ASD ASD Director

Karen Baltzley Project Director GSD Chief Information Officer

Flaviano Prosperini Database Migration Support

GSD/TSSB Application Developer Supervisor

Silvia Rodarte Project Team Member GSD/ASD GL Bureau Chief

Scott Roybal Project Team Member GSD/ASD GSD Budget Director

Anna Silva Project Team Member GSD/FMD Facilities Management Division Director

Jimmy Rodriguez Project Team Member GSD/Facilities Management

Bureau Chief

John Salazar Project Manager CSW Enterprises, LLC

Co-Project Manager

Lee Baca Project Manager CSW Enterprises, LLC

Co-Project Manager

Ted Brubaker Implementation Vendor Deloitte Consulting, LLP

Implementation Vendor

Alan Harrison Implementation Vendor Deloitte Consulting, LLP


Cassandra Hayne SHARE Guidance and DoIT SHARE ERP

PAGE | 11

NAMENAME STAKE IN PROJECTSTAKE IN PROJECT ORGANIZATIONORGANIZATION TITLETITLE

Direction Manager

Bobby Montoya SHARE Support Staff DoIT SHARE Technical Staff

Robert Wible SHARE Support Staff DoIT SHARE Technical Staff

PAGE | 12

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

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

The Executive Sponsor operates as the Chair for the Project Steering Committee. As such, the Chair is the point person for the project within GSD.

PAGE | 13

Responsibilities include:

Championing the project;

Considering potential changes facing the organization and assesses the organizational impact;

Deciding which changes will be instituted, communicates priorities and provides resources to ensure success;

Creating an environment that enables changes to be made on time and within budget;

Participating in planning sessions; and

Chairing the Steering Committee.

The Steering Committee provides governance over the direction and support of the project.

The responsibilities of the Steering Committee Members include:

Attending and participating in Steering Committee Meetings;

Reviewing and providing comment on presented documentation;

Balancing larger picture versus details of the project;

Reviewing project funding and expenditures;

Championing the project; and

Contributing to lessons learned.

Steering Committee membership is included in the Project Organizational Chart depicted on the previous page of this document

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

The key interfaces between the organizations involved in and supporting the GSD-AM Replacement Project are those between the GSD CIO, the GSD-AM Project Manager, and the GSD-AM Project Owner.

The methods of communications utilized on the project will include:

Status Reports, Talking Points Memos, and Briefings;

Standing Team or Committee Meetings;

Ad-hoc meetings;

Electronic mail;

Distribution of Meeting Minutes; and

Phone conversations.

Interaction may occur directly between the technical components of all teams. Final decisions will be made at the Steering Committee level as required. Project communications and plans will be fully detailed in the GSD-AM Replacement Project Communications Plan,

PAGE | 14

2.3 EXECUTIVE REPORTING2.3 EXECUTIVE REPORTINGThe GSD Asset Management Project Manager will ensure regular and timely communications with the Executive Steering Committee.

Steering Committee Meetings once a month or as directed to review project status, schedule, budget, risks/issues, and action items;

The Asset Management Project Manager will meet with the Executive Sponsor, Business Owner, and Project Director to discuss any issue that represents a significant impediment to progress.

The Project Manager will submit an agency-approved Project Status Report to DoIT and GSD on a monthly basis.

3.0 SCOPE3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1 PROJECT OBJECTIVES3.1.1 B3.1.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES


BUSINESS OBJECTIVE 1 Eliminate duplicate manual processes and shadow systems, leading to improvements and eliminating potential data integrity threats caused by human error.

BUSINESS OBJECTIVE 2 Improve business processes for reporting and analysis related to agency balance sheet and net financial position. Implementation of SHARE AM module will satisfy Audit Rule requirement for Financial Statement Generation.

BUSINESS OBJECTIVE 3 Increase efficiencies in managing capital, non-capital assets and operating expenditures by reducing staff time for data input pertaining to recording processing of fixed assets and depreciation.

BUSINESS OBJECTIVE 4 Incorporate best practices by implementing a proven software product designed and built utilizing industry best practices for Asset Management processing that has been successfully implemented in other New Mexico state agencies.

PAGE | 15

3.1.2 T3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


TECHNICAL OBJECTIVE 1

Implement SHARE Asset Management functionality within GSD/ASD.


Cleansing and migration of data from current SunSystem to SHARE AM module for GSD use.


Utilize existing PeopleSoft Enterprise Resource Planning software and computing infrastructure.

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONSThe project excludes the conversion of purchase order and voucher data.

3.3 CRITICAL SUCCESS FACTORS3.3 CRITICAL SUCCESS FACTORSThe following is a list of quality metrics that address critical success factors for achieving success in this project.

NUMBERNUMBER DESCRIPTIONDESCRIPTION

QUALITY METRIC 1 Implement SHARE Asset Management functionality. Full utilization should be reached within two months of production cutover.

QUALITY METRIC 2 Decrease entry time for depreciable fixed assets by 50%.

QUALITY METRIC 3 Satisfy Audit Rule requirement for Financial Statement generation.

PAGE | 16

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

Initiation Define the scope, schedule, and budget for performance, including business benefits to be achieved.

PCC Initiation Phase Certification Request and associated Presentation

Draft Project Charter

Planning Develop the strategy for delivering on the goals and objectives of the project and all key planning documents.

Identify key project team members and form Project Team.

Develop Work Breakdown Structure, estimation of costs and time, identify resources and manpower.

PCC Planning Phase Certification Request and associated Presentation

Finalize Project Charter

Project Management Plan

Implementation Execute the project using the methodology established and documented in the Project Management Plan to monitor and control the project.

PCC Implementation Phase Certification Request and associated Presentation

Updated Project Management Plan

Closeout Project comes to a close, with product and services ready for use.

Contracts are terminated, and project teams dissolved.

All invoices are paid.

Lessons Learned Report

PCC Closeout Phase Certification Request and associated Presentation

PCC Closeout Presentation

PAGE | 17

4.1.1 P4.1.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

The following 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 GSD-AM-DEL-001 – Project CharterDescription – The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities.

Deliverable Acceptance Criteria – Must meet acceptance of the Executive Sponsor and the Project Certification Committee (PCC).

Standards for Content and Format –DoIT template.Quality Review – Reviewed and approved by GSD CIO.

4.1.1.2 GSD-AM-DEL-002 – Project Management Plan

Description – The Project Management Plan (PMP) is a formal document approved by the Executive Sponsor, the GSD CIO and DoIT. The PMP is developed during the Plan Phase of the project, and is utilized to manage project execution, control, and project close.

The primary uses of the PMP are to document planning assumptions and decisions, facilitate communication among stakeholders, and to document the approved scope, cost and schedule. The PMP includes and/or integrates by reference other related plans for issue escalation, change control, communications, deliverable review and acceptance, risk management, environment management, business continuity, testing, training and operational support plans

Deliverable Acceptance Criteria – All areas of the PMP completed with sufficient levels of detail to convey complete understanding of the effort to stakeholders.

Standards for Content and Format –DoIT template.Quality Review – Reviewed and approved by GSD CIO

PAGE | 18

4.1.1.3 GSD-AM-DEL-003 – Certification Request Forms and Presentations

Description – Forms and presentations tailored to provide specific information to the Project Certification Committee as the project progress through the Initiation, Planning, Implementation or Closeout phases.

Deliverable Acceptance Criteria – Must obtain acceptance of the PCC.

Standards for Content and Format –DoIT templates for requests.Quality Review – Reviewed and approved by GSD CIO and GSD-AM Business Owner.

4.1.1.4 GSD-AM-DEL-004 – Monthly Project Status Reports to DoIT

Description – 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 DoIT.

Deliverable Acceptance Criteria: All areas of the Project Status Report Form completed with enough levels of detail to convey complete understanding of project status to governance

Standards for Content and Format: Completed to DoIT StandardsQuality Review – Reviewed and approved by GSD CIO

4.1.1.5 GSD-AM-DEL-005 –Project Schedule

Description – Schedule is the key project management tool by which the Project will be managed. The Project Schedule contains all project key tasks, activities and milestones. Tasks and activities are defined with durations and deliverables, predecessor tasks, and the deliverable(s) associated with that task where they exist.The Project Schedule also contains an accurate calendar reflecting state holidays and other non-productive time periods, such as the week between Christmas and New Year’s Day

Deliverable Acceptance Criteria: All Project Tasks, Milestones, and Deliverables detailed, with durations, predecessors, and resources entered.

Standards for Content for the Project Schedule is developed consistent with Best Practice Project Management Standards (PMBOK) and DoIT requirements mat: Completed to DoIT StandardsQuality Review – GSD-AM Business Owner and GSD CIO

PAGE | 19

4.1.1.6 GSD-AM -DEL-006 - Executive Steering Committee Meeting Agenda/Minutes

Description – Executive Steering Committee meeting agenda and minutes

Deliverable Acceptance Criteria – Must meet criteria of the Executive Steering Committee.Standards for Content and Format – Will use PM template.Quality Review – Project Executive Steering Committee

4.1.1.7 GSD-AM -DEL-007 - Project Team Meeting Agenda/Minutes

Description – Project Team meeting agenda and minutes

Deliverable Acceptance Criteria – Must meet needs as defined by the Project Team members and the Project Manager.Standards for Content and Format - Will use PM template.

Quality Review - Will be reviewed by Project Team Leads

4.1.1.08 GSD-AM -DEL-008 - Project Budget and Expenditures Report

Description – Project Budget report to identify spend by fiscal year and projected amount remaining.

Deliverable Acceptance Criteria – Must meet criteria of the Project Sponsor, Project Owner and Project Director.

Standards for Content and Format – Will use PM template.

Quality Review – Will be reviewed by GSD-AM Project Owner and GSD CIO.

4.1.1.09 GSD-AM -DEL-009 - Risk/Issue Log

Description – Project Risk/Issue Log to track Risk, Mitigation and Contingency plans. Issues will be tracked and assigned to a principle owner for resolution.

Deliverable Acceptance Criteria – Will be reviewed and accepted by the Project Steering Committee

Standards for Content and Format – Will use standard DoIT template.

Quality Review - Will be reviewed by Business Owner and Project Director.

PAGE | 20

4.1.1.10 GSD-AM -DEL-010 – Lessons Learned

Description – Document lessons learned during course of entire project.

Deliverable Acceptance Criteria – Will be reviewed and accepted by the Project Steering Committee

Standards for Content and Format – Will use standard DoIT template.

Quality Review - Will be reviewed by the Business Owner and GSD CIO.

4.1.2 D4.1.2 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

The following table identifies the deliverables this project is to produce and lists the person or persons who have authority to approve each deliverable.

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

GSD-AM-DEL-001

Project Management Charter Sponsor and GSD CIO

6/20/2109

GSD-AM -DEL-002

Project Management Plan (PMP) Executive Sponsor and GSD CIO

GSD-AM -DEL-003

PCC Certification Request Forms & Presentations

Business Owner and GSD CIO

6/20/2019

GSD-AM -DEL-004

Monthly Project Status Reports to DoIT

GSD CIO 7/9/2019; 8/10/2019

GSD-AM -DEL-005

Project Schedule Business Owner and GSD CIO

GSD-AM -DEL-006

Executive Steering Committee Meeting Agenda/Minutes


GSD-AM -DEL-0097

Project Team Meeting Agenda/Minutes

Project Team Members

GSD-AM -DEL-008

Project Budget and Expenditures Report


GSD-AM -DEL-009

Risk/Issue Log Executive Steering Committee

GSD-AM -DEL-010

Lessons Learned Executive Steering Committee

PAGE | 21

4.1.3 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Section 6.7.5 documents the Deliverable Acceptance procedures to be followed for the GSD-AM project.

4.2 PRODUCT LIFE CYCLE4.2 PRODUCT LIFE CYCLE The General Services Department intends to utilize Deloitte’s Enterprise Value Delivery (EVD) methodology which is tailored to suit the GSD needs. GSD’s product life cycle strategy is to incorporate the following phases: Discover and Prework, Mobilize, Adapt, Deploy and Support. The table below documents the process and anticipated Key Deliverables.

Phase Summary of Phase Key Deliverables

Discover and Prework Define design foundation, change management approach and governance process.

“To-Be Business and Technical Requirements

Requirements Traceability Matrix

Mobilize Review Data, requirements and business processes before prototypes, define team.

Weekly and Monthly Implementation Vendor Project Management Deliverables

Adapt Architect – create design, document detailed requirements, software gaps, tech infrastructure

Configure and prototype – configure software and perform iterative prototyping

Test – perform testing and develop end user training materials

Business Process Flow and Functional Design

Develop Conversion Extract (GSD)

Prototype 1 & 2 Output

Conversion Validation (GSD)

Test Scripts

Testing Result

Conversion Signoff (GSD)

Deploy Prepare for and execute system and business cut over to the new environment

Configuration Workbook

Training Materials

Cutover Plan

Process to document software issues and failures

PAGE | 22

Support Transition from a pre-production environment to actual business operations. After the initial 30-day warranty period, all technical support will be provided by DoIT.

Go-Live Support

Knowledge Transfer

Retainage

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

This project will utilize the following PeopleSoft modules currently deployed and operational in the state of New Mexico and under the direction of the SHARE ERP Management Team:

Asset Management (AM); Purchasing; Accounts Payable; and General Ledger.

As such, GSD will be entering into a Professional Service Contract with Deloitte Consulting LLP for the implementation of the SHARE AM module. GSD intends to leverage the existing SHARE enterprise platform and existing computing infrastructure currently operated and maintained by DoIT and will not require additional hardware or software products. Since there are already two large agencies using AM, the addition of GSD will only strengthen the value of the IT investment through enterprise models that improve and streamline the Executive Branch services.

4.2.2 P4.2.2 PRODUCTRODUCT ANDAND P PRODUCTRODUCT D DEVELOPMENTEVELOPMENT D DELIVERABLESELIVERABLES

The following 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.

4.2.2.1 GSD-AM-DEL 101 – Implementation Vendor IT Professional Services Contract

Description – An IT Professional Services Contract will be developed and executed between GSD and the awarded vendor. The Vendor Contract will identify all Contract Deliverables. Deliverable Due

Deliverable Acceptance Criteria - The DoIT IT Professional Services Contract Template will be utilized to document contract terms and conditions. GSD and the Vendor will document Exhibit A – Contract Deliverables which meet the interest of the General Services Department –Administrative Services Division.

PAGE | 23

Dates and Deliverable Compensation Amounts.

Standards for Content and Format - Standard DoIT large template IT contract template to be used.

Quality Review - 1st Review: Reviewed by the GSD AM Business Owner and GSD CIO.2nd Level Review: DoIT EPMO, and GSD General Counsel.

4.2.2.2 GSD-AM-DEL-102 – Implementation Vendor Work Plan

Description – Implementation Contractor will be required to develop a Work Plan describing how they will implement their software product.

Deliverable Acceptance Criteria: Conveys a clear understanding of the vendor activities related to software design, build, test, deploy and transition to operations.

Standards for Content and Format: Format will be agreed to by GSD and the awarded vendor.

Quality Review –

1st Review: GSD AM Business Owner and GSD CIO. 2nd Level Review: Executive Steering Committee

4.2.2.3 GSD-AM-DEL-103- Process Design and Requirements

Description – Implementation Contractor shall prepare business process flow functional design documentation and documentation for any process or system gaps that are identified during the functional design process.

Deliverable Acceptance Criteria: Conveys a clear understanding of business process, business flows and external inputs and outputs.


Quality Review –


4.2.2.4 GSD-AM-DEL-104 – Software Configuration Services

Description – Implementation Contractor will be required to configure the SHARE AM module to meet GSD business requirements.

Deliverable Acceptance Criteria: Conveys a clear understanding of the vendor activities related to software configuration.


Quality Review –


PAGE | 24

4.2.2.5 GSD-AM-DEL-105 – Data Conversion Services

Description – Implementation Contractor will provide GSD with guidance and assistance in converting the legacy SunSystem Asset Management data to the SHARE AM database.

Deliverable Acceptance Criteria: Contains sufficient detail to clearly convey information needed for converting legacy data to SHARE AM database.

Standards for Content and Format: Format will be agreed to by GSD-TSSB and the awarded vendor.

Quality Review –

1st Review: GSD AM Business Owner and GSD CIO.

2nd Level Review: Executive Steering Committee

4.2.2.6 GSD-AM-DEL-106 – User Acceptance Testing

Description – Implementation Contractor will assist GSD with conducting User Acceptance Testing of the SHARE AM module with recently converted legacy data.

Deliverable Acceptance Criteria: Conveys a clear understanding of the vendor activities related to Test Scripts, User Acceptance Testing process and Testing Results.


Quality Review –


4.2.2.7 GSD-AM-DEL-107 – Training Services

Description – Implementation Contractor will conduct training for GSD users.

Deliverable Acceptance Criteria: Conveys a clear understanding of the vendor activities related to Training Process, Training Materials and Documentation.


Quality Review –


PAGE | 25

4.2.2.8 GSD-AM-DEL-108 - Deployment

Description – Implementation Contractor shall document application configuration changes necessary to support the future-state business processes in SHARE.

Deliverable Acceptance Criteria: Conveys a clear understanding of the vendor activities related to the Deployment Plan, Configuration Workbook, Training Materials and Knowledge Transfer.


Quality Review –


4.2.2.9 GSD-AM-DEL-109 -Warranty Support

Description – Implementation Contractor shall provide post-implementation support for the Asset Management Module.

Deliverable Acceptance Criteria: Contractor shall collaborate with the Procuring Agency to identify critical and non-critical support items. Contractor shall assist with troubleshooting problems and shall provide support, in a manner as mutually agreed upon.


Quality Review –


PAGE | 26

4.2.3 D4.2.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

The following table identifies the deliverables this project is to produce, and names the person or persons who have authority to approve each deliverable.

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

GSD-AM-DEL-101

Implementation Vendor IT Professional Contract


9/27/19

GSD-AM-DEL-102

Implementation Vendor Work Plan Business Owner and GSD CIO

GSD-AM-DEL-103

Process Design and Requirements Business Owner and GSD CIO

GSD-AM-DEL-104

Software Configuration Services Business Owner and GSD CIO

GSD-AM-DEL-105

Data Conversion Services Business Owner and GSD CIO

GSD-AM-DEL-106

User Acceptance Testing Services Business Owner and GSD CIO

GSD-AM-DEL-107

Training Services Business Owner and GSD CIO

GSD-AM-DEL-108

Deployment Business Owner and GSD CIO

GSD-AM-DEL-109

Warranty Support Business Owner and GSD CIO

4.2.4 D4.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Section 6.7.4 documents the Deliverable Acceptance procedures to be followed for the GSD Asset Management project.

PAGE | 27

5.0 PROJECT WORK5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)5.1 WORK BREAKDOWN STRUCTURE (WBS)The table presented below identifies the anticipated Work Breakdown Structure (WBS) to be followed during the GSD SHARE AM Project; therefore, the table will be updated as the project progresses. The table is subject to change and will most likely incorporate vendor-proven methodologies utilized in similar project deployments.

PAGE | 28

Identifier Work Package Description Definition/Objective Milestone/Deliverable

1.0 Project Management and Control

Risk, Issues and Action Item Management, Documentation Management, Scope Control, Status Reporting, Steering Committee Meetings

Status Reports, Steering Committee Meetings, Risk, Issues and Action Items

2.0 Technology Install latest version of SHARE AM module software in the TEST EnvironmentEnsure difference of no greater than one release between Development, Test, QA and Production environmentsInstall SHARE AM Replacement Versions as they are releasedMaintain Environments

Installed Software and Documentation (where applicable)

3.0 Initiation Phase Finalize Scope; Develop Project Scope; Schedule and Budget documentation; Set up Document Management Repository; Conduct Kick-Off Meeting; Technology Planning; Change Management Planning

Project Initiation Proposal, SharePoint, Schedule, Kick-Off Meeting;

4.0 Plan Phase Business Requirements Definition Plan,

Prepare for Business Requirements Definition Sessions

Requirements Definition Plan, Project Management Plan, Define Session Schedules, and Participants.

Implementation Request and PCC Presentation.

PAGE | 29


5.0 Implementation Phase Collect Business Requirements

Comprised of Design, Build, and Test Activities

Conduct Business Requirement Gathering Meetings

Completion of Design – Business Requirements Definition Report Sign-Off

Completion of Build – Unit Testing Completed Completion of Test-End to End Process Testing Complete

5.1 Design Activities Train Business Process Requirements Definition Participants in methodology and products to be implemented;

Conduct Requirements Definition Sessions; Prepare Business Requirements Report; Finalize and present to Steering Committee for Approval

Core Team Orientation TrainingBusiness Requirements (Design Document) approved by Steering Committee

5.2 Build Activities Software configuration, data conversion, report development.

Testing Environment Ready; Configuration, Data Conversion,

Reports; Testing Strategy and Plan,

5.3 Test Activities Unit Testing; Training Materials Developed; Module Testing; User Acceptance and End to End Process Testing;

Unit, Module and Process Test Results; End User Quality Assurance Sign-off

PAGE | 30


6.0 Deployment Phase Support Staff Training, Train the Trainer Training, End User Training;

Go/No Go Review; Production Cutover;

Stabilization Support (Call Center, End User Field Support, Remediation and Follow up Training Support); Lessons Learned Analysis; Project Close-out

Support Staff, Trainer and End User Training Completed;

Production Authorization; Cut Over; Lessons Learned Analysis, Project Close-Out

7.0 Closeout Phase Conduct Lessons Learned Review and Prepare Report;

Submit Closeout Request and Presentation to PCC

Lessons Learned Report PCC Closeout Request, and Presentation

PAGE | 31

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE5.2 SCHEDULE ALLOCATION -PROJECT TIMELINEThe following project timeline is a high-level view of project activities with a focus on project milestones. It provides a high-level view of the project timeline.

Identifier Task/Activity Name Resource Name

Milestone (Y/N)

Effort/ Duration

Start Finish Dependent Task

1 Develop PCC Initiation/Planning Request and Supporting Documents

Project Manager N 1 week 6/14/19 6/20/19

2 Develop Support Contracts

GSD CIO Y 4 weeks 5/17/19 6/14/19

3 Develop Data Conversion Plan

GSD IT Y 3 weeks 10/7/19 10/28/19

4 Business Process Flow and Functional Design


Y 4 weeks 10/18/19 11/15/19 2

5 Data Conversion Dry Runs

GSD IT Y 4 weeks 12/16/19 1/13/20 3

6 Configuration & Software Prototype #1


Y 2 weeks 11/8/19 11/22/19 4

7 Configuration & Software Prototype #2


Y 3 weeks 11/23/19 12/13/19 6

8 Develop Test Plan & Scripts


Y 2 weeks 11/30/20 12/13/19

9 Integration and UAT Implementation Vendor

Y 4 weeks 1/13/20 2/10/20 8

10 Configuration Workbook and Deployment Plan


Y 3 weeks 2/7/19 2/28/20 4

11 Training Materials & Knowledge Transfer


Y 2 weeks 2/14/20 2/28/20

12 Go Live Implementation Vendor

Y 1 day 3/1/20 3/1/20 1-11

13 Go Live Support Implementation Vendor

Y 30 days 3/1/20 4/1/20 12

PAGE | 32

5.3 PROJECT BUDGET5.3 PROJECT BUDGET

Phase / Activity Associated Deliverables Estimated Budget

Umbrella Tasks

Phase 1Project Preparation & Initiation

Preliminary Internal Staff Project Kick-offCommunication Plan draftResource AllocationDraft Project CharterPMP draft including schedule and budget Governance Structure FinalizedData Conversion DesignProject Management ServicesImplementation Vendor Project Management and Reporting

$8,675.00

Phase 2Planning

Business and Tech Requirement DefinedTo-Be Business Flow and Functional Design DocumentationGap Analysis DocumentationFinalize PMPData Conversion Plan FinalizedUser Requirements, Data Flow DiagramsSupport and Operations PlanSystem Preparedness and Deployment PlanRoles and Responsibilities definedChange Management PlanOfficial Project KickoffImplementation Vendor Project Management and ReportingProject Management Services

$18,675.00

Phase 3Implementation

Configuration and Software Prototype #1Configuration and Software Prototype #2System ConfigurationDevelop Test Plan & ScriptsData Converted from legacy system Integration and UATBusiness Admin DocumentationConfiguration Workbook & DeploymentTraining Requirements

$489,350.00

PAGE | 33

Phase / Activity Associated Deliverables Estimated Budget

Training Materials & Knowledge TransferBusiness Process Flow and Functional DesignImplementation Vendor Project Management

and ReportingGo-Live SupportImplementation Vendor Project Management

ReportingProject Management Services

Phase 4Project Closing

Final Documentation Transition to Operations Lessons Learned

$4,337.50

TOTALS $521,037.50

PAGE | 34

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

PAGE | 35

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

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL AAREAREA

Transportation Requirements Definition Team

Participates in the Business Requirements Definition Sessions identifying the requirements for the Transportation Division

James ChavezAnnette Roybal

Transportation Division

Facilities Management Requirements Definition Team

Participates in the Business Requirements Definition Sessions identifying the requirements for the Facilities Management Division

Jimmy Rodriguez John HosemanElizabeth Jeffries

Facilities Management Division

General Ledger Requirements Definition Team

Participates in the Business Requirements Definition Sessions identifying the requirements for the General Ledger Bureau

Silvia Rodarte Naomi VelasquezMelanie Ortiz

General Ledger Bureau

Accounts Payable Requirements Definition Team

Participates in the Business Requirements Definition Sessions identifying the requirements for the Accounts Payable Bureau

Barbara GuruleAndrea Carey

Accounts Payable Bureau

Purchasing Business Requirements Definition Team

Participates in the Business Requirements Definition Sessions identifying the requirements for the Purchasing Bureau

Natalie VigilAndrea Carey

Purchasing Bureau

Budget Business Requirements Definition

Participates in the Business Requirements Definition Sessions identifying the requirements for the Budget Bureau.

Scott RoybalValerie Griego

Budget Bureau

TSSB Support Data Lead/DBA

Participates in the Business Requirements Definition Sessions identifying the requirements for legacy data conversion.

Flaviano Prosperini TSSB Support and Data Conversion Lead

PAGE | 36

5.5 STAFF PLANNING AND RESOURCE ACQUISITION5.5 STAFF PLANNING AND RESOURCE ACQUISITIONThe chart below identifies the project team members and details concerning their project commitment.

5.5.1 P5.5.1 PROJECTROJECT S STAFFTAFF

Resource Cost EstimateEstimated Hours Availability Skill Set Work Product/Deliverable

Karen Baltzley $0 72 .10 CIO Technology Plan; Contract Administration; Project Charter; Project Documentation; Tech Staff Management; Steering Committee Meetings, PCC Hearings; Monthly DoIT Reports and Check-ups

Project Manager $39,037.50 360 .5 FTE Project Management; Strategic Planning

PMP, Project Schedule, Planning Documents; Project Management

Michael Lujan $ 0 180 .25 FTE Business Owner

Steering Committee Meetings, PCC Hearings, Business Process Definitions, Identify Priorities, Review and Approval Deliverables

Flaviano Prosperini $ 0 180 .25 FTE Technical Lead Oversee Technical Environments; Interface Development; Configuration Management and Data Conversion

Silvia Rodarte $0 180 .25 FTE General Ledger Team Lead

Business Process Definition Designs, Training Products, Testing Products; End User Support

Jimmie Rodriguez $0 180 .25 FTE Facilities Management Team Lead


PAGE | 37

Resource Cost EstimateEstimated Hours Availability Skill Set Work Product/Deliverable

Scott Roybal $0 72 .10 FTE Budget Team Lead


Natalie Vigil $0 72 .10 FTE B-SME Purchasing


Barbara Gurule $0 72 .10 FTE B-SME Accounts Payable


Naomi Velasquez $0 180 .25 FTE B-SME General Ledger


Annette Roybal $0 180 .10 FTE B-SME Transportation


PAGE | 38

5.5.2 N5.5.2 NONON-P-PERSONNELERSONNEL RESOURCESRESOURCES

Resource Cost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

Tyler McPheeters 200 .25 Deloitte Business Process Definition Designs, Configuration, Deployment, Training Products, Testing Products

Ted Brubaker 800 1.0 Deloitte Business Process Definition Designs, Configuration, Deployment, Training Products, Testing Products

Alan Harrison 800 1.0 Deloitte Business Process Definition Designs, Configuration, Deployment, Training Products, Testing Products

5.6 PROJECT LOGISTICS5.6 PROJECT LOGISTICSA Project Office has been established at the GSD TSSB’s offices at the Joseph Montoya Bldg., 1100 St. Francis Drive, Suite 1022, Santa Fe. The Project Manager will work out of this space. Project Planning, the Business Process Definition Design Sessions, testing, training and the majority of other project activities will be conducted in the TSSB Training Lab.

Technical Staff are in TSSB’s offices at the Joseph Montoya Bldg., 1100 St. Francis Drive, Suite 1022, Santa Fe.

During the Testing Lifecycle, the TSSB Training Lab will be used as a Test Lab, during which time the Test Lead and Testers will carry out testing evolutions.

All other key resources are currently located at the Administrative Services Division offices located at the Joseph Montoya Bldg., 1100 St. Francis Drive, Room 3071 Santa Fe.

PAGE | 39

5.6.1 P5.6.1 PROJECTROJECT T TEAMEAM T TRAININGRAINING

Project Team members and stakeholders will receive various types and levels of training, depending on their involvement in the project and the phase of the project. This information will be developed and refined as Planning activities continue.

ResourceCost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Transportation Requirements Definition Team

$0 TBD 2 FTE High-level experience

“As-Is” and “To-Be” Requirements SHARE AM Software Business Definition Requirements

Facilities Management Requirements Definition Team



General Ledger Requirements Definition Team



Accounts Payable Requirements Definition Team



Purchasing Business Requirements Definition Team



Budget Business Requirements Definition



Transportation Requirements User Acceptance Team

$0 TBD 2 FTE Mid-level experience

GSD AM Testing Results

Facilities Management User Acceptance Team



General Ledger User Acceptance Team



Accounts Payable User Acceptance Team



Purchasing Business User Acceptance Team



Budget Business User Acceptance Team



PAGE | 40

6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1 RISK AND ISSUE MANAGEMENTThe Project is using the strategy developed in the recent GSD PROOF project which follows the DoIT Methodology as it relates to Risk Management and Issues Management. MS-SharePoint has been deployed in support of the project, and both Risk Management and Issues Management are documented and tracked from the Home Page of the project site.

6.1.1 R6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

A Risk Assessment and Report will be developed during the first few weeks of the project and will be on file on the project SharePoint site in the Risk Management Library. A Risk Log will be created at that same time and will also be maintained and updated at frequent intervals. It will also be filed on the SharePoint site.

Tasks will be established in the project schedule for updating the Risk Assessment Report prior to each project stage gate. Risk Identification is a standing item on the Core Team Meeting Agenda to ensure that risk awareness remains at a high level across the project team over the lifecycle of the project. Prior to Phase Gates, the Core Team will elevate emphasis on Risk and Issue Identification and Management.

The Risk Log is referred to and updated regularly by the Project Manager. All project personnel have access to the Risk Log and may submit a perceived risk at any time.

6.1.2 P6.1.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

Risks may be identified at the project level or by a number of other criteria. A column entitled ‘Category’ has been added to the Risk and Issues Log, which provides any stakeholder with another method for parsing the risks by area of responsibility, thereby aligning risks with the project organizational structure.

As indicated above, any member of the team may identify and log either a risk or an issue at any time. Team Members and Stakeholders are encouraged to raise risks and issues anywhere and anytime they are perceived.

6.1.3 P6.1.3 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

The Project Team’s approach to risk mitigation is based on conservativism and pro-activity. Any perceived risk will be granted due diligence, objective consideration. A mitigation strategy will be developed as appropriate.

The Project Team will be pro-active and strive to create a culture where team members are encouraged to raise risks and issues wherever they are perceived. The Team is similarly committed to elevating awareness of risks and issues to the Executive Steering Committee and Governance and will work pro-actively to seek collaborative and timely mitigation of strategies.

PAGE | 41

6.1.4 R6.1.4 RISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

Risks may be raised by anyone at any point during the project lifecycle. Risks may be reported via email or entered directly into the SharePoint Risk Log and then reported to the Project Manager for consideration and disposition.

Risks will be evaluated by the Project Manager and Core Team Leads (Technical, Change Management, and Communications Leads). All Risks reported will remain on the Risk Log, though they may be moved to a “Closed” status as appropriate. All new risks will be discussed in the weekly Core Team Meetings and will be disclosed on the Project Manager’s weekly status reports to Executive Steering Committee Members and other Stakeholders.

Risks of “Likely” or higher probability or “Medium” or higher impact will be presented at the monthly Steering Committee meetings. The contingency plans for each will be discussed, as will the mitigation plans.

6.1.5 P6.1.5 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

All project risks will be tracked using the DoIT Risk and Issue Log Tracking tool provided. As noted above, new risks will be discussed at the bi-weekly project team meetings, and all open risks will be reviewed by the Core Team on a monthly basis to assess changes in probability or impact.

The Risk and Issues Log is available at any time on the Project SharePoint.

6.1.6 ISSUE MANAGEMENT6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution Process

This internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality. This process should 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.

Internal issues will be addressed and escalated in a manner similar to that of the Risks. Internal Issues can be raised by any team member or stakeholder. Issues will be maintained in the Issues Tracking folder on the GSD AM Project SharePoint site. New Issues will be discussed at the Core Team Meeting and assigned, dispositioned, or escalated as appropriate. Internal Issues will also be discussed at bi-weekly one-on-one meetings between the Project Director, Project Manager and ASD Director. As appropriate, Internal Issues will be escalated to the Executive Steering Committee, DoIT, or other governance body members.

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.

PAGE | 42

External Issues will have the same escalation and resolution process as internal issues, except for the need to reach out to and engage the external agency or entity involved. At the core, the Project Team will seek collaborative and mutual agreeable resolutions to issues.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&VDue to the shortened project timeline and the SHARE Asset Module software already implemented at other state agencies (DOT and DoIT), GSD requested a waiver to the IV&V project requirement. DoIT granted the waiver on 7/10/19.

6.3 SCOPE MANAGEMENT PLAN6.3 SCOPE MANAGEMENT PLAN6.3.1 C6.3.1 CHANGEHANGE C CONTROLONTROL

6.3.1.1 Change Control Process

Change Control establishes how change will be managed, including capturing, tracking, communicating, and resolving change. Due to much ambiguity regarding change, it is vital that we document and discuss the change process with the executive sponsor.

Change Control will initially come into the project’s visibility as an Issue, Action Item or Risk. Change Control items are expected to surface primarily during the BBP Sessions, but irrespective of when and how they surface, the process of evaluating, escalating and resolving the Change Item (CI) will be the same. CI’s will be documented in the ‘Action Items and Issues’ folder on the GSD AM Project’s SharePoint site. CI’s will be detailed there, with specific information required, including:

Brief Description Detailed Description Date CI Submitted Submitted By Business Owner (Director Benefitting/Requiring) Business Justification Cost Benefits Decision Required by Date Status Progress Notes Resolution

Once a CI has been submitted, a meeting of the Core Team Leadership will be convened, including the Project Manager, GSD-CIO, ASD Director, Change Control Lead, Technical Lead, Business Unit-SME Lead, Functional Administrator, and Communications & Training Leads. The Project Leadership Group will consider the CI, its justification, costs and benefits, and make a recommendation on the resolution of the CI. CI’s resolved by a unanimous vote will be escalated to the Steering Committee for approval. Those CI’s either not resolved, or where

PAGE | 43

resolution is by less than a unanimous vote will be escalated to the Steering Committee (Change Control Board) for evaluation and final resolution.

6.3.1.2 Change Control Board (CCB)

The Executive Steering Committee will serve as the CCB, who will make a final determination on any Change Item.

6.4 PROJECT BUDGET MANAGEMENT6.4 PROJECT BUDGET MANAGEMENTProject costs are as defined above under Sections 5.5.1 and 5.5.2. All costs related to project staff are included in the project schedule and projected out over the lifecycle of the project.

Project costs have been projected using an MS-Excel spreadsheet containing monthly forecasts of costs for contract resources, software, maintenance fees, and contingencies. Actual costs will be reported against this forecast, and variances reported on a monthly basis.

6.4.1 B6.4.1 BUDGETUDGET T TRACKINGRACKING

The Project Manager will track project expenditures as expenditures are paid on the SHARE Accounting System. ASD Finance personnel will generate a monthly expenditure report for the project and the project expenditures will be reconciled with the Project Budget and Expenditures Worksheet and the SHARE General Ledger.

6.5 COMMUNICATION PLAN6.5 COMMUNICATION PLANThe Project Communication Plan will provide an approach for communications and support for the project.

The purpose of the Communication Plan is to facilitate centralized communications between and among all identified project audiences. Combining the audiences’ needs with methods for standardizing communications will enable processes for conveying project awareness, status, and issues and provide a means for feedback.

Various types of information are being communicated throughout the life of the Project. For the purpose of this project, four types of information categories have been determined:

Project Execution Project Status Project Awareness Information Generic Information

The Project audience has been broken into four broad categories:

PAGE | 44

Core Team Extended Team Internal [within ASD] External [New Mexico citizens, and other interested parties]

A detailed matrix will be created to match audiences with the appropriate type of information. Frequency and media have also been identified for each type of communication. The communications matrix will serve as the foundation of who, what, where, when, why and how the Project team will communicate with project stakeholders.

6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

The communications matrix matches the various types of information with the appropriate audiences. In addition, the matrix identifies the communication frequency and medium for the information, by audience. The matrix format is dynamic in that it allows for changes in types of information received, how often, and in what format.

A significant amount of the information communicated is focused within the Project Team. A well-informed team is better prepared to communicate effectively the strategy, goals, objectives, and status of the Project efforts. In addition, the majority of the communication information originates within the team. Therefore, effective communications within the Project Team contributes to the success of the communication efforts with the other audiences.

The following key identifies the various frequency and media options for communications.

Communications Frequency

Daily

Bi-Weekly

Weekly

Monthly

Quarterly

Upon Document Publications

As needed

Upon Joining Project

Communications Media

Lead Agency Publications

Documents / Presentations

Electronic Mail

SharePoint Web Site

PAGE | 45

Road Show Presentation Meetings

Ad Hoc Meetings

Training

Voice Mail

Tele/Video meeting

6.5.2 S6.5.2 STATUSTATUS M MEETINGSEETINGS

Various status meetings are conducted on a frequent basis:

Project Core Team meetings are typically conducted bi-weekly, with the exception of the period when Business Requirements Definition (BRD) Sessions are in progress

NOTE: Core Team Meetings are typically suspended during the BRD Sessions, as the entire team is engaged in the meetings. If a Core Team Meeting is required to address a critical project issue, a special session will be convened.

Meeting between the Project Director, Project Manager and ASD Director every other Wednesday;

Executive Steering Committee Meeting meets the last week each month;

Weekly attendance / representation at the ASD Manager’s meeting More frequent meetings with leadership and other stakeholders as appropriate or as

needed.

6.5.3 P6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

All contract personnel will be required to submit status reports weekly to the Project Manager. In addition, the Project Manager will gather detailed accomplishments from ASD staff and incorporate these in the Project Status Reports (PARs). These individual PARs include activities and accomplishments, plans for the next reporting period, and any comments, suggestions, issues, concerns or questions. The Project Manager combines these individual PARs into a project level status report that is distributed to Executive Steering Committee Members, key stakeholders in ASD, GSD and all Project Core Team Members. A copy of each week’s status report is also filed on the Project SharePoint Site in the Status Report folder.

Monthly status reports are also submitted to DoIT in accordance with DoIT requirements. The DoIT Status Reports will be available on the Project SharePoint site.

6.6 PERFORMANCE MEASUREMENT (PROJECT METRIC)6.6 PERFORMANCE MEASUREMENT (PROJECT METRIC)The Project Manager, Business Sponsor, and Executive Sponsor will define the project metrics that will be used to control the project, with possible criteria identified in the table below. Metrics will be 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.

PAGE | 46

Metric Type Metric Goal

Schedule Late Tasks – Tasks starting late or projected to finish late

< 5; < 1 for Critical Path Tasks

Quality Key Project Documents Approved by Leadership 100%

6.6.1 B6.6.1 BASELINESASELINES

Project Area Category Measure

Project Schedule Schedule On or ahead

Project Budget Budget Under

Project Scope Scope Control 0 Change Orders

6.7 QUALITY OBJECTIVES AND CONTROL6.7 QUALITY OBJECTIVES AND CONTROLThe following list 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.

6.7.1 6.7.1 QUALITYQUALITY S STANDARDSTANDARDS

No. Quality Standard Tracking Tool or Measure

1 Standards defined by statute • TBD2 The Project Management Quality Standards as defined by

the Project Management Body of Knowledge (PMBOK)• TBD

3 Information Technology standards defined within the Information Technology framework by DoIT

• TBD

4 Asset Management industry best practice standards. • TBD

6.7.2 P6.7.2 PROJECTROJECT ANDAND P PRODUCTRODUCT R REVIEWEVIEW AND ASSESSMENTS AND ASSESSMENTS

PAGE | 47

Review Type Quality Standard Tools Reviewer Reports

Requirements NM Statutes; Workflows modeled in product;Maintenance and Materials Management Industry Best Practice

MS-Visio, MS-Excel, MS-Word,

ASD Director, Executive Steering Committee

Business Process Requirements Report

Plans PMBOKDoIT

MS-Word, MS-Project

GSD CIOASD Director

PMP, Change Management Communications Training;Test Strategy and Plan

Milestones PMBOKDoIT

MS-Project ASD Director; Executive Steering Committee

Status ReportsExecutive Steering Committee Presentations

Testing PMBOKDoIT

MS-Word

MS-Excel

GSD CIOASD Director

Status Reports

Test Strategy and Plan

Use CasesTest Results

6.7.3 A6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMER S SATISFACTIONATISFACTION

Customer and Agency satisfaction will be assessed on an on-going basis by the Project Manager and Team. Weekly (Stakeholder) and Monthly (DoIT) Status reports, Steering Committee Meetings, Presentations, and frequent updates to agencies and customer groups will be the primary mechanisms by which the Team will communicate progress, goals and objectives, and identify issues and benefits.

Project reporting metrics will provide primary feedback on schedule and budget performance, and we will coordinate efforts with initiatives wherever synergy and common interests exist.

The project manager will meet with the ASD Director and GSD-CIO on a bi-weekly basis to ensure project performance is meeting expectations, and with the GSD Cabinet Secretary and others on a monthly basis to ensure customer and agency satisfaction

PAGE | 48

Areas of feedback When How Often

Agency awareness TBD Monthly

Quality of communications Every other Wednesday Bi-Weekly

Manages project tasks TBD Weekly

Productive Meetings TBD Bi-Weekly

PRODUCT DELIVERABLE ACCEPTANCE PROCESSPRODUCT DELIVERABLE ACCEPTANCE PROCESS

All products produced by the Project will be reviewed by oversight groups and leadership.

Testing the SHARE Asset Management (AM) product and ASD processes will have several dimensions to ensure quality and consistency in all deliverables. Each track of the project (process change, configuration, data conversion, interface development, report development, testing, and training) will be tested initially on an isolated basis (Unit Testing). Unit Testing will be followed by Module Testing.

Following successful completion of Module Testing, End to End Process Testing will be performed. In End to End Testing, transactions will be run through their entire life cycle. In that effort, the Project Test Team will exercise and evaluate process change related documentation (forms, SOPs, etc.), configuration data workflow, data conversion, interface performance, reports, and training materials.

Following completion of End to End Process Testing, a final round of End User Acceptance Testing will be undertaken. Staff from various bureaus of ASD will be engaged to process work using the modules being implemented and will provide feedback to the Project Team.

Prior to beginning production use of the SHARE AM software, an evaluation will be made regarding operational readiness in a number of areas, including training readiness, technical readiness, quality assurance testing readiness, and operational support readiness. The results of that evaluation will be presented to the Executive Steering Committee, which will make the final determination on approving the production cut-over.

PAGE | 49

6.7.5 D6.7.5 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDURESROCEDURES

The Deliverable Acceptance Procedure assures that the deliverables meet the requirements of the contract.

1. The Project Manager will deliver a Deliverable Acceptance Form (Sample in Appendix -B) to the Approver with each Deliverable. The Form will identify the deliverable and the acceptance criteria.

2. Upon receipt of the Deliverable and Acceptance form, the Approver has 15 working days to formally approve or reject the Deliverable. The form must be marked approved or disapproved. There is no acceptance or rejection by default.

3. If the Deliverable is rejected, a detailed description of why it was rejected must be included on the form. In the event of a rejection, the Contractor has 3 business days to address issues with the Deliverable and to resubmit the Deliverable. All errors and omissions must be detailed in the Rejection.

4. E-mail approval with the approver’s name typed on the form is an acceptable form of transmittal. When e-mail approvals are used, the e-mail with the approval should be saved as a text document and pasted into the acceptance form at the end of the form. Verbal approvals are not acceptable.

Criteria for Acceptance

The Project Manager and Approving Authority must agree on acceptance criteria for all deliverables before delivery. Acceptance criteria will describe deliverables by submitting vendor, contract number, deliverable title or name, deliverable acceptance criteria, or other measurable factors.

Acceptance Log

The Project Manager will maintain a Deliverable Acceptance Log (Sample in Appendix - C) to document the delivery and approval of each deliverable. The acceptance log will include the following information:

Date Submitted – the date the Project Manager presents the deliverable to the approving authority for acceptance;

Vendor – The name of the Vendor submitting the Deliverable; Contract Number – The Contract Number assigned by the Agency; Deliverable # - The Contract Deliverable Numbers as identified in the Professional

Services Contract; Invoice Number – The Invoice Number designated by the submitting vendor. Approved or Rejected – indicating whether or not the deliverable is approved or rejected;

and, Date of Action – Date that the approval or rejection took place.

.

PAGE | 50

6.8 CONFIGURATION MANAGEMENT6.8 CONFIGURATION MANAGEMENTConfiguration Management (CM) is the process of systematically controlling and managing all steps of configuration throughout the project lifecycle, the CM Plan operates in conjunction with, and in alignment to the Project Test Plan, the Continuity of Operations Plan, the Backup and Recovery Plan, and the Service Level Agreement.

The CM Plan provides a systematic approach for: (1) defining the process for managing changes to the environments; (2) determining who made a change to the environments; (3) discovering what changes were made, when they were made and why; and (4) understanding who authorized the changes.

This CM Plan is designed to safeguard effectively the data and configuration assets developed over the course of the Project.

The CM Plan:

(1) Provides contextual information aligning this plan to Project as a whole and references other related documents;

(2) Defines the scope of the CM processes for the Project;

(3) Provides details related to the environments that will be utilized in managing configuration changes;

(4) Details the processes for moving configuration items through environments;

(5) Defines the roles and responsibilities of project team members with respect to CM; and

Defines the toolset that will be used by the project team to track and manage changes during the project lifecycle.

6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

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

SharePoint has been implemented for the GSD Asset Management Project and is being utilized to track all project documentation.

PAGE | 51

6.9 PROCUREMENT MANAGEMENT PLAN6.9 PROCUREMENT MANAGEMENT PLANAll procurement is being conducted in accordance with established standards and procedures promulgated by SPD, in accordance with DoIT guidelines, and with the ultimate approval of the LFC and DFA.

7. 0 PROJECT CLOSE7. 0 PROJECT CLOSE The following list includes the activities to performed during the formal closing of the project.

No. Activities to be performed for Closeout:1 Gather and analyze project performance metric information to determine

effectiveness of software modernization efforts;2 Process final payments for all procured products and services;3 Conduct lesson learned with project stakeholders and document the

results in the GSD SharePoint Asset Management Project Repository;4 Develop Project Certification Committee (PCC) Closeout Request

Documentation to formally close project. Attend PCC meeting to request formal approval to close project; and,

5 Inventory and update final versions of the project management plans and all necessary project documents are uploaded to the GSD SharePoint Asset Management Project Repository.

ATTACHMENTSATTACHMENTSAppendix A – Acronyms and DefinitionsAppendix B – Deliverable Acceptance FormAppendix C – Deliverable Acceptance Log Appendix D – Project Schedule Appendix E – Project Budget

PAGE | 52

APPENDIX A - ACRONYMS AND DEFINITIONSAPPENDIX A - ACRONYMS AND DEFINITIONS - A -

Acceptance Criteria – The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE-STD-610]

Acceptance Testing – Formal testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system. [IEE-STD-610]

Action Log – The action log is a direct extension of the project schedule. The action log reflects specific actions to be completed. Generally, these actions are small enough in both impact and duration to be handled on the Action Log rather than requiring a special revision to the project plan. Any item that requires more than one day to complete should be on the action log. The action log is a living document that will be updated frequently and serves as an ongoing “To Do List” to ensure that action items are not left uncompleted. Actions will be captured during meetings and at other times by means of an action-input form. This form will be submitted to the project manager for entry into the log. The log will be maintained as a table in MS word. Closed actions will be moved to an archive.

AM – Asset Management

AR Export – Asset Renewal Export

AR Import – Asset Renewal Import

ASD – Administrative Services Department

Assumptions – Planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here or converted to formal risks.

- B -

Baseline – A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610]

BRR – Business Requirements Report

BPR – Business Process Re-engineering

- C -

CCB – Change Control Board

Change Management Log – The change management log lists the current status and project impact of each planned or enacted project change request. The log shows at a glance the current impact of change on the project. The Project Manager in a MS-Excel Worksheet format will maintain the change management log. The log will be updated when a proposed

PAGE | 53

or approved PCR is received. The log will be reviewed at the weekly Leadership meeting and reported on in the Weekly Status report.

CI – Change Item; a request for change on a project that falls under the purview of Change Control

Commitment – A pact that is freely assumed, visible, and expected to be kept by all parties.

Configuration Management (CM) – A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE-STD-610]

Consensus – a decision that is in the best interests of New Mexico, GSD and RMD, and a design that the participants can live with and which they will commit to supporting

Constraints – Factors that will (or do) limit the project management team’s options. Contract provisions will generally be considered constraints.

Contingency Planning – The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.

COTS – Commercial off the Shelf Software. Package systems provided by vendors such as PeopleSoft or Oracle that provide support for a variety of different functions. Often referred to as Enterprise Resource Planning (ERP) Systems or Enterprise Asset Management (EAM) Systems.

.

Crashing – Taking action to decrease the total duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.

Critical Path – The series of activities that determines the duration of the project. The critical path usually defined as those activities with float less than or equal to specified value often zero. It is the longest path through the project.

- D -

Decision Maker – a member of an organization possessing a high enough level of authority to render a decision with regard to organizational policy or procedure

Deliverable – Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project that is subject to approval by the project sponsor or customer.

Dependencies, Discretionary – Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential

PAGE | 54

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

Dependencies, Mandatory – Dependencies that are inherent to the work being done. In some cases, they are referred to as hard logic.

Dependency Item – A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so they can perform a planned task.

DFA – Department of Finance and Administration

DoIT – Department of Information Technology

Duration – The number of work periods (not including holidays or other nonworking periods) required to complete an activity or other project element.

Duration Compression – Shortening the project schedule without reducing the project scope. Often increases the project cost.

- E -

Effort – The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks.

Empowerment – SME’s participating in the Business Requirements Definition Sessions are authorized to make design decisions for the deployment of SHARE AM software modules with the exception of:: (1) decisions in violation of statute; (2) decisions that violate management-bargaining unit agreements; (3) decisions that commit additional funds; and (4) decisions that violate established, jurisdictional boundaries

End User – The individual or group who will use the system for its intended operational use when it is deployed in its environment.

ERP – Enterprise Resource Planning System (see COTS)

- F -

FA – Functional Administrator

Fast Tracking – Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction.

Float – The amount of time that an activity may be delayed from its early start without delaying the project-finished date.

FMD- Facilities Management Division

Formal Review – A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.

PAGE | 55

FS – Funding Source

- G -

GSD – General Services Department

- H -

No entries at this time

- I -

Integrated Project Plan – A plan created by the project manager reflecting all approved projects and sub-projects.

IPS – Integrated Project Schedule; a master schedule created by the project manager reflecting all approved project activities of the main project and sub-projects.

Issues Log – Similar to the action log, the issues log is an extension of the project plan. The issue log will be updated as needed throughout the week. An issue differs from an action in severity and the amount of effort required to resolve. An issue, if left unresolved would have a significant adverse impact on the project. Typically, the resolution to an issue is not known at the time it is created and the issue owner must develop a solution. The project issue log will be updated as needed by submitting an update form to the project manager. The issue log will be maintained in a MS-Word table.

IWA – Internal Work Agreement (or Amendment)

- J –


- K –

KPI – Key Performance Indicator

- L -

Lessons Learned – The learning gained from the process of performing the project. Lessons learned may be identified at any point during the execution of the project.

LFC – Legislative Finance Committee

- M -

Method – A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.

Methodology – A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product.

PAGE | 56

Milestone – A scheduled event for which some individual is accountable and that is used to measure progress.

- N -

NMAC – New Mexico Administrative Code

NMSA – New Mexico Statutes Annotated

Non-technical Requirements – Agreements, conditions, and/or contractual terms that affect and determine the management activities of an architectural and software project.

NTP – Notice to Proceed

- O -

OBS – Organizational Breakdown Structure

OCIO – Office of the Chief Information Officer

OOS – Office of the Secretary

- P -

PCC – Project Certification Committee

Performance Reporting – Collecting and disseminating performance information. This includes status reporting measurement, and forecasting.

PMBOK – Project Management Body of Knowledge

PMI – Project Management Institute

PMP – Project Management Plan

PO – Purchase Order

PR – Purchase Requisition

Procurement Planning – Determining what to procure and when.

Product Scope – The features and functions that characterize a product or service.

Program – A group of related projects managed in a coordinated way. Programs include an element of ongoing work.

Project Change Request forms – A PCR (Project Change Request) is a request for change on the project. It has two parts, one for estimating the cost to investigate the PCR, the other to determine how much the PCR will cost to implement. All project changes require an approved PCR. Typically, this involves a change to the project schedule, budget, or scope.

Project Charter – A document issued by senior management that formally authorizes the existence of a project. It provides the project manager with the authority to apply organizational resources to project activities.

PAGE | 57

Project Leader (Technical) – The leader of a technical team for a specific set of tasks. Typically referred to as the Technical Lead, they have technical responsibility, and provide technical direction to the staff working on the tasks.

Project Management – The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project Management is also responsible for the oversight of the development and delivery of the architecture and software project.

Project Manager – The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project. The project manager is the individual ultimately responsible to the customer.

Program Management Office (PMO) – An organizational entity responsible for management and oversight of the organization’s projects. As a specific reference in this document, the Office of the Chief Information Officer.

Project Management Plan (PMP) – A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost, and schedule baselines. The Project Management Plan (PMP) is a project plan.

Project Schedule – A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. Software products such as ABT’s Workbench and Microsoft Project are tools used to develop project schedules.

Project Scope – The work that must be done to deliver a product with the specified features and functions.

Project Sponsor – The individual that provides the primary sponsorship for an approved project. This individual will play a key role in securing funding, negotiating for resources, facilitating resolution of critical organizational issues, and approving key project deliverables.

- Q -

QMP – Quality Management Plan

Quality – The degree to which a system, component, or process meets specified requirements. The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610]

Quality Management – The process of monitoring specific project results to determine if they comply with relevant standards and identifying ways to eliminate causes of product non-compliance.

- R -

RFP – Request for Proposal

PAGE | 58

Risk – Possibility of suffering loss.

Risk Management – An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk Management includes risk identification, analysis, prioritization, and control. Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

Risk Management Plan – The collection of plans that describes the Risk Management activities to be performed on a project.

RMD – Risk Management Division.

- S -

SA – Systems Administrator

Scope Change – Any change to the project scope. A scope change usually requires an adjustment to the project cost or schedule.

SLA – Service Level Agreement

SHARE – Statewide Human Resources, Accounting, and Reporting. The State of New Mexico’s PeopleSoft-based Enterprise Resource Planning System used by the General Services Department Risk Management Division.

SME – Subject Matter Expert. A member of an organization acknowledged as an authority in a particular area or topic.

Software Life Cycle – The period that begins when a software product is conceived and ends when the software is no longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation, and checkout phase, operation and maintenance phase, and, sometimes, retirement phase.

SOP – Standard Operating Procedure

SPD – State Purchasing Division

Stakeholder – Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected because of project execution or project completion. They may also exert influence over the project and its results.

Standard – Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development.

Statement of Work – The Statement of Work (SOW) is the contractual agreement that defines the project objectives, expectations and scope. Each project member should be familiar with the SOW particularly as it relates to project scope and the definition of completion for each major deliverable.

PAGE | 59

System Requirements – A condition or capability that must be met or possessed by a system component to satisfy a condition or capability needed by a user to solve a problem. [IEEE-STD-610]

Subproject – A smaller portion of the overall project.

- T -

Task – A sequence of instructions treated as a basic unit of work. [IEEE-STD-610] A well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post conditions). Please refer to activity for contrast.

Task Assignment Sheets – Where applicable, the project manager will provide a detailed outline of the specific steps required to complete an assigned task. The Task Assignment Sheet provides much greater detail and specificity than the project schedule. In some cases a single project schedule task may be broken down into fifteen or more steps to complete. Where practical this Task Assignment Sheet will be developed in MS Word and distributed in hard copy prior to opening the new task. In addition, the project manager will hold a coaching session at the start of each task to review the task assignment.

TCM – Total Cost of Maintenance

TCO – Total Cost of Ownership

Team – A collection of people, often drawn from diverse but related groups, assigned to perform a well-defined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities.

Technical Requirements – Requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.

Traceability – The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. [IEEE-STD-610]

TSSB – Technology & Systems Support Bureau

- U -UAT – User Acceptance Test

- V –


- W -

PAGE | 60

WBS – Work Breakdown Structure: a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.

WCA – Workers Compensation Administration

- X, Y, and Z

No entries at this time.

PAGE | 61

APPENDIX B – DELIVERABLE ACCEPTANCE FORMAPPENDIX B – DELIVERABLE ACCEPTANCE FORM

DELIVERABLE ACCEPTANCE FORMDELIVERABLE ACCEPTANCE FORM

GSD ASSET MANAGEMENT REPLACEMENT PROJECT

NAME OF VENDOR SUBMITTING DELIVERABLE:

CONTRACT NUMBER:

INVOICE NUMBER:

CONTRACT DELIVERABLE NUMBER:

DELIVERABLE DESCRIPTION:

ACCEPTANCE CRITERIA:

Project Manager Acceptance

Approved Disapproved

Name Signature Date

Business Owner Acceptance


Name Signature Date

Agency CIO Acceptance


Name Signature Date

Remarks:

PAGE | 62

APPENDIX C – DELIVERABLE ACCEPTANCE LOGAPPENDIX C – DELIVERABLE ACCEPTANCE LOG

DELIVERABLE ACCEPTANCE LOGDELIVERABLE ACCEPTANCE LOG

GSD ASSET MANAGEMENT PROJECT

Date Submitted

Vendor submitting

Deliverable

Contract Number

Deliverable Number

Approved or Rejected

Date of Action

Approved or Rejected by

APPENDIX D – PROJECT SCHEDULEAPPENDIX D – PROJECT SCHEDULE Task:

PAGE | 63

PAGE | 64

PAGE | 65

APPENDIX E – PROJECT BUDGETAPPENDIX E – PROJECT BUDGET

Type Description Vendor FY20 Projected Expenses

FY20 Actual Expenses

Prof Services Software Implementation Services DELOITTE $315,000.00 $315,000.00 $ - $ - $ - $ - Prof Services Implementation Vendor Training Services DELOITTE $167,000.00 $167,000.00Prof Services Project Management CSW Enterprises $39,037.50 $39,037.50 $ - $4,668.00 $ - $4,668.00 Contingency Project Contingency *TBD $28,962.50 $28,962.50 $ - $ - $ - $ -

Total Amounts $550,000.00 $550,000.00 $ - $4,668.00 $0.00 $0.00

Amount Amount$550,000.00 $550,000.00

$122,350.00$550,000.00 $427,650.00 Amount Amount$122,350.00 $122,350.00

$4,668.00 $117,682.00 Amount

$550,000.00

$550,000.00$122,350.00 $0.00

Amount Amount$550,000.00 $550,000.00

$4,668.00

$550,000.00

$550,000.00

Total Appropriated Funds Balance Budget Allocation by Fiscal Year Total Appropriation FY20 Appropriated Funds

Total Expenditures - Inception-to-date

Appropriation Balance

Total Budget Allocation by Fiscal Year

Total Appropriated Funds Total Projected Expenses for Project

Total DoIT PCC Certified Funds Total Unfunded Amount

Total Expenses (Inception to date) Balance of DoIT PCC Certified Funds Project Unfunded Amounts

Total Appropriation DoIT PCC Uncertified BalanceDoIT PCC Certification History Project Certified Funds Balance June 27, 2019 (Initiation AND Planning Phases) Total DoIT PCC Certified Funds

DoIT PCC Certified Funds

Project Contract Expenditures: Software Implementation, and Professional Services

Total Projected Expenses

Project Appropriation History Total DoIT PCC Certified/Non-Certified BalancesLaws of 2019, Chapter 271, Section 7, Item 11 Appropriation Amount

Projected Expenditures by Fiscal Year Total Actual

Expenses

Actual Expenses by FY

GSD/ASD Asset Management Project Budget and Expenses v20190930

PAGE | 66