Driver Pro… · Web vie

NEW MEXICO DRIVERNEW MEXICO DRIVER REENGINEERING SOLUTIONREENGINEERING SOLUTION

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

EXECUTIVE SPONSOR – RICK HOMANS

BUSINESS OWNER – MICHAEL SANDOVAL

PROJECT DIRECTOR – JOEL MATEK

PROJECT MANAGER – TO BE DETERMINED

ORIGINAL PLAN DATE: OCTOBER 20, 2009REVISION DATE:

REVISION: 1.0

PROJECT MANAGEMENT PLAN FOR NEW MEXICO DRIVER REENGINEERING SOLUTION

REVISION HISTORY............................................................................................................................................ IV

PREPARING THE PROJECT MANAGEMENT PLAN..................................................................................................V

ABOUT THIS DOCUMENT.................................................................................................................................... V

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

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

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT....................................................................................................11.2 FUNDING AND SOURCES...........................................................................................................................................21.3 CONSTRAINTS........................................................................................................................................................21.4 DEPENDENCIES.......................................................................................................................................................21.5 ASSUMPTIONS...................................................................................................................................................42.1 INITIAL PROJECT RISKS IDENTIFIED.........................................................................................................................4

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................6

2.1 STAKEHOLDERS......................................................................................................................................................62.2 PROJECT GOVERNANCE STRUCTURE...........................................................................................................................8

2.2.1 Describe the organizational structure – Org Chart.....................................................................................82.2.2 Describe the role and members of the project steering committee...........................................................92.2.3 Organizational Boundaries, interfaces and responsibilities.......................................................................9

2.3 EXECUTIVE REPORTING............................................................................................................................................9

3.0 SCOPE......................................................................................................................................................... 10

3.1 PROJECT OBJECTIVES............................................................................................................................................103.1.1 Agency Objectives....................................................................................................................................103.1.2 Business Objectives..................................................................................................................................103.1.3 Technical Objectives................................................................................................................................10

3.2 PROJECT EXCLUSIONS............................................................................................................................................113.3 CRITICAL SUCCESS FACTORS...................................................................................................................................11

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................12

4.1 PROJECT MANAGEMENT LIFE CYCLE........................................................................................................................124.1.1 Project Management Deliverables...........................................................................................................124.1.1.5 Project Deliverables..............................................................................................................................144.1.2 Deliverable Approval Authority Designations..........................................................................................154.1.3 Deliverable Acceptance Procedure...........................................................................................................16

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................164.2.1 Technical Strategy...................................................................................................................................174.2.2 Product and Product Development Deliverables......................................................................................174.2.3 Deliverable Approval Authority Designations..........................................................................................184.2.4 Deliverable Acceptance Procedure...........................................................................................................19

5.0 PROJECT WORK........................................................................................................................................... 20

5.1 WORK BREAKDOWN STRUCTURE (WBS)..................................................................................................................205.2 SCHEDULE ALLOCATION -PROJECT TIMELINE..............................................................................................................225.3 PROJECT BUDGET.................................................................................................................................................225.4 PROJECT TEAM....................................................................................................................................................23

5.4.1 Project Team Organizational Structure....................................................................................................235.4.2 Project Team Roles and Responsibilities..................................................................................................24

5.5 STAFF PLANNING AND RESOURCE ACQUISITION................................................................................................27

ii OF vi


5.5.1 Project Staff.............................................................................................................................................285.5.2 Non-Personnel resources.........................................................................................................................28

5.6 PROJECT LOGISTICS.........................................................................................................................................295.6.1 Project Team Training..............................................................................................................................29

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................29

6.1 RISK AND ISSUE MANAGEMENT..............................................................................................................................296.1.1 Risk Management Strategy......................................................................................................................296.1.6 ISSUE MANAGEMENT..............................................................................................................................30

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V...........................................................................................316.3 SCOPE MANAGEMENT PLAN..................................................................................................................................32

6.3.1 Change Control........................................................................................................................................326.4 PROJECT BUDGET MANAGEMENT............................................................................................................................35

6.4.1 Budget Tracking.......................................................................................................................................356.5 COMMUNICATION PLAN........................................................................................................................................35

6.5.1 Communication Matrix............................................................................................................................366.5.2 Status Meetings.......................................................................................................................................366.5.3 Project Status Reports..............................................................................................................................36

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................376.6.1 Baselines..................................................................................................................................................376.6.2 Metrics Library.........................................................................................................................................37

6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................376.7.1 quality Standards.....................................................................................................................................376.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................386.7.3 Agency/Customer Satisfaction.................................................................................................................386.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................39

6.8 CONFIGURATION MANAGEMENT...................................................................................................................396.8.1 Version Control........................................................................................................................................396.8.2 Project Repository (Project Library).........................................................................................................40

6.9 PROCUREMENT MANAGEMENT PLAN............................................................................................................40

7. 0 PROJECT CLOSE........................................................................................................................................... 40

7.1 Administrative Close...................................................................................................................................407.2 Contract Close.............................................................................................................................................40

APPENDIX A – WORK BREAKDOWN STRUCTURE................................................................................................41

APPENDIX B - PROJECT SCHEDULE/GANTT CHART..............................................................................................42

APPENDIX C - PROJECT BUDGET........................................................................................................................ 43

APPENDIX D - RISK ANALYSIS............................................................................................................................. 44

APPENDIX E - PROJECT LIBRARY........................................................................................................................ 45

APPENDIX F - SAMPLE PROJECT FORMS............................................................................................................. 46

Project Change Request Form...........................................................................................................................46Project Status Report........................................................................................................................................47Sample issues report.........................................................................................................................................48

APPENDIX G – TRD MVD DRIVER REENGINEERING PROJECT DEFINITIONS..........................................................49

APPENDIX H – TRD MVD DRIVER REENGINEERING PROJECT ACRONYMS............................................................50

APPENDIX P - PROJECT MANAGEMENT DEFINITIONS.........................................................................................51

iii OF vi


REVISION HISTORYREVISION HISTORY

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0 October 20, 2009 Initial TRD Draft - Planning Phase

iv OF vi


PREPARING THE PROJECT MANAGEMENT PLANPREPARING THE PROJECT MANAGEMENT PLAN

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

ABOUT THIS DOCUMENTABOUT THIS DOCUMENT

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

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

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

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

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

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

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

v OF vi


1.0 Project Overview

1.1 1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECTEXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The Motor Vehicle Division (MVD) of the New Mexico Taxation and Revenue Department (NMTRD) is operating a series of hybrid mainframe/Web application systems that are outdated and difficult to maintain as the tools, operating systems, and languages date back to the 1970s and 1980s. A complicated process extracts data from all 90 individual field offices, performs required batch processing in the mainframe environment and relevant data is then replicated back to SQL Server for the next day’s processing. Connectivity issues and other events produce times when the data is out of synch causing errors and delaying customer transactions.

Business rules are often hard coded in the application code for the MVD systems. When business requirements change, it is often difficult to identify the specific code that must be modified because the code is scattered through multiple systems in multiple architectures. Qualified maintenance programmers with this expertise are scarce. Security is inadequate, and there are not appropriate audit trails to track user access.

In the fall of 2005, IBM completed a needs assessment of the business practices and the technical infrastructure utilized by MVD. They characterized the MVD system as among the worst in the country, and recommended (among other things) replacing the drivers’ services application. Also the current system is not in compliance with Federal, State, and AAMVA requirements.

Many states are moving to a customer-centric model for driver license, vehicle titling and registration systems, and financial Point-of-Sale (POS) systems. In this model, each person (e.g. person, company) has a customer record. Driver license, vehicle title and registration, and payment records all relate to the appropriate customer record. This linking of the various records provides significant benefits to our customers, to our employees, and to users such as the law enforcement community. This model is our vision for the state of New Mexico.

Purchase of a Commercial-off-the-shelf (COTS) Driver system will result in a more efficient, productive system that would improve service delivery to MVD customers while increasing reliability, security, and maintainability. This new system would be designed to meet current and future needs, including appropriate audit trails and security features. The COTS system would be something that is already proven to be successful for driver services in other states.

