• Abstract and Figures
• Public Full-text

TAPESTRYTAPESTRY PPROJECT

PROJECTPROJECT MANAGEMENTMANAGEMENT PLANPLAN (PMP)(PMP)

EXECUTIVE SPONSOR – JOHN MONFORTE BUSINESS OWNER – WILLIAM DURAN TRD CIO – JIM WASTVEDT IT PROJECT MANAGER – JAN CHRISTINE MVD Business Project Manager – Raul Alvarez ORIGINAL PLAN DATE: NOVEMBER 8, 2013 REVISION DATE: SEPTEMBER 9, 2015 REVISION: 8.0 2 PAGE | 3 REVISION HISTORY

REVISION NUMBER DATE COMMENT .3 11/8/2013 First Complete Draft .4 11/25/2013 Update for later start date, & project org chart .5 12/2/2013 Updated list of deliverables. Removed separate SI budget. 1.0 12/15/2013 Highlighted areas to be discussed 12/15/13 5.0 1/27/2014 Jan Christine and James Viano Updates. 6.0 02/01/2014 Revised Budget. Jan Christine 7.0 03/06/2014 Revised Assumption 007. 04/14/2014 Added budget into this version only available to ESC members. Updated the schedule to Baseline #1. 8.0 09/09/2015 Revised business membership. Updated progress and budget.

PAGE | 4 1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT

The Agency faces a situation today in which its driver and vehicle licensing system is aged and increasingly challenged to meet current and future business demands. New Mexico’s Taxation and Revenue Department (TRD), and in particular its Motor Vehicle Division (MVD), has a large investment in a number of interrelated driver, vehicle, administrative control, licensing and registration, and revenue processing information systems. Over time, pressure to maximize the utility and interoperability of these systems and to reduce costs has increased dramatically. These common demands have led to an industry and nationwide movement to increase systems interoperability under a technology architecture that is more modularized and reduces reliance on expensive, highly proprietary service offerings.

The Agency is committed to moving forward with the reengineering and replacement of its current systems with a drivers and vehicles solution that is customer-centric and that provides enhanced access and integration with other State and Federal databases. It is highly desirable that the new solution provide the Agency and its Motor Vehicle Division with the ability to manage technical and business requirements with user-configurable data items and modular application code so as to allow quick and cost-effective adaptation to MVD’s changing business needs.

In October 2009 the Agency published RFP# 00-333-00-06348, Motor Vehicle Division Driver and Vehicle Licensing System Reengineering Project, “to replace the legacy system currently used by the MVD and implement a modern customer-centric commercial-off-the-shelf (COTS) driver and vehicle system.” At the conclusion of that RFP process a contract was awarded on April 7, 2010 to Saber Software, Inc. (HP). In May of 2011 that contract was terminated by the Agency.

In July 2011 the Agency issued RFI#10-333-00-10249 to gather information to help the Agency determine the most advantageous way to move forward with replacement of MVD’s legacy Driver and Vehicle systems and with the implementation of a modern, customer-centric Driver and Vehicle system. The information gathering initiated by that RFI continued through October 2012.

A second RFP was issued early in 2013, RFP#30-333-12-12463. Responses to that RFP were aligned with one of two approaches: 1) COTS system, and 2) COTS software for Customer- Relationship-Management (CRM) and Rules Engine with custom development of MVD functions in and on the CRM platform. TRD is still in the process of completing this RFP. The remainder of the document will refer to the system and the system integrator as ‘SI’ in the remainder of this document.

TRD accepted Fast Enterprises proposal for the RFP#30-333-12-12463. Kickoff was March 5, 2014. The first release for Driver Services was completed on-schedule and on-budget May 26, 2015. The Tapestry team started on the second and final release for Vehicle Services July 1,

PAGE | 5 2015. As per the original schedule, Vehicle Services is due in full production September 6, 2016.

1.2 FUNDING AND SOURCES

APPROPRIATION HISTORY (INCLUDE ALL FUNDING SOURCES, E.G. FEDERAL, STATE, COUNTY, MUNICIPAL LAWS OR GRANTS)

Amount Funding Source Fiscal Year

2010 Laws of 2010 Special Session, Chapter. 6, Sec. 7, Item 3, reverts 6/30/12 2012 Laws of 2012 Chapter 19, Section 7(3), extended through 2014 $8,300,0 fiscal year 2014 00 Laws of 2014, Chapter 63, Section 7 extended through fiscal year 2015

2009 $7,209,1 Laws of 2009, Chapter 124, Sec. 7, Item 3, reverts 6/30/11 2013 66 Laws of 2013, Chapter 227, Section 7(3), extended through fiscal year 2015

2009 $12,897,100 Laws of 2009, Chapter 124, Sec. 7, Item 3, reverts 6/30/11 2013 Laws of 2013, Chapter 227, Section 7(3), extended through fiscal year 2015 2014 2009 CDL Grant CD093510000000 CFDA #20.232 $75,583.00 Expires 8/31/2014 2014 $165,942.79 2010 CDL Grant CD103510000000 CFDA #20.232 Expires 9/30/2014 2015 $ 8,861,500 Laws 2015, Chapter 101, Section 7(3) $3,690,000 of the other state funds appropriation is from cash balances (non-reverting data sales). $5,171,500 from General Fund. Total $ 37,509,292

PAGE | 6 1.3 CONSTRAINTS Constraints are factors that restrict the project by scope, resource, or schedule.

NUMBER DESCRIPTION Constraint 001 Currently, funding only exists for FY16. Unless the C2 request for FY17 is approved, the project will be unable to complete Release 2 for Vehicle Services and the associated Stabilization Services, Level 3 Support, licensing fees all due during FY17.

PAGE | 7 1.41.4 DEPENDENCIES Types 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

Number Description Type M,D,E

Dependency The funding constraint, listed in 1.3 is also a dependency. All M 001 planned project activities after the 2QFY15 cannot be completed without the requested funds.

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

NUMBER DESCRIPTION Assumption 001 The project will use the SI implementation methodology to deliver the new Driver and Vehicle Reengineering Project system, termed ‘TAPESTRY’. The methodology has been proved to be successful for numerous domestic and international projects.

In several critical areas, SI will be required to provide design documents that are usually not included as part of the SI methodology. At the present time this need is anticipated for a minimum of the below:  Temporary interfaces necessary between the new and legacy systems from the time the first Release for Driver is complete, through completion of the second release for Vehicle.  Web services agreed with SI that will be exposed from core for use by third parties, such as kiosk and record sales vendors.  Any interfaces specified as mandatory by the RFP, that require negotiation or change on the part of the external party.

The department does require the use of project management methods outside the tools incorporated into COTS products. The ITD PMO will be responsible for extraction of data\objects from the COTS product and transformation of those objects into the format or forms needed for development and maintenance of a MSP project plan with weekly updates for EVM calculations, and RTM creation and maintenance. SI will be

PAGE | 8 NUMBER DESCRIPTION responsible for cooperating with the Contract PM Team, and providing some SME guidance\coaching, regarding the most efficient and effective way to extract data from the COTS product. Assumption 002 TRD will be willing to modify and streamline business procedures in order to take advantage of the out-of-the-box capabilities of the proposed solution, to improve customer service, and to enhance the efficiency of internal agency operations.

Streamlining of the MVD business processes accepted by MVD will not detrimental to the MVD Vision of the Future, solely to use the “out-of-the- box” SI functionality. Assumption 003 The maximum amount of hardware that TRD needs to acquire was quoted by SI in the RFP. TRD’s assumption is that there will be no additional expenses for hardware or system (web server, app server, DB server) software other than that quoted in the SI response to RFP. TRD will identify existing resources that could be used for the project in lieu of the hardware\software included in the SI response. SI and TRD will mutually agree on any substitutions. Assumption 004 Current TRD policy will be upheld for requests by contractors for a) remote access to the TRD network, b) database or other server administrative access, c) after-hours access to the project site, and d) internet or TRD network access from personal laptops. Current policy is that application for these access privileges be made to the TRD CIO on an individual basis. Decisions for granting such access will be province of the TRD CIO. Assumption 005 The SI will obtain the project space within the constraints of the current budget. Budget available supplied to SI 11/04/2013. Assumption 006 The SI will use the current DMS, Qmatic, photo capture, and central issuance COTS software as specified by the RFP. Assumption 007 The solution provided will require minimal (less than 10%) additional TRD desktop support, network support, ITD support, call center support or Partner Management support currently provided by record sales, vehicle transaction, and IVR Third Party vendors. Baseline support TRD FTEs for all SAMBA and NMI users today:  Zero support FTEs today for the frontend web

 Zero desktop support for either SAMBA or NMI application users

 (1 – 1.5) FTE to support the backend of file transfers and programming to the mainframe.

PAGE | 9 NUMBER DESCRIPTION  Zero Active Directory Accounts.

 Zero direct connections to the TRD network.

 Zero network support personnel

 Zero training support

 Five (5) partner management personnel for all partners. There is no way to separate out how many FTEs are used to support SAMBA and NMI users vs. PRAs.

Assumption 008 Data Conversion TRD is responsible for extraction of the data from existing data sources, cleansing, and an unformatted dump to SQL server staging table(s). SI is responsible for all other data conversion activities including transform and load of the data into SI data structures Assumption 009 All full time project team members – including TRD business representatives, IT staff, SI staff, project administrative support, and project managers – will be co-located in the same project space, as the available space allows. Assumption 010 SI will provide all the interfaces listed in the RFP. TRD will provide any temporary interfaces necessary to concurrently run Driver functions in the new system and Vehicle functions from the legacy systems. Assumption 011

