View
1
Download
0
Category
Preview:
Citation preview
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.
NNUMBERUMBER DDESCRIPTIONESCRIPTION
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
NNUMBERUMBER DDESCRIPTIONESCRIPTION
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
Implementation Vendor
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
NNUMBERUMBER DDESCRIPTIONESCRIPTION
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
NNUMBERUMBER DDESCRIPTIONESCRIPTION
TECHNICAL OBJECTIVE 1
Implement SHARE Asset Management functionality within GSD/ASD.
TECHNICAL OBJECTIVE 2
Cleansing and migration of data from current SunSystem to SHARE AM module for GSD use.
TECHNICAL OBJECTIVE 2
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
Business Owner and GSD CIO
GSD-AM -DEL-0097
Project Team Meeting Agenda/Minutes
Project Team Members
GSD-AM -DEL-008
Project Budget and Expenditures Report
Business Owner and GSD CIO
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.
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.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.
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
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.
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.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.
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
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.
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.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.
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
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
Business Owner and GSD CIO
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
Identifier Work Package Description Definition/Objective Milestone/Deliverable
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
Identifier Work Package Description Definition/Objective Milestone/Deliverable
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
Implementation Vendor
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
Implementation Vendor
Y 2 weeks 11/8/19 11/22/19 4
7 Configuration & Software Prototype #2
Implementation Vendor
Y 3 weeks 11/23/19 12/13/19 6
8 Develop Test Plan & Scripts
Implementation Vendor
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
Implementation Vendor
Y 3 weeks 2/7/19 2/28/20 4
11 Training Materials & Knowledge Transfer
Implementation Vendor
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
Business Process Definition Designs, Training Products, Testing Products; End User Support
PAGE | 37
Resource Cost EstimateEstimated Hours Availability Skill Set Work Product/Deliverable
Scott Roybal $0 72 .10 FTE Budget Team Lead
Business Process Definition Designs, Training Products, Testing Products; End User Support
Natalie Vigil $0 72 .10 FTE B-SME Purchasing
Business Process Definition Designs, Training Products, Testing Products; End User Support
Barbara Gurule $0 72 .10 FTE B-SME Accounts Payable
Business Process Definition Designs, Training Products, Testing Products; End User Support
Naomi Velasquez $0 180 .25 FTE B-SME General Ledger
Business Process Definition Designs, Training Products, Testing Products; End User Support
Annette Roybal $0 180 .10 FTE B-SME Transportation
Business Process Definition Designs, Training Products, Testing Products; End User Support
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
$0 TBD 2 FTE High-level experience
“As-Is” and “To-Be” Requirements SHARE AM Software Business Definition Requirements
General Ledger Requirements Definition Team
$0 TBD 3 FTE High-level experience
“As-Is” and “To-Be” Requirements SHARE AM Software Business Definition Requirements
Accounts Payable Requirements Definition Team
$0 TBD 1 FTE High-level experience
“As-Is” and “To-Be” Requirements SHARE AM Software Business Definition Requirements
Purchasing Business Requirements Definition Team
$0 TBD 1 FTE High-level experience
“As-Is” and “To-Be” Requirements SHARE AM Software Business Definition Requirements
Budget Business Requirements Definition
$0 TBD 1 FTE High-level experience
“As-Is” and “To-Be” Requirements SHARE AM Software Business Definition Requirements
Transportation Requirements User Acceptance Team
$0 TBD 2 FTE Mid-level experience
GSD AM Testing Results
Facilities Management User Acceptance Team
$0 TBD 2 FTE Mid-level experience
GSD AM Testing Results
General Ledger User Acceptance Team
$0 TBD 3 FTE Mid-level experience
GSD AM Testing Results
Accounts Payable User Acceptance Team
$0 TBD 1 FTE Mid-level experience
GSD AM Testing Results
Purchasing Business User Acceptance Team
$0 TBD 1 FTE Mid-level experience
GSD AM Testing Results
Budget Business User Acceptance Team
$0 TBD 1 FTE Mid-level experience
GSD AM Testing Results
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 –
No entries at this time
- 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 –
No entries at this time
- 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
Approved Disapproved
Name Signature Date
Agency CIO Acceptance
Approved Disapproved
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
Recommended