Driver services are not exclusively used by MVD, but data is shared with numerous other agencies. Data sharing helps improve public safety by allowing agencies like the Department of Public Safety (DPS), the Federal Bureau of Investigation (FBI), and the Transportation Security Administration (TSA) to obtain information on a real-time basis. Data is used by Human Services – Child Support Enforcement, by the Federal Motor Carrier Safety Administration (FMCSA), by other States, and by the Courts – just to name some of the current interfaces with MVD systems.

Initial planning of this project has been underway for some time; although we are showing a “Planned Start Date” of February 1, 2010. The previously-certified POS project contains software and hardware

PAGE 6


procurements that may be incorporated with this project or may be replaced completely by the Driver system depending on the results of the RFP. The exact configuration and detailed requirements will not be completed until the Driver Reengineering RFP has been awarded. TRD is currently implementing a separate project that includes the purchase of POS software and hardware.

New servers for the MVD Driver system will be located within the DoIT Data Center in TRD racks, and will be administered by TRD staff. At this time, an exact hardware configuration is not known.

Network demand is expected to be consistent with the current MVD load since all MVD transactions are already using the web-based MVD 2.0 application and eventually the POS application.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCES

SOURCESOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

Laws of 2008: Chapter 3, Section 7, Item 5

$4.12 M

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

NNUMBERUMBER DDESCRIPTIONESCRIPTION

1 IMPLEMENTATION OF ONE MODULE AT A TIME (E.G. DRIVER OR VEHICLE) CONSISTENT WITH BEST PRACTICES FROM OTHER STATES.

2

3

4

5

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

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

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

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

PAGE 7


NUMBENUMBERR

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

1 Identify, acquire, and configure vendor-provided COTS software solution to meet business requirements

E

2 Identify, acquire, and configure vendor-provided Driver hardware that is compatible w/ Central Issuance (CI), Point-of-Sale (POS), MVD Online web portal, and SHARE hardware and software environments

E

3 Integration of Driver hardware and software w/ CI, POS, and MVD Online, and SHARE utilizing web services with XML

M

4 Integration of COTS solution with POS and SHARE for daily field office bank deposits, and monthly distributions for MVD beneficiaries

M

5 Integration of COTS solution with POS and SHARE for reconciliation of fees and revenue between TRD, State Treasurer’s Office and DFA

M

6 Remove Driver financial transaction business rules from MVRO M

7 Development of a MVD Financial Transaction Engine Web Service that is compatible with POS

M

8 Development of a Table Driven Fee Schedule for each type of MVD Transaction that is compatible with POS

M

9 Development of Data Conversion strategy including data clean-up of legacy Driver and Financial information and successful conversion of targeted data into COTS solution

M

PAGE 8


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


1 System will integrate with TRD MVD computing infrastructure

2 Driver hardware/equipment will work with existing CI, POS and MVD Online

3 Driver hardware will work with or replace new POS COTS solution

4 Driver COTS software will integrate with SHARE

5 Adequate budget will be available

6 Adequate staffing levels with the proper skill sets necessary to ensure the system will perform as engineered

7 Staff is trained properly on the operation of the system to ensure continued success of the program

8 Vendor will continue to support software and release upgrades/patches on a regular basis

9 Business owners will embrace MVD Driver and Distribution system

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

[Risk 1: IT Resources]

Description –

TRD IT resource availability

Probability: Medium Impact: High

Mitigation Strategy: Ensure Senior Management Stakeholders are involved and support the project. Ensure project implementation is a priority among TRD team membersContingency Plan:

Have 2nd layer of individuals defined who may be able to cover task/ responsibilities

PAGE 9


[Risk 2: Integration]

Description –

Integration with MVD computing environment


Mitigation Strategy :Utilize Central Issuance (CI) and Point-of-Sale (POS) Integration Models Contingency Plan Utilize CI and POS project deliverables and documentation to identify MVD2.0 system integration requirements.

[Risk 3: COTS solution not available]

Description –

Driver COTS solution not available


Mitigation Strategy :Identify a COTS solution with similar architecture in place in MVD computing environmentContingency Plan Contact possible Driver vendors identified in IBM Needs Assessment Study; contact other states who have implemented COTS Driver solutions, and contact MVD solution providers with Driver solutions

[Risk 4: MVD hardware not supported by COTS solution]

Description –

MVD hardware not supported by COTS solution


Mitigation Strategy :Research COTS solution and identify compatibility w/MVD hardwareContingency Plan Leverage use of existing MVD equipment wherever possible and purchase additional hardware as required

[Risk 5: User acceptance of Driver and Financial COTS solution]

Description –

User acceptance of Driver and Financial COTS solution

Probability: High Impact: High

Mitigation Strategy :Establish Driver and Financial User Advisory Group responsible for assisting with Driver and Financial system configurationContingency Plan Place emphasis on the benefits of COTS solution, and provide opportunities for user involvement throughout the project

PAGE 10


[Risk 6: Key project member departs]

Description –

Key project member departs


Mitigation Strategy :Have two levels of coverage for each project staff member Contingency Plan Communication and awareness of each team member’s tasks and responsibilities

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURESTRUCTURE

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

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

NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Rick Homans Program Financial Responsibility Taxation and Revenue Department (TRD)

Cabinet Secretary

Marilyn Hill Program Financial Responsibility Taxation and Revenue Department (TRD)

Deputy Cabinet Secretary

Michael Sandoval Program Administration Responsibility

TRD, Motor Vehicle Division

MVD Director

Alicia Ortiz Program Administration Responsibility


MVD Deputy Director

Paul Montoya Program Administration Responsibility


MVD Deputy Director

Joel Matek IT Infrastructure Project Director

TRD, Information Technology Division

Chief Information Officer

PAGE 11


NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Lee Baca MVD Applications Development TRD, Information Technology Division

IT Manager

Mac Lewis MVD Policy and Procedure


Bureau Chief

Toby Williams MVD Field Office Operations TRD, Motor Vehicle Division

Bureau Chief

Josie Ortiz MVD Field Office Operations TRD, Motor Vehicle Division

Bureau Chief

To Be Determined MVD Training TRD, Motor Vehicle Division

Training Manager

TRD IT Technology and System Support

Technical Support of Systems Technology and System Support

Application Developer, Database Administration, System Administration

To Be Determined Project Manager Contractor Contract Employee

Subject Matter Experts (SMEs)

Business knowledge input TRD Motor Vehicle Division, Financial Distributions Bureau

TBD

PAGE 12


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

PAGE 13

Executive SponsorRick Homans

MVD Business OwnerMichael Sandoval

Financial Requirements Business Owner

Frank Shaffer

Executive Steering Committee

Rick HomansTRD Cabinet Secretary Marilyn HillTRD Deputy Secretary

Michael SandovalMVD Director

IT Technical Team Lead/ Project Director

Joel Matek

Drivers SMEs

IT Technical Team

Lee BacaMVD Applications Development Manager

Sailam Vasudevan IT Developer Venkat DoddaIT Developer

Tirumal RaoIT Developer

Diane MartinezIT Developer

Ragha MulakalIT Developer

Rao ChadDBA

Raul AlvarezMVD Special Projects

Toby WilliamsMVD Bureau Chief

Josie OrtizMVD Bureau Chief

Connie TorresMVD

Vicki EvansMVD

RevenueDistribution SMEs

Taca CampbellFDB

Carmelita GomezFDB

Katie PachecoFDB

Angel MartinezMVD Partner Services

MVD Driver ReengineeringProject Governance Structure

Joel MatekTRD CIO

Ramesh TavareIT Developer

Nanda KumarIT Generalist

Vehicles SMEs

Raul AlvarezMVD Special ProjectsLeonard GarciaMVD

Monica GallowayMVD

Commercial Vehicles/ IFTA/IRP SMEs

Alfred TrujilloMVD Bureau Chief

Norman PurdyMVD

Darren GomezMVD

Zarina MartinezFDB

Dealer, Auto Recycler, Title Service SMEs

Connie MartinezMVD

Walter MartinezMVD

Margaret WilliamsMVD

Donna IntermontMVD

Vendor IT Team

TBDVendor PM

TBDVendor IT Staff