The Department will accept the best practices inherent in the SI’s FastDS‐

VS product, without detriment to the MVD Vision of the Future, solely to use the “out-of-the-box” functionality. Assumption 012 The Department will make decisions within the parameters established by the contract.

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

Risk 1 – Funds Availabiltiy

PAGE | 10 Probability: Medium Impact HIGH Description - Mitigation Strategy C2 request has been made, but will not be acted on until after all contracts are approved. Contingency Plan None available. MVD would have to stop the project during Driver implementation if additional funds are not forthcoming. Risk 2 – On-time, On-Budget System Delivery Probability: Low Impact: High MVD System Modernization project is Mitigation Strategy not delivered on-time, on- budget and in scope. 1. The vendor selected has an excellent on-time, on-budget record, with high customer satisfaction ratings. 2. Scope, Cost and Schedule management will be performed by the ITD PMO and the Business Project Manager (MVD Project Manager). 3. The selected product is a ‘true’ COTS product, mitigating the risk for late delivery or budget overruns.

Contingency Plan : TRD has already taken measures to mitigate this risk. Risk 3 – Near Term, COTS Architecture will constrain the Vision of the Future Probability: Low Impact: High Near Term, the selected COTS software will Mitigation Strategy constrain the MVD Vision of the Future 1. The Technical (Systems) Architecture function will be responsible for ensuring the best decisions are made regarding architectural options available within the COTS architecture, and ensuring compliance with the previously selected options during development and implementation. 2. TRD needs to assume responsibility for continuing dialogue with the SI and other states implementing the same COTS software, in order to continue a strategy that will allow MVD to have 80% of the transactions via virtual channels and 20% of the transactions via MVD field or partner offices. Contingency Plan : None.

PAGE | 11 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

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

NAME STAKE IN PROJECT ORGANIZATION TITLE TRD Internal Stakeholders

John Monforte Executive Sponsor TRD Deputy Cabinet Secretary

William Duran Business Owner TRD\MVD MVD Director

Jim Wastvedt CIO, Acting TRD CIO, TRD

Lee Baca Manager of the ITD TRD\ITD Manager personnel currently supporting the MVD systems.

Raul Alvarez Provide and schedule the TRD\MVD Deputy Director, activities of all business Special Projects participants from all TRD divisions. Reports to the Director of MVD

Jan Christine Provide and schedule the TRD\ITD ITD PMO Lead activities of all information & (ITD PMO) technology participants from TRD\ITD. Reports to the TRD CIO.

Other TRD Divisions Obtain information from TRD Various the system, and provide  TFID data entry and transaction  ACD handling services.  RPD TRD-External Stakeholder

PAGE | 12 NAME STAKE IN PROJECT ORGANIZATION TITLE

Existing Third Provider of services using Munis Partners the base system or local PRAs proprietary systems. STSC NMI SAMBA

Existing Users of Providers of vehicle and Dealers (1000+ Third Party User temp tag transactions. dealers) Interfaces TSCs (1800 SAMBA users) Data Sales Customers

Other State Agencies Users of Driver Various compliance and vehicle title information

AAMVA Supplier of nationwide AAMVA information and collector of state information. Must test and accept all new uses of services.

Law Enforcement Consumers of Driver and DPS Vehicle information. All NM Local Provider of NCIC service. LEs

Administration of the Provide court decisions AOC Courts regarding citations. Are consumers of MVD data regarding drivers.

PAGE | 13 2.2 PROJECT GOVERNANCE STRUCTURE

2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART

2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE EXECUTIVE STEERING COMMITTEE

NAME ROLE ORGANIZATION TITLE

John Monforte Chair TRD Deputy Cabinet Secretary

William Duran Member TRD\MVD MVD Director

Jim Wastvedt Member TRD CIO, TRD

Lee Baca Convener TRD\ITD Manager

Raul Alvarez Member TRD\MVD Deputy Director Special Projects

Adolfo Montoya Member TRD\ASD CFO

Lynette Borrego Member TRD\MVD MVD Finance

Jan Christine Member TRD\ITD ITD PMO Lead

James Viano Non-Voting Member FAST FAST PM

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

External Entity Description of relationship-all are Currently responsible based on actual electronic interfaces and crossover admin/operational jurisdiction AAMVA DLDV/Administrative Alicia Ortiz AAMVA NMVTIS Kenric Hindi/Adam Diamond

PAGE | 14 DOT TSB/TRACS/Manuals Adam Diamond/Mac Lewis/Kenric Hindi DPS NCIC/NMLETS Adam Diamond Magistrate/Muni Multiple CMS's- Connie Torres/Bernadette Courts Gonzales/Angel Martinez/Adam AOC/JID Odyssey- Adam Diamond Metro Court Stored procedure-moving to web serviceConnie Torres/Adam for Odyssey Diamond FBI access to data Alicia Ortiz/Angel Martinez County Treasurers Custom application portal Leonard Garcia County Assessors 2.0 – access to view records Leonard Garcia TSC's/STC's 2.0 and Samba related Margaret Williams/Angel Martinez Game And Fish ATV's Adam Diamond/Barbara Roybal ASD/UTC Paper Citations Adam Diamond Energy Minerals Boats Adam Diamond/Barbara and Natural Roybal Resources/Parks Division RPD Processing/data entry Connie Torres/Adam Diamond Other Law data access Angel Martinez/Adam enforcement Diamond Human Services data access Adam Diamond Division Municipalities, data access/VRS Adam Diamond/Angel Gov fleets/other Martinez Gov entities GSD data access/titling/registering Leonard Garcia All LEA's for titling/registering Leonard Garcia undercover

PAGE | 15 vehicles NMADA titling/registering Noel Davis NMIADA titling/registering Noel Davis

2.3 EXECUTIVE REPORTING Reporting requirements will remain the same as for every other certified project. A status report is provided to the Executive Steering Committee biweekly. Monthly reports are due to DoIT. Status reports are due to the PCC upon request or agreed upon schedule.

3.0 SCOPE

3.1 PROJECT OBJECTIVES

3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTION

BUSINESS OBJECTIVE 1 Replace the antiquated, fragile MVD system with a robust, reliable system via an on-time, on-budget project delivery.

BUSINESS OBJECTIVE 2 Expand electronic government (self-serve model).

BUSINESS OBJECTIVE 3 Lead customers to lower-cost service channels.

BUSINESS OBJECTIVE 4 Balance customer facing with centralized processing services.

BUSINESS OBJECTIVE 5 Expedite paperless processing.

BUSINESS OBJECTIVE 6 Simplify business rules

BUSINESS OBJECTIVE 7 Provide a solution capable of supporting the Visionary Business Model developed by MVD and ITD in 2012.

BUSINESS OBJECTIVE 8 Provide all the requirements previously developed for RFP #30- 333-00-12463

BUSINESS OBJECTIVE 9 Provide higher levels of MVD service with the ability to meet new, evolving requirements and operational needs.

BUSINESS OBJECTIVE Provide the ability to decrease the average time per transaction in

PAGE | 16 NUMBER DESCRIPTION

10 the Field Office by 20%. Average wait time January 28 in the state offices was 15 minutes.

3.1.2 TECHNICAL OBJECTIVES

NUMBER DESCRIPTION

TECHNICAL OBJECTIVE 1 Provide a solution capable of immediately, or with only slight modification, support the Visionary Business Model developed by MVD and ITD in 2012. TECHNICAL OBJECTIVE 2 Provide all the technical requirements included in the previous RFP #30-333-00-12463. TECHNICAL OBJECTIVE 3 Procure a more modular solution with current technologies that can be managed, updated, and replaced without requiring wholesale replacement. TECHNICAL OBJECTIVE 4 Adhere to national standards for data exchange, security, and interfaces. TECHNICAL OBJECTIVE 5 Provide open-systems-based architecture (SOA compliant) that is more reliable, flexible, and maintainable. TECHNICAL OBJECTIVE 6 Manage the risks of implementing and operating the new motor vehicle environment while improving system and data integrity. TECHNICAL OBJECTIVE 7 Develop and manage a program that enables disaster recovery operations and improves on return-to-service time lines. TECHNICAL OBJECTIVE 8 Improve the quality and accessibility of information for users with toolset standards, such as Structured Query Language (SQL) and Open Database Connectivity (ODBC), and do so without the involvement of operators or specialists. TECHNICAL OBJECTIVE 9 Where required in the RFP, fully integrate existing capital and hardware infrastructure that currently exists.

3.2 PROJECT EXCLUSIONS Fully complies with RFP#30-333-12-12463 and Contractor’s proposal dated February 28, 2013 and best and final offer dated March 26, 2013 submitted in response to such document.

PAGE | 17 3.3 CRITICAL SUCCESS FACTORS

Number Description

QUALITY METRICS 1 Improve customer service via a customer centric database that links vehicles to drivers.

QUALITY METRICS 2 Adopt Best Practice DMV processes.

QUALITY METRICS 3 Increase the % of transactions performed via virtual channels by 20% within three months of production go-live for each of the Driver and Vehicle releases.