TBDTechnical PM


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

RROLEOLE RRESPONSIBILITYESPONSIBILITY

Executive Project Sponsor

The point person for the project within the highest level of the Taxation and Revenue Department.

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

organizational impact Decide which changes will be instituted, communicate priorities

and provide resources to ensure success Responsible for creating an environment that enables changes to be

made on time and within budget Participate in planning sessions Member of Steering Committee Ultimate project responsibility

Steering Committee Member

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

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

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

Use this section to describe any special considerations regarding contact between the project team, the project manager, and individuals from various organizations involved in the project: boundary, interface and responsibilities at the interface.

2.3 EXECUTIVE REPORTING2.3 EXECUTIVE REPORTINGMeetings will be conducted with TRD Executive Steering Committee members, business owners, and IT technical teams on a regularly scheduled basis.

Whiteboard sessions outlining project task and resource assignment schedules and agendas are conducted throughout the process and transferred to the Microsoft project.

PAGE 14


Project status update reports will be verbally communicated to business owners conducted at weekly staff meetings by both divisions.

TRD management will be kept informed on the progress of the project periodically throughout the project life cycle.

Special oral and written Project Management and IV&V reports will be given on project progress at the MVD DRIVE Steering Committee meetings.

3.0 SCOPE3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1 PROJECT OBJECTIVES3.1.1 A3.1.1 AGENCYGENCY O OBJECTIVESBJECTIVES


Agency Objective 1 Replace a 30+ year-old mainframe system that is error-prone and becoming increasingly difficult to maintain and expensive to operate.

Agency Objective 2 Implement a new system that will help MVD better serve the public with a more secure, less error-prone, customer-centric application.

3.1.2 B3.1.2 BUSINESSUSINESS O OBJECTIVESBJECTIVES


Business Objective 1 Improve delivery of service to the citizens of New Mexico: A new COTS application would result in lower wait times at MVD field offices, a decrease in the number of errors, and an increase in the security of confidential data.

Business Objective 2 Reduce cost and complexity of Information Technology operations: A new COTS motor vehicle system will streamline and integrate processes that cross business units, multiple applications, and agency boundaries. Migrating current MVD Systems off of the mainframe would result in a $1.2 - $1.5 million cost savings for TRD/ITD.

3.1.3 T3.1.3 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


Technical Objective 1 Successfully implement a customer-centric Motor Vehicle System that is fully integrated with Point-of-Sale System.

Technical Objective 2 Successful migration of all MVD applications and systems off of mainframe and into a client-server environment.

Technical Objective 3 Improve security features and history of transactions/audit trail for all

PAGE 15



motor vehicle data and information.

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONSMainframe distribution system (MVRO) will not be completely replaced until the later Vehicle phase of this project is complete. At that time, all external interfaces and functions of MVRO will be incorporated into the COTS solution.

3.3 CRITICAL SUCCESS FACTORS3.3 CRITICAL SUCCESS FACTORSIdentify the critical success factors for achieving success in this project. Metric are key to understanding the ability of the project to meet the end goals of the Executive Sponsor and the Business Owner, as well as the ability of the project team to stay within schedule and budget. See also Section 6.7 Quality Objectives and Controls.

Metrics are estimated only, and will not be determined until after RFP award.

NUMBERNUMBER DESCRIPTIONDESCRIPTION

Quality Metrics 1 The project schedule, assigned tasks, resources and milestones are met.

Quality Metrics 2 TRD resources: TRD must provide adequate technical staffing, system resources, and user subject matter experts for a timely and successful implementation of Driver Reengineering.

Quality Metrics 3 Project does not exceed budget.

Quality Metrics 4 System is secure, operable and stable.

Quality Metrics 5 Staff is adequately trained.

Quality Metrics 6 Collecting fees and revenue distributions are accurate and produced in a timely manner.

Quality Metrics 7 Field offices operate more efficiently leading to improved customer satisfaction.

Quality Metrics 8 Driver legacy data is converted accurately and efficiently.

Quality Metrics 9 Driver and Distribution COTS solution integrates easily and accurately with POS or replaces POS functionality without losing existing POS capabilities and efficiencies.

Quality Metrics 10 Mainframe costs are reduced significantly once legacy Driver and Distribution modules are successfully implemented in Driver Reengineering COTS solution.

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

Initiating Main elements include: Authorize the project; Commit organization to project or phase; Set the overall direction; Define top-level project objectives; Secure necessary approvals and resources; Assign Project Manager; Integration Management.

Project Charter, Project Scope, Business Requirements, Assumptions, Constraints,

Planning Main elements include: Define Project scope; Refine Project objectives; Define all required deliverables; Create frame for project schedule; Provide forum for information sharing between project team members; Define all required activities; Identify required skills and resources; Estimate work effort; Risk analysis and avoidance; Define and estimate all required costs; Obtain project funding approval; Communication Plan.

Project Plan, Critical Success Factors, Work Break Down Structures, Project Schedule

Executing Main elements include: Coordinate the resources, team development; Quality Assurance; Select subcontractors; Distribute information; Work the plan.

Actual Efforts, Project Deliverables Completion

Controlling Main elements include: Manage team, stakeholders and subcontractors; Measure progress and monitor performance (overall, scope, schedule, costs and quality); Take corrective action if needed; Change request Management; Risk Management; Performance reports and communications.

Performance Status Reports, Corrective Actions, Measurement Metrics, Plan Change Request, Product Change Request, Risk Management, Issues Management

Closing Main elements include: Finalize activities; Administrative close out (gather, distribute, archive information to formalize project completion, acceptance/signoff, evaluation, member, appraisals, lessons learned); Contract close out (completion of the project contract including resolution of open items and final formal acceptance).

Deliverable Acceptance, Lessons Learned

4.1.1 P4.1.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project.

PAGE 17


4.1.1.1 Planning Documents

Description – The Project Management Plan represents the project team’s plans for the acquisition, installation, testing, and implementation of the COTS Driver solution. It is a working document. It will be modified and updated (under revision control) as the project team learns more about the project, brings on support vendors, and responds to changing or evolving conditions.

Deliverable Acceptance Criteria – MVD DRIVE Executive Steering Committee (ESC) approval and DoIT approval

Standards for Content and Format – The State PMO provides templates for content. The standard is based on the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK)

Quality Review – Review by MVD DRIVE ESC, the State PMO and PCC

4.1.1.2 Project Management & Control Functions

Description – Integrated Project Control Process, Change Control Process, Risk Management Plan, Internal Project Communication Plan, Quality Management Plan, Issue Management Process and the IV&V Plan. These are sections in the MVD Driver Reengineering Project Manual.

Deliverable Acceptance Criteria – MVD DRIVE ESC

Standards for Content and Format –The standard is based on the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK)

Quality Review – Review by MVD DRIVE ESC, the State PMO and PCC

4.1.1.3 Procure Driver Reengineering solution (RFP Process)

Description – Procuring the Driver Reengineering (the RFP process) is estimated to require two months at the least. After the RFP is written, State Purchasing, the General Council & DoIT must approve it. Then the following steps and timeframes are required:

RFP must be open for proposals – 30 days Review proposals & decide - - - - - 30 days Contract negotiations - - - - - - - - - 30 days Contract Approval - - - - - - - - - 30 days.

Deliverable Acceptance Criteria – MVD DRIVE ESC approval, signature approval by Purchasing, Legal and the State CIO approval

Standards for Content and Format – The contracts follow New Mexico standards for professional services contracts

Quality Review – MVD DRIVE ESC

4.1.1.4 Project Resource Management

Description – Recruit and hire project labor resources to include, a Project Manager, and IV&V services vendor. Specific deliverables include:

Deliverable Acceptance Criteria – MVD DRIVE ESC approval, signature approval by Purchasing, Legal and the State CIO

PAGE 18


o Project Manager Price Agreemento IV&V Price Agreemento IT Developer Price Agreement

Standards for Content and Format – The contracts follow New Mexico standards for professional services contracts

Quality Review – MVD DRIVE ESC

4.1.1.5 P4.1.1.5 PROJECTROJECT D DELIVERABLESELIVERABLES