QUALITY METRICS 4 Have system available 24x7x365 to all virtual channels with a 99.9% availability.

QUALITY METRICS 5 Maintain a Schedule Performance Index (SPI) of 1 throughout the project

QUALITY METRICS 6 Maintain a Cost Performance Index (CPI) of 1 throughout the project

QUALITY METRICS 7 No deliverable loops through a customer review more than three times, without escalation and solution of issues related to that deliverable.

QUALITY METRICS 8 Elimination of the risk of catastrophic failure, based on the current system being beyond useful life and potentially one upgrade away from failure. Much more efficient use of resources--development resources, data QUALITY METRICS 9 entry resources, internal back office resources.

Dramatically improved financial accountability and reduction of QUALITY METRICS 10 financial risk

Dramatically improved process management and partner QUALITY METRICS 11 accountability

PAGE | 18 4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables Project Charter Initiating Scope engagement with client and formulate strategic relationship. Contracts Project Management Plan PMP Sub-plans Defining project parameters and  Communications Planning building shared vision for solution  Risk Management delivery. Project Schedule Requirements Traceability Matrix (Contract PM Team) Additional Plans  Training Plan  Test Plan  Transition to Operations  Disaster Recovery Delivering the project in smaller Complete work and deliverables Executing sprints as negotiated at the time of Complete Enhancements/ contract signing. Changes Interfaces System and Load Testing Training Acceptance Testing Rollout Status Reports Project Schedule Management Monitoring the execution and Controlling (Monitoring) controlling variances to quality, Risk/Issue Management, time, and scope. Quality Assurance Variance Analysis and intervention Product Acceptance Conclusion and closure of project Transition to Operations Closing activities following deployment of solution. Transition to Support Lessons Learned

4.1.1 PROJECT MANAGEMENT DELIVERABLES 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 Project Charter Description – Deliverable Acceptance Criteria: Standard DoIT Project Charter The document is complete, per DoIT standards, and reflects the project goals and understanding of the Agency.

PAGE | 19 Standards for Content and Format - DoIT Template http://www.doit.state.nm.us/project_templates.html Quality Review -. Review and approval by the Sponsor, Business Owner, TRD CIO, Business PM, IT PM, and Business Finance.

4.1.1.2 Contracts Description – Deliverable Acceptance Criteria: Any contract for work within the The document is complete, per DoIT standards, and reflects project using DoIT’s current the project requirements. contract template. Standards for Content and Format - DoIT Template http://www.doit.state.nm.us/project_templates.html Quality Review -. Electronic review and approval by TRD OGC, TRD CIO, and DoIT. Signature by Agency Secretary, MVD Director, TRD CIO, TRD CFO, DoIT, either SPD or DFA as appropriate.

4.1.1.3 Project Management Plan Description – Deliverable Acceptance Criteria: Standard DoIT Project The document is complete, per DoIT standards, and reflects Management Plan the project goals and understanding of the Agency. Standards for Content and Format - DoIT Template http://www.doit.state.nm.us/project_templates.html Quality Review -. Review and approval by the Sponsor, Business Owner, TRD CIO, Business PM, IT PM, and Business Finance.

4.1.1.4 PMP Sub-plans Description – Deliverable Acceptance Criteria: Standard DoIT The documents are completed, per DoIT standards, and Requirements Management Plan reflects the needs and expectations of the Agency, in either a Communications Plan DoIT standard template or an alternative format agreed to by Risk Management Plan Contractor and Procuring Agency. Issue Management Plan Standards for Content and Format - Data Conversion/Migration Plan DoIT Template Master Test Plan Master Training Plan http://www.doit.state.nm.us/project_templates.html

PAGE | 20 System Rollout Plan Quality Review -. Transition to Operations Review and approval by the Sponsor, Business Owner, TRD Business Continuity\Disaster CIO, Business PM, IT PM, and Business Finance. Recovery

May include: Stakeholder Management Plan Change Management Plan Fail-Back Plan Security Management Plan Support Plan Quality Assurance Plan

4.1.1.5 Project Schedule Description – Deliverable Acceptance Criteria: MSP 2010 or higher detailed The document is complete, and reflects the needs and project schedule. expectations of the Agency. Standards for Content and Format - MSP schedule will include MS Project Resource and Staffing Assignments Quality Review -. Budgeted and actual costs Review and approval by the Sponsor, Business Owner, TRD CIO, Business PM, and IT PM. Management of the schedule will include management of budget and Baseline, analysis, and ongoing monitoring change and resource\staffing. control will be the responsibility of the Contract PM.

4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable.

DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED

PRJ-DEL-002 Project Charter Project Sponsor MVD Director

PRJ-DEL-003 Project Management Plan (PMP) Sponsor Business Owner TRD CIO PRJ-DEL-002 Contracts Depends on the In process scope and source of

PAGE | 21 DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED contract. PRJ-DEL-004 Project Management Sub-Plans Depends on the plan. Will be signed off by ESC, During Clarification, drafts were Business Owner, or provided, that will need revision, CIO, or internal for: business or ITD  Risk management PMs depending upon the content of  Implementation the plan  Organizational Change  Rollout  Stakeholder – Communications only  Desktop Support  Security  Disaster Recovery  Master Testing  Master Training  Conversion Plan PRJ-DEL-005 Project Schedule Sponsor Preliminary Business Owner approval received, During Clarification a project TRD CIO but will schedule less costs and assignments need to be was received. Two major revisions modified have already been received and when a incorporated into the main contract. project start date has been determined with more accuracy. PRJ-DEL-006 Requirements Traceability Matrix Sponsor (RTM) including control and Business Owner monitoring. TRD CIO

PAGE | 22 DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED

This is the responsibility of the Business Architect within the Contract PM Team.

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

As per the contract language, Exhibit F:

Following process shall be followed for Deliverable Submission & Acceptance. These Steps are reflected in the Project Schedule.

Step Activity Responsible Step # 1 Draft Deliverable Document, or project TRD ESC-designated personnel artiface, Preparation Step # 2 Submission for Review to TRD TRD ESC-designated personnel Step # 3 Review Comments provided by TRD TRD ESC-designated personnel Step # 4 Analysis of Review Comments by TRD ESC-designated personnel Contractor Step # 5 Joint meeting to review comments and TRD ESC-designated personnel finalize the action to be taken Member(s) Step # 6 Update Deliverable Document & TRD ESC-designated personnel Submission for Review & Approval Step # 7 Approval of Deliverable Document Designated TRD Project Member(s)

4.2 PRODUCT LIFE CYCLE The project will be using the SI development life cycle, which is an agile SDLC and methodology.

PAGE | 23 Phase Summary of Phase Key Deliverables Prepare and Plan Initiation and planning of the Business Profiles road map for how the SI Inventory of Inputs and implementation will be Outputs executed Preliminary Project Management deliverables listed in Section 4.1. Define, Design, and Base Define, design and provide a Implementation Specification Configuration starting point of navigation Interface Specifications and functionality for each line of business that will be Base Configuration delivered. Develop and Configure Items from the Define and Letters Design phase are used to Reports develop, configure and program the system Interfaces Security System, Stress\load, end-to- Ensure the system is able to Base Test Scripts for UAT end, and User Acceptance meet the business needs in a Testing Testing robust and stable manner. Test Results for all system, stress\load, end-to-end, and UAT tests Training, Conversion, and Train users, convert legacy Training materials Rollout system data, rollout new Training system and provide warranty support of the system and Training Satisfaction Results system users. Conversion test results Sample Mock Conversions Full Mock Conversions Conversion Loads Rollout Rollout desktop support Close Finalize activities for above Project Lessons Learned phases session and documentation

PAGE | 24 4.2.1 TECHNICAL STRATEGY The technical strategy will follow the SI agile methodology that has been used successfully in the past project with the SI and 24 other projects external to New Mexico, involving the same core architecture.

4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES Example: Description : Deliverable Acceptance Criteria – Documents a function’s business The Implementation Specifications shall be accepted once activity description, processing, the functions, within each business line, have been properly summary, interfaces and expected documented as to the end results of the SI system. configuration. Standards for Content and Format - SI Implementation Specification format. Quality Review - ESC designated team member(s)

Deliverable Number 1 FastDS-VS Software

Description : Deliverable Acceptance Criteria – COTS Software Purchase Contractor will obtain signoff from ESC Designated Approver(s) for Deliverable 1, FastDS-VS Software. Standards for Content and Format - SI License Agreement Quality Review - ESC designated team member(s)

Deliverable Number 2 FastDS-VS Deployment Infrastructure

Description : Deliverable Acceptance Criteria – Contractor will obtain signoff from ESC Designated Approver(s)  Deliver O/S, DB, Web and for Deliverable Number 2, FastDS-VS Deployment Infrastructure. App Server Software The designated approver for this task will be responsible for inspecting the installation prior to signoff.  Deliver Other 3rd Party Standards for Content and Format - Software Hardware, Software, etc.

PAGE | 25 Quality Review -  Deliver Server Hardware for four environment ESC designated team member(s)  Deliver Additional Network Devices  Deliver Additional SAN Storage

Deliverable Number 3 Project Management Plan