Deliverables are estimated only, and will not be determined until after RFP award.

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE PPROJECTROJECT D DELIVERABLEELIVERABLE C CATEGORYATEGORY

PRJ-DEL-001 Project Management Plan (PMP)

Planning Document

PRJ-DEL-002 IV&V Contract & Reports Project Management & Control Functions

PRJ-DEL-003 IT Service Contracts Project Management & Control Functions

PRJ-DEL-004 Risk Assessment and Management Reports

Project Management & Control Functions

PRJ-DEL-005 Project Schedule Project Management & Control Functions

PRJ-DEL-006 Monthly Project Status Reports to DoIT


PRJ-DEL-007 Architecture Plan Planning Document

PRJ-DEL-008 Hardware Configuration and Equipment

Driver Reengineering Solution

PRJ-DEL-009 Software Licenses Driver Reengineering Solution

PRJ-DEL-010 User Acceptance Testing Project Management & Control Functions

PRJ-DEL-011 Training Plan Project Management & Control Functions

PRJ-DEL-012 Rollout Plan Project Management & Control Functions

PRJ-DEL-013 Implementation Services Driver Reengineering Solution

PRJ-DEL-014 Lessons Learned Project Management & Control Functions

PRJ-DEL-015 Close Out Reports and Documentation


PAGE 19


4.1.2 D4.1.2 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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



DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

PRJ-DEL-001 Project Management Plan (PMP)

Project Director on behalf of Executive Steering Committee

PRJ-DEL-002 IV&V Contract & Reports Project Director on behalf of Executive Steering Committee

PRJ-DEL-003 IT Service Contracts Project Director on behalf of Executive Steering Committee

PRJ-DEL-004 Risk Assessment and Management Reports


PRJ-DEL-005 Project Schedule Project Director on behalf of Executive Steering Committee

PRJ-DEL-006 Monthly Project Status Reports to DoIT


PRJ-DEL-007 Architecture Plan Project Director on behalf of Executive Steering Committee

PRJ-DEL-008 Hardware Configuration and Equipment


PRJ-DEL-009 Software Licenses Project Director on behalf of Executive Steering Committee

PRJ-DEL-010 User Acceptance Testing Project Director on behalf of Executive Steering Committee

PRJ-DEL-011 Training Plan Project Director on behalf of Executive Steering Committee

PRJ-DEL-012 Rollout Plan Project Director on behalf of Executive Steering Committee

PRJ-DEL-013 Implementation Services Project Director on behalf of Executive Steering Committee

PRJ-DEL-014 Lessons Learned Project Director on behalf of Executive Steering Committee

PAGE 20





PRJ-DEL-015 Close Out Reports and Documentation


4.1.3 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

The Project Director shall present the deliverables along with a recommendation for approval to the Executive Steering Committee during a regularly scheduled steering committee meeting. The Executive Steering Committee must then vote to accept or reject the deliverable with the vote reflecting a majority decision.

If the deliverable is rejected, the Project Director must inform the vendor submitting the deliverable of the committee’s action and must also identify, in writing, why the deliverable was rejected, and what actions must be addressed by the vendor before the deliverable is presented for acceptance again.

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

Phase Summary of Phase Key Deliverables

Initiating The requirements have been defined and documented. A Business Strategy Survey will be conducted to define goals, business processes, critical factors, current environment, sizing requirements, current vendor environment, # of users, work processing requirements, other needs.

REQUIREMENTS DOCUMENTS

Planning The Vendor will be required to deliver design documents for authentication, reporting, and the database feeds.

DESIGN DOCUMENTS

Executing The system will be open architecture and be certified on standard operating platforms – Windows or Unix. Architecture will be scalable to allow for growth, provide interoperability with other systems, have a secure web front end, be security rules based and provide multiple security layers for user authentication.

SYSTEMS ARCHITECTURE

Executing Users will test system functionality, performance, reporting accuracy and response times.

SYSTEM AND USER ACCEPTANCE TESTING

PAGE 21


IT Technical Support Staff will test system operational performance.

Executing The Vendor will be required to deliver design documents for authentication, reporting, and the database feeds.

OPERATIONS REQUIREMENTS

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

Developing a project strategy is a process of choosing an approach to the work that maximizes strengths, minimizes weaknesses, takes advantage of opportunities and mitigates threats while balancing the anticipated cost and potential benefit. A good strategy will minimize risk while maximizing return on investment.

The strategic direction is to select and implement a Driver Reengineering solution using a Commercial-Off-the-Shelf (COTS) software product that has demonstrated its effectiveness in the marketplace. Using a package strategy, rather than a custom development strategy, has been proven effective in many situations, and is a common strategy in both the private and public sectors.

A package strategy however, is not without its own risks. As a whole, the Information Technology (IT) industry has found the implementation of Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM) and other large-scale automation packages to be very difficult in many situations. Many of the high profile IT project disasters documented by the IT trade press over the years have involved the implementation of software packages. The question then is how to take advantage of a software package strategy while avoiding the potential pitfalls that have plagued so many other package implementations over the years?

The project strategy is based on the strategic direction established by the TRD MVD DRIVE Executive Steering Committee, and the lessons learned from others in the Information Technology industry that have implemented package software.

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

Deliverables are estimated only, and will not be determined until after RFP award.4.2.2.1 – Hire Project Manager

Description – Develop and execute contract for Project Manager

Deliverable Acceptance Criteria – Approval of contract and deliverables from management and DoIT

Standards for Content and Format – DoIT contract template

Quality Review – Review and acceptance from management and DoIT

4.2.2.2 Issue/Award RFP

PAGE 22


Description – Issue/Award RFP for Driver Reengineering COTS System and finalize vendor contract.

Deliverable Acceptance Criteria – Approval of RFP Committee recommendation by management, DoIT and State Purchasing

Standards for Content and Format - MS Word, MVD business requirements

Quality Review – ITD and MVD management review and Project Manager acceptance

4.2.2.3 Purchase Driver Reengineering Hardware

Description – Purchase hardware Deliverable Acceptance Criteria – Acceptance and delivery of hardware

Standards for Content and Format – Purchase Requisition

Quality Review – ITD and MVD management review and Project Manager acceptance

4.2.2.4 Implement Driver Reengineering in TRD

Description – Implement Driver Reengineering System in TRD

Deliverable Acceptance Criteria – Acceptance of system through User Acceptance Testing

Standards for Content and Format – MS Word, design specifications and PMP

Quality Review – ITD and MVD management review, Project Manager acceptance and IV&V

4.2.3 D4.2.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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





DEL-001 Project Management Plan Project Director on behalf of Executive Steering Committee

DEL-002 IV&V Contract & Reports Project Director on behalf of Executive Steering Committee

PAGE 23





DEL-003 IT Service Contracts Project Director on behalf of Executive Steering Committee

DEL-004 Risk Assessment and Management


DEL-005 Project Schedule Project Director on behalf of Executive Steering Committee

DEL-006 Monthly Project Status Reports to DoIT


DEL-007 Architecture Plan Project Director on behalf of Executive Steering Committee

DEL-008 Hardware Configuration and Equipment


DEL-009 Software Licenses Project Director on behalf of Executive Steering Committee

DEL-010 User Acceptance Testing Project Director on behalf of Executive Steering Committee

DEL-011 Training Plan Project Director on behalf of Executive Steering Committee

DEL-012 Rollout Plan Project Director on behalf of Executive Steering Committee

DEL-013 Implementation Services Project Director on behalf of Executive Steering Committee

DEL-014 Lessons Learned Project Director on behalf of Executive Steering Committee

DEL-015 Project Closeout Report Project Director on behalf of Executive Steering Committee

44.2.4 D.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

The Project Director shall present the deliverables along with a recommendation for approval to the Executive Steering Committee during a regularly scheduled steering committee meeting. The Executive Steering Committee must then vote to accept or reject the deliverable with the vote reflecting a majority decision.

PAGE 24


If the deliverable is rejected, the Project Director must inform the vendor submitting the deliverable of the committee’s action and must also identify, in writing, why the deliverable was rejected, and what actions must be addressed by the vendor before the deliverable is presented for acceptance again