Description : Deliverable Acceptance Criteria –  Produce the Project Schedule Contractor will obtain signoff from ESC Designated Approver(s)  Produce the preliminary for: Project Plan  Provide Project Management Project Schedule (MS Project Format) Information Master Test Plan Master Training Plan  Perform Project Start Tasks Quality Assurance Plan System Rollout Plan Transition to Operations Business Continuity – Disaster Recovery Plan (Contractor input only) Standards for Content and Format - Microsoft Project, SI standard templates and DoIT standard templates. Quality Review - ESC designated team member(s)

Deliverable Number 4: Driver Services (Rollout 1) Definition of Requirements and Specifications Description : Deliverable Acceptance Criteria – Contractor will obtain signoff from ESC Designated Approver(s)  General Requirements for the documents listed in 4.14 in accordance with Exhibit D.  Customer Requirements Definition and Specification Standards for Content and Format - SI Implementation Specification format.

PAGE | 26  Driver Requirements Quality Review - Definition and Specification  Financials Requirements ESC designated team member(s) Definition and Specification  The Office Requirements Definition and Specification  Partner Management Requirements Definition and Specification  Business Rules Requirements Definition and Specification  History and Audit Requirements Definition and Specification  Driver Interfaces Requirements Definition and Specification  Interface Definition Documents  Web Services/Portal – Web- Services Requirements Definition and Specification  Requirements Tracing  Review Preliminary Specifications

Deliverable Number 5: Rollout 1 Base Configuration

Description : Deliverable Acceptance Criteria –  General system navigation Contractor will obtain signoff from ESC Designated Approver(s) configuration for the Base Configuration demonstration.  General customer adding and Standards for Content and Format - navigation (including IDs, SI’s COTS database tables and tool set. names, addresses, etc.) Quality Review -  General account adding and navigation (including IDs, ESC designated team member(s) names, addresses, attributes and basic functionality)

Deliverable Number 6: Rollout 1 Development and Unit Test

Description : Deliverable Acceptance Criteria – Contractor will obtain signoff from ESC Designated Approver(s) for test bursts of 6.6.

PAGE | 27  Continue to install Standards for Content and Format - implementation specification SI COTS database tables and tool set. beyond base configuration, Quality Review - including. o developing letters, ESC designated team member(s) o developing reports, o developing interfaces, o developing web services o developing site- specific programming, o configuring business rules including parameters and edits. o installing application security requirements  In addition, each developer performs tests (unit testing) of each function in order to ensure functions are ready for system testing by business users.

Deliverable Number 7: Conversion and Migration Rollout 1

Description : Deliverable Acceptance Criteria – Contractor will obtain signoff from ESC Designated Approver(s) o Inventory Data Stores based on Rollout 1 go-live. Prepare Conversion Data o Standards for Content and Format - Purification Approach & Plan o Perform Data Purification SI standard templates, DoIT standard templates, SI’s COTS database tables and tool set.

PAGE | 28 o Prepare Conversion Quality Review - Approach & Plan (non-data ESC designated team member(s) purification plan) o Review Conversion Plan o Build/Test Conversion Extract Modules o Build/Test Conversion Load Modules o Data Mapping and Translation o Run Partial Mock Conversions o Run Full Mock Conversions o Develop Conversion Verification and Reconciliation Reports o Review Conversion Reports Run Conversion for Production (occurs during Rollout Phase)

Deliverable Number 8: Testing Rollout 1s

Description : Deliverable Acceptance Criteria –  System Testing Contractor will obtain signoff from ESC Designated Approver(s) o Train the testers on for the Rollout 1 Test results. the system and best Standards for Content and Format - testing practices. SI standard templates and COTS tool set.

PAGE | 29 o Provide FastDS-VS Quality Review - core test scenarios. ESC designated team member(s) o Track pass, fail and rework status of test scenarios.  Converted Data Testing o Ensure data moved from legacy system works in conjunction with FastDS-VS business functions. o Ensure accuracy of data moved from legacy systems.  Performance Testing o Ensure functions meet performance requirements. o Provide tuning of database tables, configuration and site-specific code.  Security Testing o Ensure correct functions exist in system security. o Ensure security roles contain correct functions. o Ensure end-user are assigned to correct roles. o Ensure single factor and multi-factor authentication are working properly based upon user group.  End-to-end Testing o Ensure functions within, and across, subsystem work in conjunction with one another. o Ensure business lines results are achieved based upon start-to-finish scenarios as opposed to individual function scenarios.

PAGE | 30 Deliverable Number 9: Training Rollout 1

Description : Deliverable Acceptance Criteria – Contractor will obtain signoff from ESC Designated Approver(s) Train the Trainer for up to (40) for delivery of the Train the Trainer sessions. persons. The TRD trainers are then responsible Standards for Content and Format - for simultaneous regional training just SI standard template and DoIT standard template for training previous to the ‘Big Bang’ go live for each Release (Driver and Vehicle) plan. SI’s COTS package for delivery. SI-provided base training materials, with TRD provided site Specifics include: specific revisions. o Training Approach Development Quality Review - o Needs Assessment Meetings ESC designated team member(s) o Training Course Development o Curriculum Development o Course Scheduling o End User Training o Post Rollout Training

Deliverable Number 10: Cutover/Implementation Rollout 1

Description : Deliverable Acceptance Criteria – Contractor will obtain signoff from ESC Designated Approver(s) o Refine Cutover Plan upon the successful Driver go live. o Refine Desk-side Support Plan Standards for Content and Format - o Refine Operations Transition Plan SI standard templates, DoIT standard templates, SI’s COTS o Prepare Business Cutover database tables and tool set. Checklist Quality Review - o Develop Cutover Calendar ESC designated team member(s) o Prepare Project / Technical Cutover Checklist o Refine Production Support Plan o Refine Desk side Support Plan o Help Desk Setup o Run/Verify Conversion o Input/Verify Held Batches o Cutover o Update Disaster Recovery Plan o Update Technical Documentation o Production Support Lessons Learned

PAGE | 31 Deliverable Number 11: Driver Knowledge and Skill Testing Module (DKSTM)

Description : Deliverable Acceptance Criteria –  Deliver and install the Driver Contractor will obtain signoff from ESC Designated Approver(s) Knowledge and Skill Testing for the Driver Knowledge and Skill Testing Module. Module.  Include testing approach, Standards for Content and Format - training materials and Train SI standard templates, DoIT standard templates, SI’s COTS the Trainer sessions. database tables and tool set. Quality Review - ESC designated team member(s)

Deliverable Number 12: Vehicle and Dealer Services (Rollout 2) Definition.

Description : Deliverable Acceptance Criteria –  General Requirements Contractor will obtain signoff from ESC Designated Approver(s)  Vehicle Requirements for the documents listed in 12.17 in accordance with Exhibit D. Definition and Specification Standards for Content and Format - SI Implementation Specification format.

PAGE | 32  Dealer Management Quality Review - Requirements Definition and Specification ESC designated team member(s)  Financials Requirements Definition and Specification  The Office Requirements Definition and Specification  Partner Management Requirements Definition and Specification  Business Rules Requirements Definition and Specification  History and Audit Requirements Definition and Specification  Vehicle and Dealer Management Interfaces Requirements Definition and Specification  Interface Definition Documents  Web Services and Eservices Requirements Definition and Specification  Define integration with existing COTS packages  Validate/Review Requirements  Training Team Planning  Prepare Preliminary Specifications  Requirements Tracing  Review Preliminary Specifications

Deliverable Number 13: Rollout 2 Base Configuration

Description : Deliverable Acceptance Criteria –  General customer adding and Contractor will obtain signoff from ESC Designated Approver(s) navigation (including IDs, for the Base Configuration demonstration. Standards for Content and Format - names, addresses, etc.)  General account adding and SI’s COTS database tables and tool set. navigation (including IDs, Quality Review - names, addresses, attributes ESC designated team member(s) and basic functionality)

Deliverable Number 14: Rollout 2 Development and Unit Test

PAGE | 33 Description : Deliverable Acceptance Criteria –  Continue to install Contractor will obtain signoff from ESC Designated Approver(s) implementation specification for test bursts 14.6. beyond base configuration, Standards for Content and Format - including. SI COTS database tables and tool set. o developing letters, o developing reports, Quality Review - o developing ESC designated team member(s) interfaces, o developing web services o developing site- specific programming, o configuring business rules including parameters and edits. o installing application security requirements  In addition, each developer performs tests (unit testing) of each function in order to ensure functions are ready for system testing by business users.

Deliverable Number 15: Conversion and Migration Rollout 2

Description : Deliverable Acceptance Criteria – Inventory Data Stores o Contractor will obtain signoff from ESC Designated Approver(s) o Prepare Conversion Data for Rollout 2 go-live. Purification Approach & Plan Standards for Content and Format - o Perform Data Purification SI standard templates, DoIT standard templates, SI’s COTS database tables and tool set.

PAGE | 34 o Prepare Conversion Quality Review - Approach & Plan (non-data ESC designated team member(s) purification plan) o Review Conversion Plan o Build/Test Conversion Extract Modules o Build/Test Conversion Load Modules o Data Mapping and Translation o Run Partial Mock Conversions o Run Full Mock Conversions o Develop Conversion Verification and Reconciliation Reports o Review Conversion Reports Run Conversion for Production (occurs during Rollout Phase)

Deliverable Number 16: Testing Rollout 2

Description : Deliverable Acceptance Criteria –  System Testing Contractor will obtain signoff from ESC Designated Approver(s) o Train the testers on for the Rollout 2 Test results. the system and best Standards for Content and Format - testing practices. SI standard templates and COTS tool set.