5.0 PROJECT WORK5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)5.1 WORK BREAKDOWN STRUCTURE (WBS)A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Describe the work activities that comprise the work breakdown structure (WBS) or the work packages within the WBS. Identify the WBS element or other work package identifier and provide a general description of the tasks or activities, the definition or objectives, and the milestones and deliverables of each work package.

Work Breakdown Structure is estimated only, and will not be determined until after RFP award.

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

PAGE 25



PAGE 26


Identifier Work Package Description Definition/Objective Milestone/Deliverable

WBS-001 Requirements Define technical, business, and staffing requirements

Technical include: Hardware; Driver COTS software; POS integration or replacement; SHARE integration; licensing requirements; Network communications; security; VPN; and redundancy.

Business include: MVD business rules; and reporting requirements.

Staffing requirements include: ITD/MVD resource identification and vendor resource identification.

WBS-002 Acquisition Purchase hardware and software

Vendor selection and acquisition process.

WBS-003 Implementation Install hardware and software

Hardware installation including; rack installation if required, Software installation; Operating systems for servers; database installation; configure redundancy; and install applications.

WBS-004 Inventory Add MVD2.0, POS, CI and MVRO functionality to Driver software

Configure Driver software to incorporate MVD2.0, POS, CI and MVRO business requirements.

WBS-005 Application Deployment

Data cleansing and conversion mapping. Application code development for integration and configuration of Driver software

Conversion of legacy data. Develop coding for systems integration. Configure systems, initial testing by development staff and handover to operations staff.

WBS-006 Implementation/ Testing

Testing hardware and software configuration

Development of Test Plan, develop test scripts, conduct User Acceptance Testing, reconciliation of fees and revenue distribution, and validate reports.

WBS-007 Training Conduct training Develop documentation for users, and support personnel. Conduct training of MVD personnel.

PAGE 27


5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE

Project Timeline is estimated only, and will not be determined until after RFP award.

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

Budget is estimated only, and will not be determined until after RFP award.

Identifier Work Package or Budget Category Cost

WBS-001 – WBS007 Consulting Services $2,516,000.00

WBS-001 – WBS007 Hardware $150,000.00

WBS-001 – WBS007 Software $1,144,000.00

WBS-001 – WBS007 Implementation Costs (Per Diem, OT, Comp Time) $310,000.00

TOTALS $4,120,000.00

PAGE 28


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

PAGE 29

Executive SponsorRick Homans

MVD Business OwnerMichael Sandoval

Financial Requirements Business Owner

Frank Shaffer

Executive Steering Committee

Rick HomansTRD Cabinet Secretary Marilyn HillTRD Deputy Secretary

Michael SandovalMVD Director

IT Technical Team Lead/ Project Director

Joel Matek

Drivers SMEs

IT Technical Team

Lee BacaMVD Applications Development Manager

Sailam Vasudevan IT Developer Venkat DoddaIT Developer

Tirumal RaoIT Developer

Diane MartinezIT Developer

Ragha MulakalIT Developer

Rao ChadDBA

Raul AlvarezMVD Special Projects

Toby WilliamsMVD Bureau Chief

Josie OrtizMVD Bureau Chief

Connie TorresMVD

Vicki EvansMVD

RevenueDistribution SMEs

Taca CampbellFDB

Carmelita GomezFDB

Katie PachecoFDB

Angel MartinezMVD Partner Services

MVD Driver ReengineeringProject Governance Structure

Joel MatekTRD CIO

Ramesh TavareIT Developer

Nanda KumarIT Generalist

Vehicles SMEs

Raul AlvarezMVD Special ProjectsLeonard GarciaMVD

Monica GallowayMVD

Commercial Vehicles/ IFTA/IRP SMEs

Alfred TrujilloMVD Bureau Chief

Norman PurdyMVD

Darren GomezMVD

Zarina MartinezFDB

Dealer, Auto Recycler, Title Service SMEs

Connie MartinezMVD

Walter MartinezMVD

Margaret WilliamsMVD

Donna IntermontMVD

Vendor IT Team

TBDVendor PM

TBDVendor IT Staff

TBDTechnical PM


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

The State Department of Information Technology (DOIT) will provide project management oversight and the TRD DRIVE Executive Steering Committee will provide strategic direction for the project.

The TRD DRIVE Executive Steering Committee (ESC) provides strategic, high-level guidance with regard to procedures, progress, and risks. The Steering Committee is charged with taking a department view to ensure this project supports the delivery of an enterprise/department model. The project team reports status and progress to the Steering Committee on a regular basis. The TRD DRIVE ESC will also review, and approve deliverables, monitor the activities of the Project Team, assure adherence to the project plan and ensure involvement of participants in order to meet deadlines.

The TRD Driver Reengineering project team will handle the day-to-day tasks and decisions brought to the attention of the Steering Committee. The workgroup is comprised of staff members from the MVD Business Owners and the IT Technical Team. Tasks performed by these two teams include: project management and planning, analyzing requirements, data cleansing, data gap analysis and data mapping, making program specific decisions, helping determine the system and operational processes, business process reengineering, training and deployment.

The Department of Information Technology Office will provide increased emphasis on strategic information technology planning and management. This ensures the proper and efficient administration of all Information Technology Projects in the state.

Resources are to be contracted through the competitive vendor request (CVR) process to implement IV&V.

Given in the table below are the roles and responsibilities of each of the team members.

Role Responsibilities

NM DOIT Provide project implementation oversight Ensure proper project management and cost reporting Certify and approve funding prior to each phase of the project

PAGE 30



Executive Steering Committee (ESC)

Meet at least once monthly Provide strategic direction and promote the vision for Driver

Reengineering Advise project on policy issues Review, evaluate, and provide direction to the Project Director and Project

Team Members on implementation and deployment strategies Monitor the project progress Provide recommendations on issues escalated to the committee Assist in mitigating strategic project risks Direct the Project Director on issues and risks Address, review, and approve all deliverables, such as project structure

and team activities Monitor the project activities, assuring adherence to the project plan Ensure involvement of participants in order to meet deadlines Review and approve expenditures of funds Represent the point of view of key stakeholders including technology-

enabled customers and state government executives

Project Director/Project Manager

Report to ESC on project status, issues, budget, and activities Address, review, and submit deliverables to ESC from the TRD Project

Team members Prepare Driver Reengineering materials for MVD DRIVE ESC meetings Establish and maintain a coordinated project manual that includes all IT

and non-IT tasks and activities necessary to fully execute the project and to achieve project goals

Monitor and report the activities of the TRD Project Teams, assuring adherence to the project plan, budget and schedule

Ensure involvement of participants in order to meet deadlines Ensure mitigation of project issues and risks Maintain a current copy of the project budget Facilitate development of Driver Reengineering selection criteria Procure hardware and software for Driver Reengineering Comply with approved IT Infrastructure policies & procedures Plan system interfaces and document migration processes Manage testing and validating for Driver Reengineering solution Provide contract and Vendor oversight Assure Vendor deliverables meet the business & system requirements Monitor the project and contract to ensure delivery of complete, accepted

deliverables on schedule Serve as a contact for the Vendor Team Manager, review and accept

weekly status reports, project milestones, deliverables, and issues logs Advise the Vendor Team(s) on issues and risks Review and approve all Vendor documentation Document Driver Reengineering Model

PAGE 31



MVD and FDB Business Owners Team Members

Provide subject matter expertise for MVD and FDB business requirements Participate in workgroups and status meetings to determine best course of

action, options, and alternatives Review ITC PCC documentation for certification Participate in developing Driver Reengineering selection criteria Make recommendations to Driver Reengineering Project Director

concerning the project deliverables Assist with project coordination and issues where escalation is necessary Review Vendor deliverables and participate in test walk-through Approve and sign off on project documentation Work closely with Project Director to create an approved, published

Driver Reengineering framework

IT Team Members Participate in Hosting Strategy Development Support installation of hardware and technology infrastructure Develop applications as required Perform installation of hardware and software Configure hardware and software

IT Specialists System Administrators, System Experts and Developers

Provide IT subject matter expertise Work with Project Director to determine hardware, software, network and