PAGE | 35 o Provide FastDS-VS Quality Review - core test scenarios. ESC designated team member(s) o Track pass, fail and rework status of test scenarios.  Converted Data Testing o Ensure data moved from legacy system works in conjunction with FastDS-VS business functions. o Ensure accuracy of data moved from legacy systems.  Performance Testing o Ensure functions meet performance requirements. o Provide tuning of database tables, configuration and site-specific code.  Security Testing o Ensure correct functions exist in system security. o Ensure security roles contain correct functions. o Ensure end-user are assigned to correct roles. o Ensure single factor and multi-factor authentication are working properly based upon user group.  End-to-end Testing o Ensure functions within, and across, subsystem work in conjunction with one another.  Ensure business lines results are achieved based upon

Deliverable Number 17: Training Rollout 2

PAGE | 36 Description : Deliverable Acceptance Criteria – Train the Trainer for up to (40) Contractor will obtain signoff from ESC Designated Approver(s) persons. for delivery of the Train the Trainer sessions. The TRD trainers are then responsible for simultaneous regional training just Standards for Content and Format - previous to the ‘Big Bang’ go live for SI standard template and DoIT standard template for training each Release (Driver and Vehicle) plan. SI’s COTS package for delivery. Specifics include: Quality Review - o Training Approach Development ESC designated team member(s) o Needs Assessment Meetings o Training Course Development o Curriculum Development o Course Scheduling o End User Training o Post Rollout Training

Deliverable Number 18: Cutover/Implementation Rollout 2

Description : Deliverable Acceptance Criteria – o Refine Cutover Plan Contractor will obtain signoff from ESC Designated Approver(s) o Refine Desk-side Support Plan upon the successful Vehicle go live. o Refine Operations Transition Standards for Content and Format - Plan o Prepare Business Cutover SI standard templates, DoIT standard templates, SI’s COTS Checklist database tables and tool set. o Develop Cutover Calendar Quality Review - o Prepare Project / Technical ESC designated team member(s) Cutover Checklist o Refine Production Support Plan o Refine Desk side Support Plan o Help Desk Setup o Run/Verify Conversion o Input/Verify Held Batches o Cutover o Update Disaster Recovery Plan o Update Technical Documentation o Production Support Lessons Learned Deliverable Number 19: Driver Release, Final Acceptance

PAGE | 37 Description : Deliverable Acceptance Criteria – Final Acceptance Report, which will Contractor will provide Final Acceptance Report which will include: include: Summary of Application Functionality, Summary of known Application Defects, Summary of System Performance,  Summary of Application Training Results, Summary of Help Desk Tickets, and Technical Functionality, Documentation. All deliverables will be submitted to the Procuring Agency ESC for  Summary of known review and approval. Application Defects, Standards for Content and Format -

 Summary of System SI standard templates, DoIT standard templates, SI’s COTS database tables and tool set. Performance, Quality Review -  Training Results, ESC designated team member(s)

 Summary of

 Help Desk Tickets,

 and Technical Documentation and Summary of Site Support.

Deliverable Number 20: Vehicle Release, Final Acceptance

Description : Deliverable Acceptance Criteria – Contractor will provide Final Acceptance Report which will Final Acceptance Report, which will include: Summary of Application Functionality, Summary of include: known Application Defects, Summary of System Performance,  Summary of Application Training Results, Summary of Help Desk Tickets, and Technical Functionality, Documentation and Summary of Site Support.

 Summary of known All deliverables will be submitted to the Procuring Agency ESC for review and approval. Application Defects, Standards for Content and Format -  Summary of System SI standard templates, DoIT standard templates, SI’s COTS Performance, database tables and tool set.

PAGE | 38  Training Results, Quality Review - ESC designated team member(s)  Summary of

 Help Desk Tickets,

 and Technical Documentation and Summary of Site Support.

4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable.

DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED

4 Driver Services (Rollout 1) Definition of Requirements and Specifications Business and IT PM 5 Rollout 1 Base Configuration Business and IT PMs Complete 6 Rollout 1 Development and Unit Test Business and IT PMs Complete 7 Conversion and Migration Rollout 1 Business and IT PMs Complete 8 Testing Rollout 1 Business and IT PMs Complete 9 Training Rollout 1 Business and IT PMs Complete 10 Cutover/Implementation Rollout 1 Business and IT PMs Complete 11 Driver Knowledge and Skill Testing Module (DKSTM) Business and IT PMs Complete 12 Vehicle and Dealer Services (Rollout 2) Definition Business and IT PMs 13 Rollout 2 Base Configuration Business and IT PMs 14 Rollout 2 Development and Unit Test Business and IT PMs 15 Conversion and Migration Rollout 2 Business and IT PMs 16 Testing Rollout 2 Business and IT PMs 17 Training Rollout 2 Business and IT PMs

PAGE | 39 DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED 18 Cutover/Implementation Rollout 2 Business and IT PMs 19 Driver Release, Final Acceptance Business and IT PMs 20 Vehicle Release, Final Acceptance Business and IT PMs

4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

Step Activity Responsible Step # 1 Draft deliverable document, or complete TRD PM Team product artifact. Step # 2 Submission for Review to MVD TRD PM Team Step # 3 Review Comments provided by MVD Designated TRD Project Member(s) Step # 4 Analysis of Review Comments by TRD PM Team Contractor Step # 5 Joint meeting to review comments and TRD PM Team& Designated TRD finalize the action to be taken Project Member(s) Step # 6 Update deliverable document, or project TRD PM Team artifact & Submission for Review & Approval Step # 7 Approval of Deliverable Document Designated TRD Project Member(s) .

5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS) A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Describe the work activities that comprise the work breakdown structure (WBS) or the work packages within the WBS. Identify the WBS element or other work package identifier and provide a general description of the tasks or activities, the definition or objectives, and the milestones and deliverables of each work package. Use the chart below for highest level presentation, and provide a more detailed WBS as an attachment to this project plan.

PAGE | 40 Identifier Work Package Description Definition/Objective Milestone/Deliverable 1.0 Driver Release 1.1 Refine Project Complete project TRD sign-offs Management Plan(s) planning and associated plan documents 1.2 Definition Identify business TRD sign-offs requirements and design, develop, and configure in the development environment. This includes implementation specifications plus confirmation of design and configuration. 1.3 Base Configuration Base configuration TRD sign-offs identifies Basic navigation and functionality agreed upon between Procuring Agency, and SI and installed and demoed in the test environment. 1.4 During the Base Development and Unit Configuration and TRD sign-offs Test Development phases, four questions will be answered: 1. Can configuration meet the requirement? 2. Can the business process be altered to conform to the new system? 3. Should the feature be incorporated into the core COTS system? 4. Consider customization with site components? 1.5 The data conversion Conversion process is iterative, TRD sign-offs beginning with a plan. Mock conversions are conducted, after which the converted data is verified and reconciled, and/or changes are made to the data conversion and migration process.

PAGE | 41 5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE The project timeline is a high-level view of project activities with a focus on project milestones. The project timeline does not replace the need for a detailed project schedule and it is to highlight key events such as deliverable due dates and when go/no-go decisions are made. *** Note: All of the dates are predicated on a November 4 start date. Just prior to the contracts being submitted to the signature process, all project dates will be changed here and on the contracts to more accurately reflect a feasible start date.

TASK Duration End*** Driver 1. Refine PM Plan 4/11/2014 2 Definition 07/24/2014 3 Base Configuration 07/25/2014 4 Development and Unit Test 02/02/2015 5 Conversion 5/24/2015 6 Testing 5/14/2015 7 Training 5/14/2015 8 Rollout 5/25/2015 9 Driver Knowledge and Skills 5/25/2015 VEHICLE 2 Definition 10/07/2015 3 Base Configuration 10/7/2015 4 Development and Unit Test 6/3/2016 5 Conversion 9/4/2016 6 Testing 9/2/2016 7 Training 8/25/2016 8 Rollout 9/5/2016

PAGE | 42 5.3 PROJECT BUDGET (TO END OF IMPLEMENTATION)

FY15 & FY16 FY17 Prev Actual Bud Planned Total Personal Services & $3,527.0 $3,135.9 $1,874.3 $8,537.2 Employee Benefits Professional Services $13,622.4 $5,318.2 $7,543.9 $26,484.5 Travel/Lodging/Rent $506.1 $503.0 $280.0 $1,289.1 IT Maintenance $310.4 $550.0 $200.0 $1,060.4 IT Supplies/Inv $174.8 $135.0 $0.00 $309.8 Exempt IT Equip, HW & SW $782.1 $0.00 $1,019.9 $1,802.0 Other Financing Uses $0.00 $0.00 $0.00 $0.0 Total $18,922.8 $9,642.1 $10,918.1 $39,483.0

PAGE | 43 5.4 PROJECT TEAM

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

5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES

ROLE RESPONSIBILITY NAME FUNCTIONAL AREA Established via negotiation & contractually determined

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

PAGE | 44 5.5.1 PROJECT STAFF

Cost Estimated Resource Estimate Hours Availability Skill Set Work Product/Deliverable

ITD just requires two Included in Contract DBAs, in addition budget to the existing Contractors for workload shift.

MVD Included in Raul Alvarez Budget Adam Diamond Kenric Hindi Joann Sugamosto Kristina Romero Darren Gomez Vehicle Services R2 Yvette Martinez Vanessa Griego David Chavez Jonathan Roybal Noel Davis Barbara Roybal Melissa Ponce

PAGE | 45 5.5.2 NON-PERSONNEL RESOURCES Use this section to list services or product (HW/SW and such) needed for project

Cost Estimated Resource Estimate units/hours Availability Source Work Product/Deliverable

(2) Contract Business Included in Analysts budget

(1) Contract DMS Level 3 Expert (depends on personnel request FY15) Included in (1) ITD PMO Business budget Analyst – State Employee (?) Contract Organizational Change SMEs Included in Contract Data Conversion budget

Included in Contract Workload Shift – budget ITD &MVD FY15 & Contract for rewrite of FY16 DMS, IVR, and Q-matic budgets interfaces

5.6 PROJECT LOGISTICS Logistics describes how the project manager, project team, the business owner/customer and any vendor resources will physically work together. Include anything to do with moving or starting resources. Training specifically related to project team members should be included here.

5.6.1 PROJECT TEAM TRAINING Describe training if any needed by project team members. This is not to include training for end users, system administrators or business owners; those should be handled within a training document or part of the transition to operations planning.

PAGE | 46 Cost Estimated Work Resource Estimate Hours Availability Skill Set Product/Deliverable

BA and SME Training 8 Understanding of basic Driver Business Functions. Basic navigation of web browsers

ITD Developer Training 32 Strong understanding of programming concepts. That is, parameters, loops, etc. Good to excellent SQL skills. Moderate to strong people skills.

6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT PMBOK©: Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” Issue: “A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.” Both Risks and Issues can significant impact a project’s success, and both should be handled in similar ways.

6.1.1 RISK MANAGEMENT STRATEGY TRD is a risk-adverse organization and could therefore be qualified as a risk-averter. Risk management has already started with the selection of a COTS product with demonstrated, successful implementations in two states. No other competing product was able to demonstrate successful implementation. This is an example of risk avoidance. The hiring of an outside firm to perform PM activities and including a Business Architect and a Systems Architect on that team are an example of the secondary strategy TRD intends to employ for this project, transfer of the risk. All certified projects need to contract with an IV&V vendor, as does this project. This is an example of how the remaining risk can be mitigated, the third risk strategy available to TRD. Continuing forward the strategy TRD will pursue in relation to negative risks or threats is the strategy of avoidance, followed by transfer, mitigation and acceptance. To the extent TRD can realize the 2012 ‘MVD Vision of the Future’, TRD will employ the positive risk strategy of exploitation.

PAGE | 47 TRD and Contractors will create a Risk Management Plan and monitor and control against that plan throughout the project. The Risk Management Plan will include the common PMBOK components:  Methodology  Roles and Responsibilities  Definitions  Probability and impact analysis  Stakeholder tolerances  Budgeting  Timing  Reporting formats  Tracking  And the DoIT Risk and Issue Log Template or other agreed upon format

6.1.2 PROJECT RISK IDENTIFICATION The first step to creating a Risk Management Plan is risk identification. After identifying risks the team will continue with qualitative and quantitative risk analysis and risk response planning. All of these activities will include a cross-functional team from the larger project team, including selected external stakeholders. Identifying risks is an iterative process because new risks may evolve or become known as the project progresses through its life cycle. The frequency of iteration and who participates in each cycle will vary during the project and be monitored and controlled by the Contract PM Team. During each risk identification cycle, the team will use any of the following inputs to the process as needed or considered necessary:  Risk Management Plan  Cost estimates  Time estimates  Scope baseline  Stakeholder register  Cost Management Plan  Schedule Management Plan  Quality Management Plan  Project documents or other artifacts  Enterprise environmental factors  Organizational process assets Tools used for risk identification will include, but not be limited to:  Documentation/artifact reviews  System reviews  Information gathering techniques  Checklist analysis  Assumptions analysis  Diagramming techniques

PAGE | 48  SWOT analysis  Expert judgment The deliverable of this activity will be a risk register, or the DoIT equivalent, ‘Risk and Issue Log’.

6.1.3 PROJECT RISK MITIGATION APPROACH TRD’s risk adverse position will always favor a risk avoidance approach. However, when the risk cannot be avoided, the mitigation strategy will be considered. Risk mitigation implies a reduction in the either the probability and/or impact of a negative risk event. Therefore, the impact\probability matrix offers an excellent starting point for understanding and planning for risk mitigation. The TRD approach would be to first concentrate on those risks with either a high impact or a high probability of occurrence. For each of those a brief root cause analysis would be performed to understand the source of either the high impact or the high probability. Then the team would brainstorm methods for reducing either the impact or the probability. Consensus would be reached regarding the course to pursue, and the necessary tasks would be executed to mitigate the risk.

6.1.4 RISK REPORTING AND ESCALATION STRATEGY TRD will use the standard DoIT project status report which includes risk and issues. Status reports will be created and submitted by the Contract PM Team weekly. Therefore any changes to the risk profile of the project will be considered weekly with the status report any changes\additions to what those previously identified. http://www.doit.state.nm.us/project_templates.html Any team member has obligation to immediately report significant changes or additions to risk to their immediate supervisor on the project. As quickly as possible these must be escalated to the Contract PM Team for reporting in the next status meeting\report. The Sponsor, Business Owner, and TRD CIO should be immediately notified of any risk jeopardizing project success, or any risk for which a mitigation strategy has not been initiated in a timely manner.

6.1.5 PROJECT RISK TRACKING APPROACH TRD will use either a risk register or the standard DoIT ‘Risk and Issue Log’. The Contract PM is responsible for monitoring and controlling this tracking devise, and reviewing weekly at the time of the status report. Contract PM will also be responsible for escalating critical risks, or strategies that have stalled, to executive management. Contract PM will also be responsible for convening additional risk analysis cycles during the project implementation.

6.1.6 ISSUE MANAGEMENT The project’s proactive processes for issue management provide a continuous cadence to identify, track, and resolve issues quickly and at the appropriate staffing level to realize the project’s goals and objectives.

PAGE | 49 6.1.6.1 Internal Issue Escalation and Resolution Process The following figure depicts the Issue Resolution Process. Each step is described in detail together with the responsible staff at each stage of the process. This is a simple process that will handle management, resolution, and escalation of problems, risks, and issues.

6.1.6.2 External Issue Escalation and Resolution Process The external process is provided for issues that involve project resources, processes, procedures, or methodology that cannot be resolved within the Agency that is responsible for managing the project without affecting the overall project schedule, cost, or quality. Escalation will occur through the escalation path defined in the Project Governance structure.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V The IV&V contract is currently in eReview. TRD made a conscious decision to add a Business Architect and Technical Architect to the Contract PM Team. The company selected for the PM Team contract has presented two individuals with much greater depth in the areas of requirements management, quality management, test management, and technical architecture

PAGE | 50 analysis. Therefore, the strategy pursued via the IV&V contract, is to have the IV&V vendor serve more of the role of verifying and validating that processes have been correctly followed and that the correct identification, monitoring, and controlling activities are being performed effectively.

6.3 SCOPE MANAGEMENT PLAN Scope management and change control are critical to maintaining schedule, achieving the desired outcomes on time, deploying on time, and delivering to the expected level of quality. Project scope is not static and may evolve, which emphasizes the importance of proper scope control. Project scope management is conducted in the context of program-level integrated planning and dependency management, allowing alignment between individual stages of the project and other concurrent efforts to produce the desired project results. The scope management process includes: Submitting any changes or waiver of RFP requirements to the Weekly Executive Meeting for ratification or change. Maintaining contractual compliance and overseeing orderly revisions to the contract, if necessary, throughout project execution Tracking contractual commitments and deliverables and monitoring progress toward completing them against contractual requirements and due dates

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

Figure 1 Tapestry Scope Management and Quality Assurance

For Tapestry, the scope baseline is the 700+ requirements from the RFP. These are loaded into a Requirements section of a Tapestry version and instance, of Fast Enterprises FCR, for each project release (driver and vehicle). During the Definition and Baseline Configuration phases of each release, the sessions determine how the mandatory requirements will be satisfied within the Fast DS-VS COTS package. The contract allows for the changing or waiving of certain requirements by the written approval of TRD executives. This is accomplished in the Weekly Executive Meeting via WEM Decision Requests (DR). The WEM can either decide to agree with the DR as drafted, request a revision, or request the DR be withdrawn. DRs approved result in auditable changes to the Requirements in the FCR tool. Requirements are then linked in a separate portion of the FCR tool (Project), to Test Scenarios and their associated test criteria.

Scope Verification Due to the iterative nature of the SDLC employed for Tapestry, several verification points exist during the project. The first scope verification occurs at the end of the Definition phase for each release. At this time the Core team for the functional or support area reviews and accepts the Implementation Spec for their specific area. For the Tapestry project Driver Release, this task was completed the week of July 7, 2014. Another checkpoint for scope validation occurred the same week, Base Configuration demo. The project team for a functional area assembles to view a demo of the system as configured to date, and approves or requests revisions to the current version of the New Mexico instance of Fast DS-VS. These signoffs were also obtained the week of July 7, 2014. A scope validation continues throughout unit, system, and end-to-end testing, until the QA reports show that all requirements for the given release have been included in test scenarios, and that all requirements for a given release have been successfully tested and signed off by SME leads and the assigned Business Analyst for the specific functional team. The Fast FCR tool core was modified to create, maintain, and track throughout project processes a true Requirements Traceability Matrix.