technical requirements. Work with Project Director to define technical system interface

requirements. Provide IT perspective and guidance for technology issues

Vendor(s) Ensure compliance with the Contract and the approved work plan. Develop and submit all deliverables as required by the Contract. Meet the project schedule and milestones as defined in the Work Plan and

the Contract.

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

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL A AREAREA

Cabinet Secretary Program Financial Responsibility

Rick Homans Taxation and Revenue Department (TRD)

Deputy Cabinet Secretary

Program Financial Responsibility

Marilyn Hill Taxation and Revenue Department (TRD)

MVD Director Program Administration Responsibility

Michael Sandoval TRD, Motor Vehicle Division

MVD Deputy Director

Program Administration Responsibility

Alicia Ortiz TRD, Motor Vehicle Division

PAGE 32


RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL A AREAREA

MVD Deputy Director

Program Administration Responsibility

Paul Montoya TRD, Motor Vehicle Division

Chief Information Officer

IT Infrastructure Joel Matek TRD, Information Technology Division

IT Manager MVD Applications Development

Lee Baca TRD, Information Technology Division

Bureau Chief MVD Policy and Procedure

Mac Lewis TRD, Motor Vehicle Division

Bureau Chief MVD Field Office Operations

Toby Williams TRD, Motor Vehicle Division

Bureau Chief MVD Field Office Operations

Josie Ortiz TRD, Motor Vehicle Division

Training Manager MVD Training To Be Determined TRD, Motor Vehicle Division

Application Developer, Database Administration, System Administration

Technical Support of Systems

TRD IT Technology And System Support

Technology and System Support

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

Staff Planning and Resource Acquisition is estimated only, and will not be determined until after RFP award.

PAGE 33


5.5.1 P5.5.1 PROJECTROJECT S STAFFTAFF

Project staff requirements are estimated only, and will not be determined until after RFP award.

Resource Cost Estimate

Estimated Hours Availability Skill Set

Work Product/Deliverable

Project Manager $190,000 2000 Full-time Project Manager

All

IT Project Staff $500,000 2000 As Needed IT Expert All

MVD Business Owners $500,000 2000 As Needed MVD Experts

All

5.5.2 N5.5.2 NONON-P-PERSONNELERSONNEL RESOURCESRESOURCES

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

Hardware and Software Requirements are estimated only, and will not be determined until after RFP award.

Resource Cost Estimate

Estimated units/hours

Availability Source

Work Product/Deliverable

Driver Reengineering Hardware

$150,000 6 application servers6 database servers

TBD Hardware

Driver Reengineering Software

TBD 500 Clients TBD Software

PAGE 34


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

5.6.1 P5.6.1 PROJECTROJECT T TEAMEAM T TRAININGRAINING

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.

ResourceCost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

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

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

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 significantly impact a project’s success, and both should be handled in similar ways.

6.1.1 R6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

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

The best way to deal with a large amount of data/information is to categorize it in such a way to begin understanding the relationships between the data and start to see structure. The Software Engineering Institute (SEI) has developed a Taxonomy of Software Project Risk that offers a way to systematically

PAGE 35


think about the potential risks that are faced by software development/implementation projects. This taxonomy is used to stimulate thinking about the potential risks that the MVD Driver Reengineering project may face. To ease the documentation and tracking of identified risks, a risk evaluation tool is used, built with an excel spreadsheet that was originally provided by TRD. This is the primary tool to be used to list and categorize MVD Driver Reengineering project risks. The Risk Analysis is shown in Appendix D. The sequence of activity is as follows:

1. Risk Identification – The process of identifying potential risks and documenting the specific characteristics of each.

2. Risk Analysis – The process of determining the impact and likelihood of the identified risks. This process may employ both qualitative and quantitative techniques as deemed necessary to objectively evaluate potential risks to the project.

3. Risk Mitigation – The process of mitigating the possibility of the risk and assigning responsible individuals to identified risks. All identified risks will have appropriate mitigation strategies/plans. For those risks that are highly probable and have, significant impact to the project will develop contingency plans.

4. Risk Monitoring and Control – The process of tracking, evaluating and responding to ongoing developments relative to project plans, risk mitigation plans and specific contingency plans. Risk management is an integral component of integrated project control. This is an ongoing process for the duration of the project and will be part of every project status meeting.

Risk identification is the responsibility of all members of the project team. The Project Director and Project Manager are responsible for tracking risks and for developing mitigation strategies and contingency plans that address the risks identified by the team.

The MVD Driver Reengineering project will follow a continuous risk management strategy. Risk will be assessed routinely to ensure that identified risks are being dealt with appropriately and that new risks are identified and dealt with as early as possible

6.1.6 ISSUE MANAGEMENT6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution ProcessWith any project, no matter how comprehensive the planning process, issues arise that need to be addressed. This section of the project manual addresses how this process will be managed for the MVD Driver Reengineering project.

When the project team identifies an issue, it will be added to a document called MVD Driver Reengineering Issues Log.xls stored in the project library. An issue can also be identified by anyone affiliated with the project although the project team will be primarily responsible for tracking issues through to resolution. The project team will review the issues list twice a month. Issues, which could negatively affect the project, will be brought to MVD DRIVE ESC attention according to the change control process in Section 7.4. The process of tracking an issue is outlined here:

1) An issue is identified.2) It is added to the issue document, assigned an issue number with a brief explanation of the issue

and date entered.3) The issue is assigned to someone and potential action to be taken.4) As action is taken, it is noted with the issue.5) If possible, an estimated completion date is entered.

PAGE 36


6) Upon completion of an issue, the actual completion date is noted with the resolution.

Listed below are examples of how an issue can be resolved:

It could be resolved by an action taken. A document can be created which addresses the issue. A resolution could create new issues that need to be addressed. A new policy could be created which addresses the issue.

The project team is primarily responsible to resolve issues or follow-up to be sure action is being taken to resolve an issue.

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. MVD Driver Reengineering project will log internal and external issues as stated in Format 6.1.6.1 in order for all issues to be documented in a formal process. The mitigation process for resolving external issues will depend on contract terms and requirements agreed to by the agency and external vendors.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V

Independent verification and validation (IV&V) is a risk mitigation strategy designed to provide management with project oversight through an independent evaluation of a project’s product and process quality. The MVD Driver Reengineering Project has adopted a low risk implementation strategy by using a package solution that is currently implemented in multiple commercial and government sites. Given that the project has adopted a package solution strategy, its IV&V plan will be tailored to address the unique risks associated with package implementation projects.

The IV&V plan will: Evaluate and verify that processes, contracts, and system designs comply

with the specified requirements of the Enterprise Architecture and Standards

Evaluate and validate that products and deliverables of a given development phase fulfill the requirements and performance outcomes set forth in the scope and project plan

Provide a “close-out” report to the Executive Board at the end of project.

An IV&V vendor will be selected from the Statewide IV&V price agreement. The IV&V vendor will develop a complete IV&V plan in conjunction with the project team.

PAGE 37


6.3 SCOPE MANAGEMENT PLAN6.3 SCOPE MANAGEMENT PLAN

Project control is the mechanism by which the Project Director in conjunction with the project team assesses progress relative to the project plan. The project control process is implemented through a weekly project status meeting. The meeting will be designed to identify variances from the project plan and to identify and initiate corrective actions where appropriate.

Cost Control –The project director maintains a copy of the current budget and is to notify TRD of budget variances as they are identified.

Schedule Control – The project team is responsible for establishing and maintaining a project schedule. The project team will assess the current project schedule status and report variances as they are identified. Additionally, the team will identify and implement the appropriate corrective actions to eliminate or minimize schedule variances.

Scope Control – The project scope is defined and documented in Section 3 of this document. The detailed scope definition contained in Section 3 will be used to evaluate project scope issues. Significant variances from scope will be submitted to a formal project change control mechanism (Section 7.4 Change Control Process).

Quality Management – TRD MVD Driver Reengineering Project Quality Management will be established for each deliverable based on the quality mechanisms of the responsible organization, and the TRD MVD Driver Reengineering Quality Management Plan (Section 6.7) of this document.