PAGE | 52 6.3.1 CHANGE CONTROL

6.3.1.1 Change Control Process A primary reason for choosing the selected system vendor is that this is a ‘true’ COTS package. What TRD considers a ‘true’ COTS package includes the following features:  System Code Base is not modifiable by the customer organization  Installation of the package in a new jurisdiction is via configuration changes. No code changes are made for a new jurisdiction.  A product management process exists within the vendor organization, that is responsible for creating upgrade releases that are provided to their clients for installation Due to all the above, the SI strategy is to have zero Change Orders during the project implementation. Should Change Orders actually exist during this project, the typical TRD process will apply the same as used by the team maintaining the Tax systems: During the course of the project, issues will occur that influence the scope of the project. These issues may either be requirements in the form of additional complexity or new deliverables. These potential increases to the project scope must be properly managed and approved before they can be incorporated into the project’s work effort. The following outlines a process for managing change control. . Upon discovery of a potential project change, the Project manager shall ensure the new requirement is sufficiently documented using the Decision Request form. . A request is initiated by the end user, management or the project team. . The project team performs the necessary analysis to determine the cost, time estimates and other potential impacts to the project. . The Project Manager completes the Decision Request form and presents it to the Executive Steering Committee . The Executive Steering Committee either approves or rejects the request and the Decision Request is closed. . If approved, the project manager formally documents the change in both the Project Plan and Project Schedule. . Throughout this process, the project manager documents the status of each proposed change in the weekly status report and the change control log.

6.3.1.2 Change Control Board (CCB) The Change Control Board for this project will be the Executive Steering Committee. All scope changes will be logged by the Contract Project Management Team in the change system with any impact reported in status and other associated project documents. The project manager will manage all change control processes for the system utilizing the change management system.

PAGE | 53 6.4 PROJECT BUDGET MANAGEMENT Project budget management will be the responsibility of the MVD Finance Bureau, in collaboration with the Contract PM Team. Costs estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable). Separate accounts under DRIVE MVD will be set up for the TRD DMS project. Standard procedure will be adhered to for this project, a monthly budget report will be created at the end of each month by our Administrative Services Division of TRD. Projects are assigned to individuals in this division on a rotating basis, so it is not known at this time who will be the project budget analyst.

6.4.1 BUDGET TRACKING Monthly reports from the TRD Administrative Services Division, and the MVD Finance Bureau will include the project budget and expenditures, encumbered POs and unencumbered POs for the project to date.

6.5 COMMUNICATION PLAN

The usual Executive Communications Reporting will be used for this project, within the structure of the DRIVE MVD Executive Steering Committee.

Description Target Delivery Frequency Responsible Standard Audience Method Party

TRD TAPESTRY Project TRD CIO Face-to-Face Weekly  TRD Lead Recurring Status Meeting Project meetings are scheduled To discuss project status Manager through with the TRD CIO Outlook Uses standard format

PAGE | 54 Description Target Delivery Frequency Responsible Standard Audience Method Party

TRD TAPESTRY Project Meeting Face-to-Face Weekly  TRD Project Recurring Management Status attendees Managers meetings are Meeting (PMs, PA, (owns scheduled Requirements through Regularly scheduled meeting Leads) Outlook meetings: notice; Meeting contributes Uses standard To discuss project minutes are agenda format activities, progress, issues stored in the topics) and results of An agenda is Project measurement and analysis  Contractor distributed in Repository activities. Project advance. Analyst Event driven: (scribe) When new requirements are added, existing requirements are changed, etc

TRD TAPESTRY Steering Meeting Conference Once  Project Recurring Committee Attendees call or in monthly, Managers meetings are (PMs, Account person beginning in scheduled This formal meeting Exec, DMV June 2010 through addresses the Delivery Outlook accomplishments and Executive, TRD results of the project with Uses standard CIO, MVD the client. These meetings format Director, address commitments, Project An agenda is plans, risks, status of Analyst) distributed in activities and significant advance. issues for the project, as Meeting well as how the project fits minutes are into the current business stored in the environment and the Project communication of the Repository results of measurement and analysis activities.

MVD DRIVE Steering Meeting Face-to-Face Bi-weekly TRD Lead Recurring Committee Attendees Project meetings are (PMs, TRD CIO, Manager scheduled This formal meeting MVD Director, through addresses the MVD Deputy) Outlook accomplishments and results of all MVD projects. Uses standard format

TRD TAPESTRY Status Client Project Word Weekly, by Status report Report Managers Document COB Monday template To describe the status of Status Reports Email the project to the client are stored on the Project Repository

DoIT TRD TAPESTRY DoIT Word Monthly  Contract Follows DoIT Project Status Document PM Team Standard To describe the status of Email the project to DoIT

PAGE | 55 Description Target Delivery Frequency Responsible Standard Audience Method Party

TRD TAPESTRY Change Attendees Group As needed  Change Meetings are Control Board (CCB) (PMs, PA, Meeting or Control scheduled Meeting Requirements conference Board Chair through Leads) call Outlook as Review, evaluate, approve needed. or reject, and prioritize For contract change requests. Group changes, An agenda is approved change requests additionally distributed in into releases. Contractor advance. Account Exec, DMV Practice Lead, ITD CIO, MVD Director Meeting minutes are stored in the Project Repository

Issue Tracking and Captured and Project Whenever an  Project External Escalation stored in the Repository issue arises or Managers Issue Project needs Resolution To provide a framework for E-mail, Repository management and documenting and tracking conference involvement Escalation issues to closure and call or in for resolution. Procedure escalating long-standing or person critical issues for senior leadership attention.

PAGE | 56 6.5.1 COMMUNICATION MATRIX

The following will be completed with the next draft of the Communications Plan. The first draft was received during Clarification.

Type Name/Nature of (Man/Mkt Format Delivery Communication From To Content Provided By g/Info) Frequency Used Media Comments Sponsors

Urgent Issues Program Manager, Executive Program Manager, Project As needed E-mail The Program Manager will Program Director Sponsor, Program Managers, External collect this issue and add Sponsor Stakeholders an entry in the Issues Log.

Issues Updates/ Executive Sponsor, Program Director, Executive Sponsor, As needed Verbal updates, The Program Manager will Resolutions Program Sponsor Program Manager Program Sponsor E-mail, Memos update the Issue and associated Log.

Status Report Program Manager Program Director Program Manager, Mandatory Monthly Status Report E-mail or The Program Manager will Project Managers form Shared Storage pull information gathered from the program status reports.

Special Program Manager Executive Team Program Manager, Information As needed To be Meeting Presentation or Program Director al determined, Meetings for based on Updating requirements Executives Team Members

PAGE | 57 Type Name/Nature of (Man/Mkt Format Delivery Communication From To Content Provided By g/Info) Frequency Used Media Comments

New Program Program Manager, Program Manager Project Managers, Project (1) Weekly (via the (1) Project (1) E-mail (1) If new issue/action item Issues or Action Project Managers Team Members, and other Project Status Status Report is received through the Items and Team members, persons Report) form (2) Lotus Notes Project Status Report, the and other persons Issues/Action Program Manager will log (2) As needed (via (2) Standard Items it after discussing them Program Manager) Issue or databases. during the Program Status Action Item (3) As needed (via (3) Meeting meeting. (Persons outside Submission the team can only use the Stakeholder form by Minutes within Meeting minutes) Program project log new Program issues/action items.) Manager Manager. (2) If new issue/action item (3) is “Submitted” the Stakeholder Program Manager will Meeting “approve” the issue and Minutes also bring it up for document discussion during the Program Status meeting (3) The scribe from the Stakeholder Meeting will submit these issues; the Program Manager will “approve” the issue and also bring it up for discussion during the Program Status meeting

Issue Items Program Manager, Program Manager Program Manager, Project (1) Weekly (via the (1) Project (1) E-mail (1) If the Status / Updates / Project Managers Managers, Project Team Project Status Status Report status/update/resolution is Resolution Members Report) form (2) Lotus Notes received through the Issues/Action Project Status Report, the (2) As needed (2) Lotus databases Program Manager will Notes enter it into program log. “Response” form Status/updates will be submitted as “Responses” to a main-topic record in Program Log. If a resolution is received as a “Response” to a main-topic in the databases, the program manager will enter the resolution in the main record and close out the issue/action item.

PAGE | 58 Type Name/Nature of (Man/Mkt Format Delivery Communication From To Content Provided By g/Info) Frequency Used Media Comments

Change Requests Project Managers Program Manager Project Managers Mandatory As needed Standard E-mail These change requests will Change be submitted to the Request form program manager, discussed at the weekly Program Status meetings, and captured in the control files database.

Project Status Project Managers Program Manager Project Managers and Weekly (by Standard E-mail These reports will serve as Reports Team Members Tuesday 12:00 Status Form inputs for discussion at the PM) weekly Program Status meeting

Program Status Program Manager Program Manager Program Manager, Project Weekly Standard Program This will be developed as a Report database Managers Status Report Manager result of the weekly Form control file Program Status meeting and will also serve as the meeting minutes Stakeholders