Risk Management – Risk Management is an ongoing process of identification and assessment. Risk Assessment is included as part of the routine status process of the project. This maintains an awareness of risk and the associated risk assessment and monitoring tasks required to manage the project effectively.

These five (5) parameters of the project are integrally linked and any significant change in one will likely cause changes in the others. Project control establishes the mechanism to routinely track and report on these parameters. If issues arise that result in significant variances in these parameters, the project team will prepare and submit a Project Change Request form through the Project Change Control process.

The process below is designed to capture project status information on a weekly basis. The information is then used to trigger corrective action, risk mitigation and a variety of reporting processes. This process is critical to successful project communication and is the foundation on which a successful project control system will be built. The process should allow for flexibility in dealing with project control issues while ensuring that project status information is captured and documented.

6.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.

PAGE 38


6.3.1.2 Change Control Board (CCB)

A formal change control process is an essential component of a successful IT project. The key to controlling project change, is managing the impact to the project plan, budget, and implementation schedule.

Some changes are unavoidable – instances where changes have to be made to comply with legal, federal/state regulations, policy changes, compliance with changes in the business direction of the enterprise, or where technology may dictate change. Other non-essential changes can be avoided through management of a formal change control process.

Scope changes (sometimes referred to as scope creep) are the continual addition of functional enhancements to the product requirements throughout the project life cycle. Excessive scope changes are directly related to poorly defined product requirements and specifications. A well thought out change control process will assist the project management team in controlling “scope creep”.

Three (3) steps are necessary to control scope changes:

1. Establish the baseline product2. Obtain agreement from the project “approvers”3. Enforce a formal change control process

Establish the baseline product

The MVD Driver Reengineering project plan is developed around a “package” strategy. Further, the strategy specifically specifies minimal modifications to the package. No functional modifications are to be made to the selected MVD Driver Reengineering product. The package plus the Work Breakdown Structure and product descriptions in Section 5.1 of this document represents the baseline product and therefore the criteria for determining the approved scope.

Agreement from the MVD DRIVE ESC

The baseline product described above and strategy for implementation is to be reviewed and approved by the MVD DRIVE Executive Steering Committee. Requests to change the scope will also be reviewed and approved by the MVD DRIVE ESC.

Enforce a formal change control process

The software package/implementation process is never static. Some changes are to be expected during the MVD Driver Reengineering implementation, and a formal process has been defined and is to be followed to make sure all changes to the product are made in an orderly manner. As scope change requests are made, a change control process ensures

Only necessary changes are made, Changes are communicated to all affected parties, and Changes are implemented in an orderly fashion

PAGE 39


Integrated Control Process requirements are estimated only, and will not be determined until after RFP award.

PAGE 40


6.4 PROJECT BUDGET MANAGEMENT6.4 PROJECT BUDGET MANAGEMENTCost 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, should be consistent with the proposal, and include breakdowns as needed. Match these cost estimates with the actual billed amounts, and use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

6.4.1 B6.4.1 BUDGETUDGET T TRACKINGRACKING

The Motor Vehicle Division’s Budget Bureau will be responsible for managing the MVD Driver Reengineering budget, and will be a member of the MVD DRIVE Executive Steering Committee. The Budget Bureau employee will provide a budget update at each Steering Committee Meeting, identifying past expenditures, encumbrances, future encumbrances, personnel costs, and any other expense associated with the project budget.

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

Communication is fundamental to effective project management. The communications plan outlines the roles and responsibilities of participants in the dissemination, review and approval of project information. A communications plan that is well implemented will help manage expectations of the project, assure appropriate levels of communication with internal and external project stakeholders, provide relevant, accurate, consistent information at all times and help generate and sustain enthusiasm and support for the project.

The communication strategy covers all the informational needs of the project stakeholder community. Many will receive routine information about the project; others will be able to visit the project website and obtain the specific information that they are seeking and all may receive ad hoc communication from the project team at any time depending on the need.

The Executive Steering Committee will meet at a minimum on a monthly basis in order to review project progress, deliverables/milestones, provide direction to the Project Director, and team. The Project Director is required to provide formal status reports to the ESC and will present the report during the ESC meetings. The Project Director is also required to report on the overall status of the project on a monthly basis, per standard DoIT procedures.

PAGE 41


Specific requests for expenditure authorization should be forwarded to the ESC representatives for the agencies. If funding approval is an agenda item on the regular ESC meeting, the request and associated justification for spending should be circulated to committee members at least seven (7) days in advance of the ESC meeting. If funding approval is required in a timeframe that does not coincide with the ESC meeting schedule, it is the responsibility of the Project Director to send a request and justification directly to the ESC committee members. A reminder notice should be sent out after seven (7) days if there has been no response from ESC committee members. A final attempt to contact ESC members should be made at fourteen (14) days if there has been no response. Summary of any such action should be documented in team status reports and reported to the ESC at the next meeting.

6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

Stakeholders (PD = Project Director, PM = Project Manager)

Deliverable/Description Target Audience

Delivery Method

Frequency Responsible Party

MVD Driver Reengineering Project Status

TRD CIO Face-to-Face Weekly MVD Driver Reengineering PM


TRD Team Face-to-Face As Needed PD/PM


MVD DRIVE ESC

Email 2nd & 4th Mon PD/PM

MVD DRIVE ESC Meeting MVD DRIVE ESC

Face-to-Face 2nd & 4th Weds. PD/PM

MVD DRIVE ESC Meeting Minutes

MVD DRIVE ESC

Email 2nd & 4th Fri. PM

DOIT MVD Driver Reengineering Project Status

DOIT Email Monthly PM

Project Web Page As Needed Web Page As Needed PM Team

AD HOC As Needed As Needed As Needed As Needed

6.5.2 S6.5.2 STATUSTATUS M MEETINGSEETINGS

See above Matrix.

6.5.3 P6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

See above Matrix.

PAGE 42


6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)The Project Manager and Executive Sponsor define the project metrics that will be used to control the project. Each project will need to have an established metrics program. Metrics are collected for measuring the progress of a project against its planned budget, schedule, resource usage, 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 B6.6.1 BASELINESASELINES

Project Area Category Measure

Schedule Time Is project on schedule

Budget Costs Are project deliverables within budget

Quality Has testing results matched expectations

6.6.2 M6.6.2 METRICSETRICS L LIBRARYIBRARY

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

6.7.1 6.7.1 QUALITYQUALITY S STANDARDSTANDARDS

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

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

No. Quality Standard Tracking Tool or Measure

1The project schedule, assigned tasks, resources and milestones are met.

• Project Management Plan comparing estimated to actual

2TRD resources: TRD must provide adequate technical staffing and system resources for a timely and successful implementation of Driver Reengineering.

• Project Management Plan tracking tasks to resources

PAGE 43


3Project does not exceed budget.

• Project budget

4System is secure, operable and stable

• UAT results

5Staff is adequately trained

• User lessons learned

6Collecting fees and revenue distributions are accurate and produced in a timely manner

• Independent Audit by Tax Fraud Division

7Field offices operate more efficiently leading to improved customer satisfaction

• MVD Bureau chiefs comparing wait-times before MVD Driver Reengineering, and after MVD Driver Reengineering

8Driver legacy data is converted accurately and efficiently

• UAT results

9Driver and Distribution COTS solution integrates easily and accurately with POS or replaces POS functionality without losing existing POS capabilities and efficiencies

• UAT results

10Mainframe costs are reduced as legacy Driver and Distribution functionality is successfully implemented in MVD Driver Reengineering solution

• Project Director comparing mainframe costs before MVD Driver Reengineering, and after MVD Driver Reengineering

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

Review Type Quality Standard Tools Reviewer Reports

Requirements

Plans

Milestones

Testing

6.7.3 A6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMER S SATISFACTIONATISFACTION

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

Examples:

PAGE 44


Areas of feedback When How Often

Agency awareness Project Initiation Quarterly

Quality of communications Project Initiation Monthly

Manages project tasks Project Initiation Monthly

Productive Meetings Project Initiation Monthly

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

Hardware Project Director recommends approval to ESC

ESC grants final approval

Software Project Director recommends approval to ESC


UAT Project Director recommends approval to ESC


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

6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