New Issues/Action Stakeholders Program Manager Stakeholders Bi-Weekly Discussions Issues/Action The scribe will capture Items during bi- Items section of issues/action items and weekly meeting maintain a running log stakeholders minutes through the meeting meeting minutes document. The scribe will also submit these issues/action items via the Program Manager database.

Issues/Action Program Manager Stakeholders Program Manager, Project Bi-Weekly Program Stakeholders The program manager will Items Managers, Team Members Management Meeting review the open Status/Updates/Re update during issues/action items with the solutions stakeholders project teams and provide meeting. update, capturing all within the Program Manager database.

PAGE | 59 Type Name/Nature of (Man/Mkt Format Delivery Communication From To Content Provided By g/Info) Frequency Used Media Comments

Urgent Program Director Team & External Program Manager, As needed TBD E-Mail/Voice As critical information Information Stakeholders Program Director, Project Mail, as such as newly developed Impacting Team Managers appropriate issues arise, a and External (I/S) communication will be Stakeholders distributed to ensure immediate knowledge transfer.

PAGE | 60 6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) The Project Manager and Executive Sponsor define the project metrics that will be used to control the project. Each project will need to have an established metrics program. Metrics are collected for measuring the progress of a project against its planned budget, schedule, resource usage, and error rates, and of establishing a historical database, which will aid in planning and forecasting future projects. At a minimum metrics must be established for time (schedule), cost (budget) and quality.

6.6.1 BASELINES Project Area Category Measure Schedule Time A metric to determine if the project is on schedule. EVM if feasible. Budget Costs Are project deliverables within budget. EVM if feasible. Requirements Requirements Status (number A metric to show the status of approved, implemented, and each requirement in the verified) system, incorporated into the RTM. Testing Defect Density Ratio (DDR) A metric indicator for the number of defects in the system, by subsystem. A quality indicator that shows the number of defects in the system. Testing Test Case Coverage A metric to determine whether Percentage the test cases fully test system requirements. An indicator to show whether there are sufficient tests to address system requirements Testing Test Execution Percentage by A metric to indicate the Type percentage of tests executed by subsystem. The status of testing efforts

PAGE | 61 and a software quality indicator. Testing Test Execution Percentage by A metric to indicate the Type percentage of tests executed by use case and subsystem Testing Percentage of Test Cases An indicator to show the pass Passed percentage of test scenarios and test cases Testing Number of Defects Found by An indicator to show how Inspection (DFI) many defects the customer has found through inspection of the software Testing Defect Removal Effectiveness The metric can be calculated (DRE) for the entire development process, for the front-end (before code integration), and for each phase. It is called early defect removal and phase effectiveness when used for the front-end and for specific phases, respectively. The higher the value of the metric, the more effective the development process and the fewer the defects that escape to the next phase or to the field. This metric is a key concept of the defect removal model for software development.

6.6.2 METRICS LIBRARY The revised Fast FCR tool provides TRD with the opportunity to track test progress throughout the project. Examples of the types of metrics used for tracking QA efforts can be found in the Tapestry Share drive, or can be provided upon request.

6.7 QUALITY OBJECTIVES AND CONTROL Quality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control, and quality

PAGE | 62 improvement, within the quality system. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.

6.7.1 QUALITY STANDARDS Reference the baselines under 6.6.1.

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS

Review Type Quality Standard Tools Reviewer Reports

Definition See sections 4.1 and 4.2 for more detailed information.

Plans

Base Configuration

Milestones

Testing

6.7.3 AGENCY/CUSTOMER SATISFACTION MVD has an end-customer satisfaction survey in place, that could be extended to anonymously collect data regarding satisfaction with the MVD System Modernization project. In addition, the below project mechanisms and processes will be used to continuously collect additional information regarding project satisfaction.

Areas of feedback When How Often Agency awareness Staff meetings Quarterly Quality of communications Project meetings Monthly Manages project tasks Project meetings Monthly Productive Meetings At the end of random Weekly meetings Project Pace After 1st quarter Quarterly Vendor relations Internal meetings Monthly External Partners After 1st quarter Quarterly Other External Stakeholders After 1st quarter Quarterly

PAGE | 63 6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS How the client takes procession of the product. Delivery of media; manuals; contracts; licenses; services agreements; configuration settings; status of patches to COTS products; in-house or vendor developed code; test cases, routines, and scripts; and other items required to operate the product. Deliverable Final Approval Process Customer Acceptance Criteria

Driver Release 1 User Acceptance Testing Zero defects, and complete and Review and acceptance of coverage of the RFP mandatory, the results by the Executive and SI-confirmed optional Sponsor and Business Owner. requirements.

Vehicle Release 1 User Acceptance Testing Zero defects, and complete and Review and acceptance of coverage of the RFP mandatory, the results by the Executive and SI-confirmed optional Sponsor and Business Owner. requirements.

6.8 CONFIGURATION MANAGEMENT

6.8.1 VERSION CONTROL All code is stored in DI’s version control system. All configuration is stored in the database where it is logged, tracked and backed up. Project documents are stored on a standard windows file share which is backed up.

6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)

Description – A electronic structure Deliverable Acceptance Criteria – A electronic structure with containing copies of project official copies of documents collected to manage and control the management documentation project. throughout the project life cycle.

Standards for Content and Format – Insertion of all final copies of final project documents such as sign-offs, specifications, change logs, issue logs, etc. These documents should be arranged into categories and kept updated throughout the life cycle. The binder should also be retained after project closure to ensure capability to perform project audits and reviews.

Quality Review – Periodic reviews during the project with the Team Leader, TRD IT Auditor, Project Manager, and TRD PMO Manager

PAGE | 64 6.9 PROCUREMENT MANAGEMENT PLAN Hardware, software, application licenses, implementation services, and maintenance and support will all purchased under one contract with the SI. In addition, a separate contract for the team facility, furniture, and utilities will also be procured via the SI. Two other major contracts will be managed by the MVD Finance Bureau and the ITD PMO and MVD Business project team:  Contract PM Team  IV&V

7. 0 PROJECT CLOSE Project Close will always consist of administrative project activities and possibly contractual project activities and an external vendor is employed. Completing both sets of activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is responsible for managing the project, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments. Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products.

7.1 ADMINISTRATIVE CLOSE Administrative Close occurs at both the end of phase and end of project. This closure consists of verification that objectives and deliverables were met. Acceptance is formalized and phase activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in accordance with the WBS and should not be delayed to project end. At that point, the burden of closing is too great and audits inaccurate. The specific project close activities for a given project are contingent on the project’s complexity and size. Project managers should work with the project’s project management consultant to tailored Project Close procedures to compliment the project’s objectives. Activity Responsible Party Date Conclude Project Control Agency/Contractor Reassign Team Contractor Appoint Support Contacts Agency/Contractor

7.2 CONTRACT CLOSE Contract close is similar to administrative close in that it involves product and process verification for contract close. Activity Responsible Party Date Verify Project Objectives were Agency/Contractor met Verify Project Implementation Agency/Contractor Deliverables were met and accepted Complete Plan Components Contractor Complete Project Agency/Contractor

PAGE | 65 Communications

ATTACHMENTS

PAGE | 66 PROJECT SCHEDULE

Task Name Duration1 Forecast Start Forecast Finish Project Start 1 day Mon 3/3/14 Mon 3/3/14 Project Preparation Tasks Start 1 day Mon 3/3/14 Mon 3/3/14 1.0 Project Management Plan (& 1177 days Mon 3/3/14 Sat 11/1/14 Associated Items) New Mexico Driver Services - Rollout 1 day Mon 3/3/14 Mon 3/3/14 1 - Start 2.0 Definition 8997 days Wed 3/19/14 Mon 9/22/14 3.0 Base Configuration 282 days Wed 4/2/14 Fri 7/25/14 3.5 OCM 18 days Wed 3/26/14 Wed 3/11/15 4.0 Development and Unit Test 10887 days Mon 3/3/14 Tue 5/12/15 5.0 Conversion 1459 days Wed 4/2/14 Sun 5/24/15 6.0 Testing 1783.5 days Fri 6/27/14 Thu 5/14/15 7.0 Training 719 days Mon 3/3/14 Thu 6/4/15 Training Post Rollout - Review (where 9 days Tue 6/2/15 Fri 6/12/15 required for end-users) 8.0 Rollout 654 days Mon 9/29/14 Mon 8/3/15 Post Rollout 1 35 days Tue 5/26/15 Fri 7/10/15 1 day Tue 5/26/15 Tue 5/26/15 1.0 Rollout 2 Preparation (during final 55 days Mon 3/2/15 Fri 5/15/15 months of R1) Rollout 2 start 1 day Tue 6/16/15 Tue 6/16/15 2.0 Definition 82 days Wed 6/17/15 Thu 10/8/15 3.0 Base Configuration 82 days Wed 6/17/15 Thu 10/8/15 4.0 Development and Unit Test 254 days Wed 6/17/15 Mon 6/6/16 5.0 Conversion 319 days Wed 6/17/15 Mon 9/5/16 6.0 Testing 319 days Wed 6/17/15 Mon 9/5/16

PAGE | 67 7.0 Training 313 days Wed 6/17/15 Fri 8/26/16 8.0 Rollout 1 day Mon 9/5/16 Mon 9/5/16

PAGE | 68

Load more

  68

Copy Link