TRD will implement a software solution to manage version controls for documentation and products. The software will secure or lock documents and products for access by a single individual. The proposed software will have the ability to also merge changes to a central repository.

PAGE 45


6.8.2 P6.8.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))A project repository consisting of a shared server with multiple folders and a project web site will be developed by TRD IT staff members as a means to provide a central repository for all project documentation and deliverables.

6.9 PROCUREMENT MANAGEMENT PLAN6.9 PROCUREMENT MANAGEMENT PLANAll procurement for project goods and services must be performed under the guidance and direction of New Mexico State Procurement Statutes which will be made available from the MVD Driver Reengineering project website.

.

7. 0 PROJECT CLOSE7. 0 PROJECT CLOSEProject 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 A7.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE

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 Management Consultant to tailor Project Close procedures to compliment the project’s objectives

7.2 C7.2 CONTRACTONTRACT C CLOSELOSE

Contract Close is similar to Administrative Close in that it involves product and process verification for Contract Close.

PAGE 46


APPENDIX A – WORK BREAKDOWN STRUCTUREAPPENDIX A – WORK BREAKDOWN STRUCTURE


PAGE 47


APPENDIX B - PROJECT SCHEDULE/GANTT CHARTAPPENDIX B - PROJECT SCHEDULE/GANTT CHART

Project Schedule is estimated only, and will not be determined until after RFP award.

PAGE 48


APPENDIX C - PROJECT BUDGETAPPENDIX C - PROJECT BUDGET

Project Budget is estimated only, and will not be determined until after RFP award.

PLANNING PHASE COSTContract Costs Project Management $190,000 IV&V $ 60,000 Business Analysis $ 50,000Total Contract Costs $300,000

PAGE 49


APPENDIX D - RISK ANALYSISAPPENDIX D - RISK ANALYSIS

Project Risk Analysis is estimated only, and will not be determined until after RFP award.

PAGE 50


APPENDIX E - PROJECT LIBRARYAPPENDIX E - PROJECT LIBRARYThe Project Library is an electronic storage place where all documentation relating to the project is stored and updated. TRD MVD Driver Reengineering Project Share Folder provides project specific information. This is a single source of project information for all stakeholders. The “Share Folder” includes the following information:

Project Management Plan Project Schedule Project Budget Governance, including project status reports and meeting minutes Project Background and Definitions MVD Driver Reengineering Requirements Matrix MVD Driver Reengineering Architecture Design

PAGE 51


APPENDIX F - SAMPLE PROJECT FORMSAPPENDIX F - SAMPLE PROJECT FORMSPPROJECTROJECT C CHANGEHANGE R REQUESTEQUEST F FORMORM

This is the form to initiate the Change Control process.

PAGE 52


PPROJECTROJECT S STATUSTATUS R REPORTEPORT

For the most up-to-date MVD Driver Reengineering Project Status Report, please email the TRD MVD Driver Reengineering Project Manager. Contact information will be updated once the PM is hired.

PAGE 53


SSAMPLEAMPLE ISSUESISSUES REPORTREPORT

For the most up-to-date MVD Driver Reengineering Issues Report, please email the TRD MVD Driver Reengineering Project Manager. Contact information will be updated once the PM is hired.

PAGE 54


APPENDIX G – TRD MVD DRIVER REENGINEERING PROJECT APPENDIX G – TRD MVD DRIVER REENGINEERING PROJECT DEFINITIONSDEFINITIONS

"Administrator" means the state records administrator (Section 14-3-2 NMSA 1978)."Agency" means any state agency, department, bureau, board, commission, institution or other

organization of the state government, the territorial government and the Spanish and Mexican governments in New Mexico (Section 14-3-2 NMSA 1978).

“Application” means a software program designed for end user to do work, such as word processing, accounting, or illustrating. Software programs such as WordPerfect, Excel, and PageMaker are examples of end user applications.

“Audit” means a periodic examination of an organization to determine whether appropriate procedures and practices are followed.

“C-1” means a project request for a base budget“C-2” is a single agency project request for funding“C-3” is a multi-agency project request for funding “Computer” This includes, but is not limited to, mainframe computers, minicomputers, and

microcomputers, personal computers, portable computers, pocket computers, tablet computers, telephones capable of storing information, PDAs, and other devices.

“Content” is a metadata concept that encompasses document images, papers, books, maps, email, web sites, HTML, XML, photographs, forms, audio, video, text, and reports.

“Data” is the plural for “datum” which means a single piece of information. Data refers to a collection of information, electronic or non-electronic. Data can also refer to raw facts, figures, or symbols.

“Database” means a collection of information stored in magnetic or hardcopy form (with or without any “Operating system,” means the master control software that runs a computer. When the computer is

turned on, the operating system is the first program that gets loaded into the memory of the machine.

“Program” means a coded set of instructions, written by humans, that directs a computer’s functions. The program can be stored on disk (in which case the program is software) or in a chip (which is firmware).

“Storage Area Network (SAN)” is a technology designed to overcome throughput and data-sharing issues that are common in existing data networks. SANs are fully scalable, fault-resilient shared data repositories providing unlimited mixing and matching of storage devices, storage space, and even files (under certain conditions) across the network. They are fast becoming the architecture of choice for centrally managed network storage tasks. SANs are high-speed, high-bandwidth I/O channels (usually Fibre Channel) that connect to the back end of local area network (LAN) servers. They remove cumbersome storage functions from the server, thus improving overall LAN and WAN performance. A typical SAN includes a blend of storage devices (such as automated tape libraries or RAID) capable of communicating with multiple hosts and with each other over a fast, fault-tolerant storage pipeline (the SAN). The SAN is actually a dedicated storage access I/O channel (containing network properties) optimized for handling storage tasks.

“Website” means a presence on the internet or intranet containing information that represents an agency or presents information on specific subjects or allows transactions to be conducted through the use of links or web pages. A website is normally hosted and maintained by an agency or by another entity sharing internet resource or through an internet service provider.

PAGE 55


APPENDIX H – TRD MVD DRIVER REENGINEERING PROJECT APPENDIX H – TRD MVD DRIVER REENGINEERING PROJECT ACRONYMSACRONYMS

APD – Advance Planning Document

CIO – Chief Information Officer

CRM – Customer relationship management

DAM – Digital Asset Management

DFA – Department of Finance and Administration

DoIT – Department of Information Technology

ERP – Enterprise Resource Planning

ESC – Executive Steering Committee

IT – Information Technology

ITC – IT Commission, a State CIO sponsored commission

PD – Project director

PMBOK – Project Management Book of Knowledge

PMI – Project Management Institute

PT – Project team

RFP – Request for proposal

TRD – Taxation and Revenue Department

WBS – Work breakdown structure

PAGE 56


APPENDIX P - PROJECT MANAGEMENT DEFINITIONSAPPENDIX P - PROJECT MANAGEMENT DEFINITIONSBelow is a list of project management terms. These definitions were supplied by the NM Department of Information Technology office.

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 or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEE-STD-610]

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.

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]

Commitment

A commitment is 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]

Configuration Management Library System

These are the tools and procedures needed to access the contents of the software baseline library.

Constraints

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

Contingency Planning

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

Crashing

Crashing is 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.

PAGE 57


Critical Path

Critical Path is a 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.

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

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.

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.

End User

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

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.

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.

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.

Integrated Project Plan

PAGE 58


A plan created by the project manager reflecting all approved projects and sub-projects.

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.

Method

Method is 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.

Milestone

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

Non-technical Requirements

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

Performance Reporting

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

Procurement Planning

Determining what to procure and when.

Product Scope

The features and functions that characterize a product or service.

Project Leader (Technical)

The leader of a technical team for a specific task, who has technical responsibility and provides technical direction to the staff working on the task.

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.

Program

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

Program Management Office

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.

PAGE 59


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.

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.

Project Management Plan

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.

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 id they comply with relevant standards and identifying ways to eliminate causes of product non-compliance.

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.

PAGE 60


Scope Change

Any change to the project scope. A scope change almost always requires an adjustment to the project cost or schedule.

Software Life Cycle

The period of time 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.

Stakeholder

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.

PAGE 61