Executive Sponsor – Demesia Padilla, CPA - CDLIS... · Web view2.0 Project Authority and...

New Mexico Taxation and Revenue DepartmentMotor Vehicle Division

CDLIS Modernization Project

Project Management Plan (PMP)

EXECUTIVE SPONSOR – DEMESIA PADILLA, CPABUSINESS OWNER – KEITH PERRY

TECHNICAL OWNER – GREG SAUNDERS

PROJECT MANAGER – LORETTA SILVA

ORIGINAL PLAN DATE: JUNE 1, 2011REVISION DATE: AUGUST 24, 2011

REVISION: 2.0

MVD CDLIS MODERNIZATION (C-MOD) PROJECTPROJECT MANAGEMENT PLAN VERSION: 2.0

Table of ContentsREVISION HISTORY............................................................................................................................................. III

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

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT 11.2 FUNDING AND SOURCES 21.3 CONSTRAINTS 31.4 DEPENDENCIES 31.5 ASSUMPTIONS 41.6 INITIAL PROJECT RISKS IDENTIFIED 5

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................7

2.1 STAKEHOLDERS 72.2.1 Describe the organizational structure – Org Chart.....................................................................................92.2.2 Describe the role and members of the project steering committee...........................................................92.2.3 Organizational Boundaries, interfaces and responsibilities.....................................................................10

2.3 EXECUTIVE REPORTING 11

3.0 SCOPE......................................................................................................................................................... 12

3.1 PROJECT OBJECTIVES 133.1.1 Business Objectives..................................................................................................................................133.1.2 Technical Objectives................................................................................................................................13

3.2 PROJECT EXCLUSIONS 143.3 CRITICAL SUCCESS FACTORS 15

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................15

4.1 METHODOLOGY 154.1.1 Lessons Learned.......................................................................................................................................154.1.2 Agile/Waterfall Hybrid Methodology......................................................................................................18

4.2 PROJECT MANAGEMENT LIFE CYCLE 184.1.1 Project Management Deliverables...........................................................................................................194.1.2 Deliverable Approval Authority Designations..........................................................................................204.1.3 Deliverable Acceptance Procedure...........................................................................................................21

4.2 PRODUCT LIFE CYCLE 234.2.1 Technical Strategy...................................................................................................................................244.2.2 Product and Product Development Deliverables......................................................................................254.2.3 Deliverable Approval Authority Designations..........................................................................................254.2.4 Deliverable Acceptance Procedure...........................................................................................................26

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

5.1 WORK BREAKDOWN STRUCTURE (WBS) 285.2 SCHEDULE ALLOCATION -PROJECT TIMELINE 305.3 PROJECT BUDGET 315.4 PROJECT TEAM 31

5.4.1 Project Team Organizational Structure....................................................................................................315.4.2 Project Team Roles and Responsibilities..................................................................................................32

5.5 STAFF PLANNING AND RESOURCE ACQUISITION 375.5.1 Project Staff.............................................................................................................................................37

I


5.5.2 Non-Personnel resources.........................................................................................................................375.6 PROJECT LOGISTICS 38

5.6.1 Project Team Training..............................................................................................................................38

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................39

6.1 RISK AND ISSUE MANAGEMENT 396.1.1 Risk Management Strategy......................................................................................................................396.1.2 Project Risk Identification........................................................................................................................396.1.3 Project Risk Mitigation Approach............................................................................................................396.1.4 Risk Reporting and Escalation Strategy...................................................................................................396.1.5 Project Risk Tracking Approach................................................................................................................406.1.6 ISSUE MANAGEMENT..............................................................................................................................40

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V 446.3 SCOPE MANAGEMENT PLAN 45

6.3.1 CHANGE CONTROL...................................................................................................................................476.4 PROJECT BUDGET MANAGEMENT 50

6.4.1 Budget Tracking.......................................................................................................................................516.5 COMMUNICATION PLAN 51

6.5.1 Communication Matrix............................................................................................................................526.5.2 Status Meetings.......................................................................................................................................546.5.3 Project Status Reports..............................................................................................................................54

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) 546.6.1 Baselines..................................................................................................................................................54

6.7 QUALITY OBJECTIVES AND CONTROL 556.7.1 quality Standards.....................................................................................................................................556.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................566.7.3 Customer Satisfaction..............................................................................................................................576.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................57

6.8 CONFIGURATION MANAGEMENT 586.8.1 Version Control........................................................................................................................................596.8.2 Project Repository (Project Library).........................................................................................................59

6.9 PROCUREMENT MANAGEMENT PLAN 60

7. 0 PROJECT CLOSE........................................................................................................................................... 60

7.1 Administrative Close...................................................................................................................................607.2 Contract Close.............................................................................................................................................60

8. 0 ATTACHMENTS........................................................................................................................................... 61

APPENDIX A – MVD C-MOD PROJECT DEFINITIONS............................................................................................61

APPENDIX B – MVD C-MOD PROJECT ACRONYMS..............................................................................................63

APPENDIX C –PROJECT MANAGEMENT DEFINITIONS.........................................................................................64

II


REVISION HISTORYREVISION HISTORY

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0 June 1, 2011 First Draft

2.0 August 24, 2011 Revisions for PCC certification

III


1.0 PROJECT OVERVIEW1.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 (NM TRD) is operating a series of hybrid mainframe/Web application systems that are outdated and difficult to maintain because 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.

The MVD Reengineering project (Milagro) was started in 2010, awarding the RFP to Hewlett Packard. The Milagro project purchased a framework (COMET) and services for both Driver and Vehicle functions. The source code was to become the property of the State of New Mexico upon project completion. The Milagro project was discontinued in May 2011 due to a contract breech. A replacement for the current MVD multi-platform system is still urgently needed.

The goal of a reengineered 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. A significant amount of Specifications Requirements and Business Rule documentation from the Milagro project can be reused and employed for Milagro’s successor.

1


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.A development environment has already been installed under the Milagro project. TRD prefers architecture very similar to that proposed for Milagro Test and Production for the new project. New servers for the production MVD Driver system will be located within the DoIT Data Center in TRD racks, and will be administered by TRD staff. Specific hardware requirements were included in the Systems Requirement Document submitted as part of our presentation to the Technical Architecture Review Committee (TARC). There should be no need for additional hardware in the field offices, as new computers and other hardware will be deployed as part of the MVD Point of Sale (POS) Project that will be completed prior to completion of the MVD Reengineering.

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 the POS application.

After terminating the HP/Saber contract in May 2011, TRD decided to proceed with a three-pronged interim solution for the reengineered MVD system:

1. Continue MVD Reengineering with an internal project, CDLIS Modernization (C-Mod), in order to comply with the CDLIS 5.2 mandates by January 30, 2012.

2. Identification and prioritization by MVD of issues requiring revision in the current MVD 2.0 system, followed by the repair of those outstanding issues by internal ITD staff.

3. Commence an MVD initiative to issue a second RFI and RFP for a reengineered, customer-centric, driver and vehicle system.

This document will focus on item one, CDLIS Modernization.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCES

The MVD C-Mod project is funded by the FY09 C2 Special Appropriation (Laws of 2008: Chapter 3, Section 7, Item 5).

2


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

NNUMBEUMBERR

DDESCRIPTIONESCRIPTION

1. CDLIS compliance functionality must be completed by January 30, 2012.

2. Ability to hire sufficient State employees to fulfill the project plan

3. Ability to hire sufficient experienced Contract employees to fulfill the project plan

4. Ability to use appropriate funding source as per the previous project for the in-house project.

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

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

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

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

NUMBENUMBERR

DESCRIPTIONDESCRIPTION TYPE TYPE M,D,EM,D,E

1. Agency and Contract team members will need to coordinate staff to best meet project timelines and deliverable approvals

M

2. Third Party Interfaces E3. AAMVA availability to facilitate casual testing, structured

testing, and certificationM

3


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

NNUMBERUMBER DDESCRIPTIONESCRIPTION1. The Agency plans to use existing workstations and printers, including both

general use printers and specialty printers.2. Contractors will be co-located with the Agency Team members.3. Use Case/User Interface deliverables will be the methodology used for

documenting requirements.4. A hybrid development approach will be used, such as Agile Modeling

methodology, to ensure that the maintenance team has sufficient documentation at the end of implementation, but that the project proceeds at a rapid pace.

5. The Agency will be providing a first level of Help Desk support, including receiving and logging incoming user calls and answering basic questions.

6. Modifications will work with pertinent interfaces (external and internal).7. Adequate budget will be available.

4


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

ID Risk Description

Probability Impact

Rating Mitigation Plan

Contingency Plan

1 Funding not authorized.

Requires reallocation of MVD Reengineering funds to C-Mod project.

Unlikely

Very High

.1425

Certification request will be presented at August PCC meeting.

Remove contract resources and extend timeline for a 100% in-house effort.

2 Inadequate levels of internal and Contract staffing (technical).

We continue to experience additional demands placed on ITD staff. Project delays resulted from the additional demands.

Likely High .4125

Create a detailed Resource Staffing Plan and gain approval of this plan early in the project from ITD to furnish resources.

Include contingency funds in the project plan that will allow ITD to backfill positions with temporary or contract personnel.

3 Inadequate levels of internal and Contract staffing (business).

We continue to experience additional demands placed on MVD staff. Project delays resulted from the additional demands.

Likely High .4125

Create a detailed Resource Staffing Plan and gain approval of this plan early in the project from MVD to furnish resources.

Include contingency funds in the project plan that will allow MVD to backfill positions with temporary or contract personnel.

4 AAMVA not available

Dependent upon AAMVA

Unlikely

Very High

.1425

Contact AAMVA to inform them of C-Mod project and

Adjust schedule to match

5


ID Risk Description

Probability Impact

Rating Mitigation Plan

Contingency Plan

for certification.

availability for casual testing, structured testing in order to obtain certification.

timelines. AAMVA availability.

5 Demanding project schedule.

After HP contract was canceled, only eight months remain to complete C-Mod changes by federal deadline.

Likely High .4125

Manage resources closely (people, tasks and timelines). Keep executive management posted on progress.

Seek additional resources to increase project staff to meet deadlines.

6 PM experience and credentials

PM with sufficient credentials and experience cannot be found at an acceptable rate.

Unlikely

Very High

.1425

Existing contract ITPM has been identified. Establish contract once C-Mod is certified.

Assign internal PM to C-Mod project and adjust workload accordingly.

LEGEND - Rating

Color

Minimum risk - Acceptable

Some risk - Monitor at PM/Team Level

High risk - Active monitoring with ongoing Contingency/Mitigation activity

Show stopper - Active participation with steering committee to mitigate

6


2.0 PROJECT AUTHORITY AND ORGANIZATIONAL 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURESTRUCTUREThe 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

Demesia PadillaProject Sponsor/Program Financial Responsibility

Taxation and Revenue Department (TRD)

Cabinet Secretary

Keith PerryProgram Administration Responsibility

TRD, Motor Vehicle Division

MVD Director

Greg SaundersIT Infrastructure Project Director Post-implementation Maintenance and Support

TRD, Information Technology Division

Chief Information Officer

Alicia Ortiz Program Administration Responsibility


MVD Deputy Director

Paul Montoya Program Administration Responsibility


MVD Deputy Director

Lee Baca MVD Development Bureau TRD, Information Technology Division IT Manager

Vickie Evans Project Manager, Lead SME – MVD


Bureau Chief

Loretta Silva Project Manager – ITD CSW Enterprises, LLC Contract PM

Sailam Vasudevan

Technical and Business Knowledge


IT BusinessAnalyst

Doug Torhan AAMVA Technical Knowledge DoIT, Information Systems Division

Contract Developer

7


NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Donna Intermont Business Knowledge Input – CDLIS


Subject Matter Expert

Darren Cordova Business Knowledge Input - CDLIS



Nichole Armijo Business Knowledge Input – Medical Certificate



Raul Alvarez Business Knowledge Input TRD, Motor Vehicle Division


Connie Torres Business Knowledge Input TRD, Motor Vehicle Division


Mac Lewis Policies and Procedures TRD, Motor Vehicle Division

Bureau Chief

Julia Belles Legal Interpretation TRD, Legal Services Bureau

Staff Attorney

TRD IT Technology and System Support

Technical Support of Systems TRD, Information Technology Division

MVD Dev, Database Admin, Infrastructure Support, Operations

To Be Determined MVD Training TRD, Motor Vehicle

DivisionTraining Manager

8


2.2 Project Governance Structure

2.2.1 D2.2.1 DESCRIBEESCRIBE THETHE ORGANIZATIONALORGANIZATIONAL STRUCTURESTRUCTURE – O – ORGRG C CHARTHART

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

Role Responsibility

Executive Level The point person for the project is the Cabinet Secretary 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 Ultimate project responsibility

9


Role 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

Project Managers (ITD, MVD)

Responsible for oversight and management of project teams.

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

areas

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

Executive Governance is reserved for significant items beyond 2nd Level ability to resolve. Examples that may be escalated to this level could include:

• Monthly Status

• Program level issues that could not be resolved by the Program Level Governance

• Compliance/barrier that will jeopardize project ability to meet objectives and/or deliverables

• Inability to resolve contract or inter-Division issues

• Regional and Local Laws interpretations/issues/changes

• Legal issues

Program Governance is the first line of consideration for issues such as scope changes, quality, risks management and schedule, or those issues that cannot be resolved at the Project Management level or effect the overall budget.

10


Project Governance

• Provides a shared understanding and agreement among all participants as to what will be delivered, how it will be completed, and the commitment required.

Is differentiated from oversight alone in that it involves interactive participation with the project in assisting the project achieve its stated objectives.

Provides a clear and functional hierarchy for escalation to those empowered to intervene / help resolve items that cannot be resolved at the project level.

Includes client participation at project as key stakeholders for informational and resolution purposes.

Monitors progress of the integrated Project Schedule.

Provides leadership intervention as required to the execution of project plan, and appropriate escalation to higher levels of management.

Assists in removing barriers that inhibit execution of the project plan.

Maintains and manages the action items.

Reviews and approves scope change requests, within an agreed upon impact limit.

2.3 EXECUTIVE REPORTING2.3 EXECUTIVE REPORTINGThe MVD and ITD project managers will compile biweekly and monthly C-Mod status reports for review by Project Executives and the Project Steering Committee. These reports will include a general status update of the C-Mod project, milestones (achieved, in progress), major risks, change requests, and any other items needing executive review. Also included will be Earned Value calculations, if a cost-effective method can be implemented to obtain these figures.

C-Mod project status will be reviewed with project executives and stakeholders at bi-weekly DRIVE MVD and monthly TRD MVD Reengineering Steering Committee meetings.

C-Mod project status reports will be verbally communicated to Project Managers at weekly C-Mod Project Team Leads meetings.

11


3.0 SCOPE3.0 SCOPE The primary goal of the C-Mod project is to become fully-compliant with AAMVA CDLIS Modernization 5.2 standards by January 30, 2012. Completing the C-Mod project serves two purposes: (a) ensures compliance with federal mandates, and (b) C-Mod changes for Drivers will be used for the next iteration of MVD Reengineering, making it easier to ensure compliance and simplify the conversion from legacy applications to the new system.

The individual components that comprise the C-Mod project include:

1. Name Expansion – Expand client name to meet federal guidelines

a. First Name = 40 characters

b. Middle Name = 35 characters

c. Last Name = 40 characters

d. Suffix = 5 characters

2. Ten-Year History Check/Driver License Number Survey – when applying for an initial issuance, renewal or transfer of a CDL, a driver must provide a list of all the States where the driver was licensed to operate any type of motor vehicle during the past ten years. Before issuing, renewing or transferring a CDL, a State must request the driving record from each State listed by the driver.

The Driver License Number (DLN) Survey is used to obtain a DLN and status information from a previous jurisdiction when a 10-Year History Check is needed and the DLN is not known. Once a DLN is obtained, the history check is performed.

3. Patriot Act - requires any commercial driver who has or will seek a hazardous material endorsement (HME) to their Commercial Driver's License (CDL) to undergo a background check. C-Mod changes require MVD to capture and store the Transportation Security Administration (TSA) Result Date, TSA Result (Approval, Denial, and Denial with immediate revocation), and expiration date as part of the CDL license.

4. Medical Certificate – requires the electronic capture of medical certificate information and storage of same for all Commercial Driver License holders who are required to provide a medical certificate. After fifteen days of CDL issuance or renewal, drivers will no longer be required to carry the physical medical certificate with them while they are driving. NOTE: Until electronic Medical Certificate availability is coordinated with law enforcement agencies, drivers may have to continue carrying the physical medical certificate. The medical certificate information is stored in the state database and must update the driver record on AAMVA’s CDLIS central site within ten days of CDL issuance or renewal. If a driver fails to renew their medical certificate, the CDL will be downgraded to the base license and the CDLIS driver record must be updated within ten days.

12


5. Admin Per Se – requires MVD to notify other states when CDL drivers are served with certain ACD actions (A61, A94, and A98):

a. A61 – Underage Convicted of Drinking and Driving at .02 or higher BAC

b. A94 – Administrative Per Se for .04 BAC

c. A98 – Administrative Per Se for .08 BAC

d. A report is sent to other states only after final adjudication is made.

6. Passenger 16+ – Commercial vehicles designed to transport sixteen or more passengers (including the driver) are impacted by Motor Carrier Safety Information Act (MCSIA) disqualification rules. When a CDL driver has an out of service order in effect and is found driving a commercial vehicle with sixteen or more passengers, the driver can be disqualified. Disqualification revokes commercial driving privileges, and the driver’s license is downgraded to a base license. In order to comply with this mandate, the legacy driver applications must store a data element for Passenger 16+. The changes will impact database table definitions and program logic.

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

NNUMBERUMBER DDESCRIPTIONESCRIPTION

Business Objective 1Procure a more modular solution with current technologies that can be managed, updated, and replaced without requiring wholesale replacement.

Business Objective 2 Manage the risks of implementing and operating the new motor vehicle environment while improving system and data integrity.

Business Objective 3 Provide higher levels of MVD service with the ability to meet new, evolving requirements and operational needs.

Business Objective 4 Develop and manage a program that enables disaster recovery operations and improves on return-to-service time lines.

3.1.2 T3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


Technical Objective 1 Provide open-systems-based architecture that is more reliable, flexible, and maintainable.

Technical Objective 2 Adhere to national standards for data exchange, security, and interfaces.

Technical Objective 3Improve the quality and accessibility of information for users with toolset standards, such as Structured Query Language (SQL) and Open Database Connectivity (ODBC), and do so without the involvement of operators or specialists.

13



Technical Objective 4 Retain the necessary level of system security to protect users and information from unauthorized access.

Technical Objective 5 Provide client agencies with increased MVD access and functions.

Technical Objective 6 Use best in class components and commercial off-the-shelf (COTS) solutions to improve system supportability and cost.

Technical Objective 7Provide enhanced audit trail and functional capability to view complete history of transactional changes over time, including who, what, and when.

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONSNumber Description

Exclusion 1 The Project does not include the implementation of a document management system.

Exclusion 2The Project does not include the implementation of an Interactive Voice Recognition (IVR) application. The implementation of the IVR MVD functionality will be complete in FY12 under a separate project.

Exclusion 3The Project does not include the implementation of a Business Intelligence application that would allow Business Users to create their own ad hoc reports.

14


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

NUMBERNUMBER DESCRIPTIONDESCRIPTIONQuality Metrics 1 Baselined Project Schedule subjected to continuous monitoring and

weekly status reporting.Quality Metrics 2 The project schedule, assigned tasks, resources and milestones are met.Quality Metrics 3 Project does not exceed budgetQuality Metrics 4 TRD Resources – TRD must provide adequate technical staffing,

system resources, and user subject matter experts for a timely and successful implementation of C-Mod implementation.

Quality Metrics 5 Project Focus by all team members.Quality Metrics 6 The State and any Contractors meet their mutual obligations as defined

by the contract.Quality Metrics 7 Early and active involvement of all stakeholders (including 3rd party

interfaces).Quality Metrics 8 Evaluating processes outside of how they are performed now,

improvements identified and implemented.Quality Metrics 9 Successful process and application training. Staff is adequately

trained.

4.0 PROJECT DELIVERABLES AND METHODOLOGY4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 METHODOLOGY4.1 METHODOLOGY4.1.1 L4.1.1 LESSONSESSONS L LEARNEDEARNED

From lessons learned on the previous iteration of the Milagro project, there are some modifications to be made to the Software Development Methodology and the Project Management of the project. The Lessons Learned identified a minimum of the following challenges in the implementation of the previous project.

4.1.1.1 Challenges with Previous Methodology1. User Interface and Use case documents did not agree.

15


2. Use Case and User Interface documents did not adequately describe Basic, Alternative, and Exception flows.

3. Use cases and User Interfaces sometimes included a different set of functions (i.e, Manage Operator’s License might be in the UI, but not mentioned as any separate function in the Use Case of the same number).

4. Agile methodologies allow the overlapping of requirements, design, coding, and testing for a specified set of functionality (i.e., Learner’s Permit). In practice this has not worked well for TRD. Changes had to be made to code already dropped and tested due to changes in the requirements or design documents. The latter documents were not approved in some cases until after the code drop functional testing was completed. This out-of-sequence delivery also made it difficult to identify what was to be tested.

5. The schedule for the previous iteration of the Milagro project allowed most of the interfaces for Driver to be developed as part of the last Sprint. Testing became much more complicated and required multiple testing of the same functionality. One example is that only 9 of 41 scenarios for New Operator license could be completed with the code drop, because interfaces required to complete the other 32 Test Scenarios were not provided at the time of the code drop.

6. On the Vendor side, Configuration Management of the code seemed to be problematic.

7. Recommended performance improvements to the database design were rejected. Performance problems were reported by all vendor implementation sites surveyed.

8. Design documents were not provided to the level necessary for State staff assuming maintenance and support post-implementation.

9. Submission of many Requirements Specification documents were allowed to exceed the maximum of two (2) proposed by the contract.

10. Complaints were made by other states regarding the code quality and adherence to agreed upon coding and documentation standards.

4.1.1.2 Proposed Methodology Changes1. If Use Case (UC) and User Interface (UI) documents are to be used to describe

the functionality to the Users. UC and UI documents should be presented and reviewed at the same time in order to determine their agreement and comprehensive coverage.

2. Use Case and User Interface documents should clearly delineate Basic Flow as well as all Alternative Flows and Exception flows.

16


3. Use Case and User Interface documents should clearly delineate multiple functions: Issue Operator License, Renew Operator License, Manage Operator License, etc.

4. A hybrid methodology will be adhered to that requires a waterfall methodology within a specified set of functions (all Operator License functions), and an agile method between system functions (all the Driver Specifications will not need to be completed before any Driver function Design document is created).

5. Interfaces needed for testing a function (e.g., the photo capture or Matricula verification for Operator’s License) will be completed with the associated Operator’s License functionality. This practice will significantly reduce testing time.

6. Going forward the team would like to use a dedicated Configuration Manager, and a more robust Configuration Management tool like ClearCase or AccuRev.

7. Start with a 3NF customer centric database, where possible based on database models provided by AAMVA.

8. Include in the design documents a minimum of the following:

a. Software Technical Design Overview(tiers)

b. Controller model used, if applicable (MVC)

c. High Level Design Architecture (role and responsibility of each design component)

d. Physical Data Model

e. Class Diagram

f. Sequence Diagrams

g. Object Library: searchable library of the objects and their basic function

h. Logic diagrams/detailed design for objects including deployment structures

i. Products and Tools required for future maintenance

9. Immediate identification and notification if any agreed upon limit/schedule has been exceeded. Clear and rapid escalation of any item exceeding schedule or review limits.

10. External, independent review of code and adherence to coding standards.

17


4.1.2 A4.1.2 AGILEGILE/W/WATERFALLATERFALL H HYBRIDYBRID M METHODOLOGYETHODOLOGY

Figure 1 Agile - Waterfall Hybrid Methodology

Two sets of code could be developed separately using the waterfall techniques within each sub-release. The decision whether the code for 2.1 and 2.2 would be tested together or separately would depend on the timing of the completion of the two sets of code, any interdependencies, and the availability of multiple test regions to not confound the test results.

4.2 PROJECT MANAGEMENT LIFE CYCLE4.2 PROJECT MANAGEMENT LIFE CYCLEOverall the project would conform to the standards specified by DoIT for project certification. The Project Management Life Cycle consists of the following project management phases and responsibilities:

Initiating— Identify the high-level business objectives, assumptions and constraints, and secure commitment to proceed with a project to satisfy the stated requirements. Initiating

18


should occur not only at the beginning of each new project—it also should occur at the beginning of each significant phase in an existing project to make sure the project objectives and costs/benefits are reasonable.

Planning—Plan the project in detail, as part of project start-up, prior to each new stage and as part of the change-management process.

Executing— Coordinate the resources (people and other) required to deliver the project. From the project viewpoint, this is where the project work is actually accomplished.

Controlling–Make sure the project objectives are met. The project management team is responsible for reviewing project progress to verify that the project remains on time, on budget and meets project requirements. Corrective actions are taken as required to make sure the project returns to a managed state.

Closing—Make sure the project or phase is properly closed down, either when project delivery is complete or when the project is terminated for whatever reason.

Phase Summary of Phase Key Deliverables

InitiatingScope engagement with client and formulate strategic relationship.

Project Charter, Assumptions, Constraints, Contract

PlanningDefining project parameters and building shared vision for solution delivery.

Project Plan, Work Breakdown Structure, Project Schedule

Executing

Delivering the solution in two parts (phases): 1) Drivers Licensing and 2) Vehicle Licensing and associated deliverables.

Complete work and deliverables (Enhancements, System Testing, Training, Acceptance Testing, Implementation)

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

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

ClosingConclusion and closure of project activities following deployment of solution.

Product Acceptance, Transition to Operations and Support

4.1.1 P4.1.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

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

4.1.1.1 Project Management PlanDescription - Defines how the project is executed, monitored and controlled.

Deliverable Acceptance Criteria – Document meets NM DoIT standards.

19


Standards for Content and Format –

Defined by NM DoITQuality Review – Refer to Section 6.7 of this document.

4.1.1.2 Project ScheduleDescription - A list of a project’s tasks with intended start and finish dates.

Deliverable Acceptance Criteria – Deliverable identifies all project related tasks, tasks have predecessors and successors as applicable and associated resources for tasksStandards for Content and Format – Project schedules will have a Work Breakdown Structure that is deliverable based versus Systems Development Life Cycle (SDLC) methodology/process based. Deliverables will be given clear, meaningful names. This standard applies to deliverables at any WBS level.Quality Review – Refer to Section 6.7

4.1.1.3 Risk Management PlanDescription - Description - A deliverable defining the risk management methodology and approach for handling risks for this project.

Deliverable Acceptance Criteria – Deliverable defines risks Standards for Content and Format – Defined by NM DoITQuality Review – Refer to Section 6.7

4.1.2 D4.1.2 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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 NNUMBERUMBER

DDELIVERABLEELIVERABLEAAPPROVERSPPROVERS (W(WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

1Project Management Plan (PMP)Project ScheduleRisk Management Plan

MVD Director/ TRD CIO

2 IV&V Plan and ReportsMVD Director/ TRD CIO

3 Requirements SpecificationsMVD Director/ TRD CIO

20



DDELIVERABLEELIVERABLEAAPPROVERSPPROVERS (W(WHOHO CANCAN APPROVEAPPROVE))


4 Design, Coding and Unit TestingMVD Director/ TRD CIO

5 User Acceptance TestingMVD Director/ TRD CIO

6 AAMVA Casual/Structured Testing and Certification


7 User TrainingMVD Director/ TRD CIO

8 ImplementationMVD Director/ TRD CIO

4.1.3 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

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

Acceptance. In accord with Section 13-1-158 NMSA 1978, the Executive Level Representative shall determine if the Deliverable provided meets specifications. No payment shall be made for any Deliverable until the individual Deliverable that is the subject of the Payment Invoice has been Accepted, in writing, by the Executive Level Representative. In order to Accept the Deliverable, the Executive Level Representative, in conjunction with the Project Manager, will assess the Quality Assurance level of the Deliverable and determine, at a minimum, that the Deliverable:

1.) Complies with the Deliverable requirements as defined in CDLIS State Procedures Manual (Release 5.2.0);

2.) Meets the performance measures for the Deliverable(s) and this Agreement;

3.) Complies with all the requirements of this Agreement.

21


If the Deliverable is deemed Acceptable under Quality Assurance by the Executive Level Representative or designee, the Executive Level Representative will notify the Contractor of Acceptance, in writing, within fifteen (15) business days from the date the Executive Level Representative receives the Deliverable(s) and accompanying Payment Invoice.

Rejection. Unless the Executive Level Representative gives notice of rejection within the fifteen (15) business day Acceptance period, the Deliverable will be deemed to have been accepted. If the Deliverable is deemed unacceptable under Quality Assurance, fifteen (15) days from the date the Executive Level Representative receives the Deliverable(s) and accompanying Payment Invoice, the Executive Level Representative will send a consolidated set of comments indicating issues, unacceptable items, and/or requested revisions accompanying the rejection. Upon rejection and receipt of comments, the Contractor will have ten (10) business days to resubmit the Deliverable to the Executive Level Representative with all appropriate corrections or modifications made and/or addressed. The Executive Level Representative will again determine whether the Deliverable(s) is Acceptable under Quality Assurance and provide a written determination within fifteen (15) business days of receipt of the revised or amended Deliverable. If the Deliverable is once again deemed unacceptable under Quality Assurance and thus rejected, the Contractor will be required to provide a remediation plan that shall include a timeline for corrective action acceptable to the Executive Level Representative. The Contractor shall also be subject to all damages and remedies attributable to the late delivery of the Deliverable under the terms of this Agreement and available at law or equity. In the event that a Deliverable must be resubmitted more than twice for Acceptance, the Contractor shall be deemed as in breach of this Agreement. The Procuring Agency may seek any and all damages and remedies available under the terms of this Agreement and available at law or equity. Additionally, the Procuring Agency may terminate this Agreement.

22


4.2 PRODUCT LIFE CYCLE4.2 PRODUCT LIFE CYCLE II

The necessity to meet new CDLIS 5.2 requirements by January 30, 2012, requires a change in implementation priority. Consequently, the following is proposed for three (3) Major project Phases.

Phase Summary of Phase Key Deliverables

Phase 1 Various activities related to CDLIS 5.2 compliance, outlined later in this section.

Continuously identify, prioritize, and implement changes to the existing multi-platform system.

Publish and process an RFI for system replacement.

MVD CDLIS 5.2 Compliance.

Ready existing system to provide the required functionality in the interim and meet any compliance requirements subsequent to CDLIS 5.2.

Restart the MVD Reengineering procurement process.

Phase 2 Publish and process an RFP for a fully integrated Driver and Vehicle System

Contract with Third Party or develop in-house by which TRD will own either (1) a “real” COTS system, (2) code for a MOTS system with contract terms, conditions and deliverables appropriate for the system type, or (3) a custom built system that meets RFP mandatory deliverables and requirements.

Phase 3 Delivery of Integrated System Fully integrated system installed and used by TRD

Phase 1 Functionality

Foundation functionality necessary for this C-Mod compliance must be completed by January 30, 2012. The following changes are necessary in order to comply with the CDLIS 5.2 mandates:

Mainframe

23


DB2 and program changes for Name Expansion, Ten-Year History Check/Driver License Survey, Patriot Act, Medical Certificate, Admin Per Se, and Passenger 16+

Convert and test associated interfaces

UNI Server table and program changes for Name Expansion, Ten-Year History Check/Driver License Survey, Patriot Act, Medical Certificate, Admin Per Se, and Passenger 16+

Test associated UNI Server messages, transmission and responses

MVD 2.0

SQL Server and program changes for Name Expansion, Ten-Year History Check/Driver License Survey, Patriot Act, Medical Certificate, Admin Per Se, and Passenger 16

Convert and test associated interfaces

AAMVA Certification

Coordinate, participate and complete casual testing of C-Mod changes

Coordinate, participate and complete structured testing of C-Mod changes

Obtain AAMVA certification for Name Expansion, Ten-Year History Check/Driver License Survey, Patriot Act, Medical Certificate, Admin Per Se, and Passenger 16+

Additional tasks related to C-Mod

Legacy data cleanup activities continue with MVD and ITD developers

Upgrade SQL Server 2000 to SQL Server 2005 and test with MVD2.0

Repurpose DB01 DB2 test environment for CDLIS testing

Create a new, separate SQL test environment for CDLIS testing

Implement the CDLIS Help Desk

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

C-Mod changes are being made to legacy applications. Therefore TRD, DoIT and contract developers will modify the legacy MVD2.0 and mainframe applications as well as associated interfaces. After user acceptance testing is successfully completed, TRD personnel will work closely with AAMVA to complete casual and structured testing for all C-Mod components in order to obtain certification.

24


TRD’s existing infrastructure will continue to support the MVD systems. Both the mainframe and servers for the C-Mod project are located within the DoIT Data center in TRD racks, and are administered by TRD staff.

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.

Mainframe processing is expected to be consistent with the current MVD load since all MVD transactions are already using the mainframe legacy applications.

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

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

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.


DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))


4.2.2.1 Project Management MVD Director/ TRD CIO

4.2.2.2 IV&V MVD Director/ TRD CIO

4.2.2.3 Requirements Specification MVD Director/ TRD CIO

4.2.2.4 Design, Coding and Testing MVD Director/ TRD CIO

4.2.2.5 User Acceptance Testing MVD Director/ TRD CIO

4.2.2.6 AAMVA Casual and Structured Testing


4.2.2.7 User Training MVD Director/ TRD CIO

4.2.2.8 Implementation MVD Director/ TRD CIO

25


4.2.4 D4.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Describe the process that this project will use for the formal acceptance of all deliverables.

Submission. Upon completion of agreed upon Deliverables, project management team (consisting of ITD MVD Development Manager, MVD Business Manager, and ITD Project Manager) will review submitted deliverable for accuracy, completeness and adherence to requirements.

For deliverables submitted by contractors, as set forth in respective contracts and/or service level agreements, the Contractor shall submit a Payment Invoice with the Deliverable, or description of the Deliverable, to the Project Manager. Each Payment Invoice shall be for the fixed Deliverable price as set forth in the contract and/or service level agreement, less retainage, if applicable.

Acceptance. In accord with Section 13-1-158 NMSA 1978, the Executive Level Representative shall determine if the Deliverable provided meets specifications. No payment shall be made for any Deliverable until the individual Deliverable that is the subject of the Payment Invoice has been Accepted, in writing, by the Executive Level Representative. In order to Accept the Deliverable, the Executive Level Representative, in conjunction with the Project Manager, will assess the Quality Assurance level of the Deliverable and determine, at a minimum, that the Deliverable:

1.) Complies with the Deliverable requirements;

2.) Meets the performance measures for the Deliverable(s) and this Agreement;

3.) Complies with all the requirements of this Agreement.

If the Deliverable is deemed Acceptable under Quality Assurance by the Executive Level Representative or designee, the Executive Level Representative will notify the Contractor of Acceptance, in writing, within fifteen (15) business days from the date the Executive Level Representative receives the Deliverable(s) and accompanying Payment Invoice.

Rejection. Unless the Executive Level Representative gives notice of rejection within the fifteen (15) business day Acceptance period, the Deliverable will be deemed to have been accepted. If the Deliverable is deemed unacceptable under Quality Assurance, fifteen (15) days from the date the Executive Level Representative receives the Deliverable(s) and accompanying Payment Invoice, the Executive Level Representative will send a consolidated set of comments indicating issues, unacceptable items, and/or requested revisions accompanying the rejection. Upon rejection and receipt of comments, the Contractor will have ten (10) business days to resubmit

26


the Deliverable to the Executive Level Representative with all appropriate corrections or modifications made and/or addressed. The Executive Level Representative will again determine whether the Deliverable(s) is Acceptable under Quality Assurance and provide a written determination within fifteen (15) business days of receipt of the revised or amended Deliverable. If the Deliverable is once again deemed unacceptable under Quality Assurance and thus rejected, the Contractor will be required to provide a remediation plan that shall include a timeline for corrective action acceptable to the Executive Level Representative. The Contractor shall also be subject to all damages and remedies attributable to the late delivery of the Deliverable under the terms of this Agreement and available at law or equity. In the event that a Deliverable must be resubmitted more than twice for Acceptance, the Contractor shall be deemed as in breach of this Agreement. The Procuring Agency may seek any and all damages and remedies available under the terms of this Agreement and available at law or equity. Additionally, the Procuring Agency may terminate this Agreement.

27


5.0 PROJECT WORK5.0 PROJECT WORK

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

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

28


Identifier Work Package Description Definition/Objective Milestone/Deliverable

4.2.2.1Project Management

Provide day-to-day management of C-Mod project.

Creation/maintenance of Project Management Deliverables and status reports.

Project Management PlanScheduleBudgetRisk Management PlanProject Status ReportsDoIT Reports

4.2.2.2.IV&V

Perform Independent Verification & Validation services.

Creation of IV&V Plan and reports.

IV&V PlanRisk Assessment PlanInitial ReportMonthly Reports

4.2.2.3Requirements Specifications

Document business requirements to implement C-Mod changes.

Creation/maintenance of Use Case and User Interface documents for six C-Mod components.

Use Case and User Interface documents for:

1. Name Expansion2. Ten-Year History

Check/Driver License Number Survey

3. Patriot Act4. Medical Certificate5. Admin Per Se6. Passenger 16+

4.2.2.4Design, Coding and Unit Testing

Design, code and test solution to implement C-Mod changes.

Complete program analysis, design, coding and testing of C-Mod changes.

Database changes and code changes for:

1. Name Expansion2. Ten-Year History



4.2.2.5User Acceptance Testing

Perform UAT for C-Mod changes

Run test scripts, document results, and accept test results for C-Mod changes, ensuring accuracy and completeness.

Test scripts and results for:1. Name Expansion2. Ten-Year History



4.2.2.6AAMVA Casual and Structured Testing

Perform Casual and Structured Testing to obtain AAMVA certification of C-Mod changes.

Work closely with AAMVA to test all aspects of each C-Mod component, ensuring accuracy and completeness.

AAMVA certification for:1. Name Expansion2. Ten-Year History


3. Patriot Act4. Medical Certificate

29


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

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

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

30


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

Identifier Work Package or Budget Category Cost

4.2.2.1 Project Management $157,9324.2.2.2 IV&V $72,5204.2.2.3 Requirements Specifications $96,0044.2.2.4 Design, Coding and Unit Testing $890,0604.2.2.5 User Acceptance Testing $101,8074.2.2.6 AAMVA Casual and Structured Testing $54,6874.2.2.7 User Training $88,4094.2.2.8 Implementation $12,009

TOTALS $1,473,430

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

The C-Mod project team is comprised of MVD business subject matter experts, ITD technical experts, and contract personnel (PM, IV&V, and developers). The core members of the project team are co-located in the ITD area of the Joseph Montoya building. Co-location facilitates ongoing day-to-day interaction and collaboration. The Technical Project Manager is the lead project manager.

31


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 DRIVE MVD Executive Steering Committee will provide strategic direction for the project.

The DRIVE MVD 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 DRIVE MVD 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.

Resources were contracted utilizing the State Price Agreement 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

32



Executive Steering Committee (ESC)

Meet at least once monthly Provide strategic direction and promote the vision for C-Mod Advise project on policy issues Review, evaluate, and provide direction to the Project

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

33



Technical 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 C-Mod 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 C-Mod selection criteria Procure hardware and software for C-Mod, as needed Comply with approved IT Infrastructure policies &

procedures Plan system interfaces and document migration processes Manage testing and validating for C-Mod solution Provide contract and Vendor oversight Assure Vendor deliverables meet the business & system

requirements Monitor the project and contracts to ensure delivery of

complete, accepted deliverables on schedule Advise the Contractor(s) on issues and risks Review and approve all Contractor documentation

MVD Business Team Members

Provide subject matter expertise for MVD 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 C-Mod selection criteria Make recommendations to C-Mod Project Manager

concerning the project deliverables Assist with project coordination and issues where escalation is

necessary Review Contractor deliverables and participate in test walk-

through Approve and sign off on project documentation

34



IT Team Members and contract developers

Participate in project meetings and activities Design and implement database changes as required Design and develop application changes as required Participate in UAT Participate in User Training Participate in Implementation Provide IT subject matter expertise Work with Project Manager to determine technical

requirements Work with Project Manager to define technical system

interface requirements Provide IT perspective and guidance for technology issues

The table below summarizes the roles and responsibilities of each of the team members.

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL AAREAREA

Cabinet Secretary Program Financial Responsibility

Demesia Padilla Taxation and Revenue Department (TRD)

Deputy Cabinet Secretary

Program Financial Responsibility

John Monforte Taxation and Revenue Department (TRD)

MVD Director Program Administration Responsibility

Keith Perry TRD, Motor Vehicle Division

MVD Deputy Director

Program Administration Responsibility

Alicia Ortiz TRD, Motor Vehicle Division

MVD Deputy Director

Program Administration Responsibility

Paul Montoya TRD, Motor Vehicle Division

Chief Information Officer

IT Infrastructure Greg Saunders TRD, Information Technology Division

35


RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL AAREAREA

IT Manager MVD Applications Development

Lee Baca TRD, Information Technology Division

Technical Project Manager

Lead Project Manager Loretta Silva Contract Project Management

Business Project Manager/Lead SME

MVD Project Manager Vickie Evans TRD, Motor Vehicle Division

Driver SME MVD Requirements Specifications

Connie Torres TRD, Motor Vehicle Division

Bureau Chief MVD Policy and Procedure

Mac Lewis TRD, Motor Vehicle Division

CDL SME MVD Commercial Driver License Bureau

Darren Cordova TRD, Motor Vehicle Division

Medical Certificate SME

MVD Commercial Driver License Bureau

Nichole Armijo TRD, Motor Vehicle Division

Business Knowledge Input

MVD Special Projects Manager Raul Alvarez, Jr. TRD, Motor

Vehicle DivisionLegal Interpretation

TRD Legal Services Bureau Julia Belles TRD, Office of

the SecretaryTRD IT Technology and System Support

Technology Support of Systems

Jacque GeoffrionChris HollisLarry Vigil


User Training MVD Training TBD TRD, Motor Vehicle Division

36


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

5.5.1 P5.5.1 PROJECTROJECT S STAFFTAFF

Resource Cost Estimate

Estimated Hours Availability Work Product/Deliverable

TRD Project Manager $157,932 1,640 Full Time

Project Management documents and status reports

TRD, IT Project Staff $364,650 6,630 Part Time

Requirements SpecificationsDesign, Coding and Unit TestingUser Acceptance TestingAAMVA Casual and Structured TestingUser TrainingImplementation

MVD Business Owners $54,600 1,560 Part Time

Requirements SpecificationsUser Acceptance TestingAAMVA Casual and Structured TestingUser TrainingImplementation

Contract Developers $658,007 10,640 Full Time

Requirements SpecificationsDesign, Coding and Unit TestingUser Acceptance TestingAAMVA Casual and Structured TestingUser TrainingImplementation

IV&V $72,520 N/A Part Time

IV&V Plan and Reports

5.5.2 N5.5.2 NONON-P-PERSONNELERSONNEL RESOURCESRESOURCES

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

Resource Cost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

N/A N/A N/A N/A N/A N/A

37


5.6 PROJECT LOGISTICS5.6 PROJECT LOGISTICS

The primary C-Mod team members will be co-located onsite working closely on a daily basis to facilitate day to day interaction and active participation in the onsite JAD Sessions, Interface meetings, Conversion meetings and other project related meetings. Other experts will participate as needed.

User Training will be conducted at a central site by the MVD Trainer with assistance from the C-Mod business and technical team. The project will utilize a train-the-trainer approach. MVD Field Office managers will receive C-Mod training, and in turn, will train employees at their respective locations during rollout weekend.

5.6.1 P5.6.1 PROJECTROJECT T TEAMEAM T TRAININGRAINING

Training for the Project Team will be provided by the IT Business Analyst, ITD developers and MVD Trainer. Training will be delivered by three methods:

On-the-job Training (OJT)

Mentoring (One-on-One)

Classroom (Instructor-Led Training)

Training will continue throughout the entire project lifecycle. Below is a list of the type of training that will be offered during the different phases.

Requirements, Design Phase

o CDLIS 5.2 Mandates

o Functional Knowledge

Application Development

o Development Methodology

o Standards

o Database Design

o Program Changes

o Interfaces

Application Support

o Operations

o Application Maintenance

38


6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1 RISK AND ISSUE MANAGEMENT6.1.1 R6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

Risk Management is the process and activities for managing assumptions, risks and issues. Risk management is a joint responsibility of all project members and leaders. The project’s risk management approach facilitates a shared understanding and involvement about the approach to risk management, which is that high-impact or critical risks are identified early and managed proactively including perceptions of risks, environmental factors such as stakeholders, funding, and time lines. Additionally, the project establishes a basis for risk escalation to promote appropriate and timely risk visibility. This proven approach to risk management minimizes potential project impact to quality, cost, and schedule because of risks, thereby facilitating improved project success. A detailed Risk Management Plan is available as a separate project deliverable; please refer to the MVD C-Mod Risk Management Plan for additional details.

6.1.2 P6.1.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

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

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

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

6.1.3 P6.1.3 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

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

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

Risks will be escalated for visibility or information if:

The risk has impact outside of the MVD C-Mod project. One of the Project Managers assesses that leadership needs awareness of the risk.

Risks will be escalated for leadership action or resolution if

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

example, risk event is to occur within 30 days, the plan must be in place within 7

39


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

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

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

6.1.5 P6.1.5 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

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

• The status of risks and mitigating actions taken will be reviewed at a minimum monthly.• High Priority Risks and their associated Contingency Plans will be reviewed weekly

during the Project Status Meetings.• Risks will be reported and tracked in the Project Repository.• Contractor Project Status Reports will contain at a minimum the top three Risks and

associated data. Additionally, all risks will be provided for review weekly.• Feedback on active risk activities, current risks, and emerging risks will be provided to

the project team and to stakeholders. • Risks that cannot be managed at the project level will be escalated to leadership for

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

during the project change control process.

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

Contingency Plans will be reviewed according to the documented frequency within the Risk Handling Plans to determine if the risk symptoms or contingency triggers and actions are current. If the risk symptoms or contingency triggers for these plans have been exceeded, the appropriate actions are taken and the status of these plans is monitored as specified above.

6.1.6 ISSUE MANAGEMENT6.1.6 ISSUE MANAGEMENT

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

40


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

Issue Resolution Process

Issue resolution will occur at various levels within the project structure. This issue resolution process allows problems to be resolved as close to the point of origin as possible. This approach makes certain that the team with the knowledge and the skills required for resolving the issues is assigned ownership of the issue. These team members will exhaust the resolution options before the issue is escalated.

41


Issue identification and resolution from within the project teams can be initiated from all areas of the project organization. Each team can raise issues relevant to their specific deliverables or to the entire project.

The first step of the issue resolution process is to identify whether the proposed issue is, in fact, an issue and if it is, whether it has been previously documented. After it is determined that the issue should be logged, it is recorded using the appropriate tool (the tools are discussed in the following section). An issue tracking spreadsheet will record the title and the description of the issue, along with other relevant information as detailed in the following table. The issue will be managed through its life cycle and stored for historical viewing.

Issue Resolution Tracking Document DescriptionIssue Process Steps DescriptionIssue Register Project issues will be identified and recorded into the Issue

Log by the Project Managers. The Project Managers will coordinate the review and the resolution of each issue.As issues are identified, the project team will review each issue. Next, the issue is captured and tracked using the Issue Log. The process will remain flexible enough to accommodate the needs and the dynamic nature of the project. If an issue is not addressed quickly or not satisfactorily resolved, it will be escalated to the next level of authority. The Issue Log will include the following information: ID (Issue Number) Status (Open, Escalated, Cancelled, Completed) Category (impact area of issue, e.g. Scope) Assigned To Title (brief unique identifier) Originator (group or individual) Level (High, Medium, Low) Open Date Target Date Description Status Comment

An issue can be placed on the Issue Log at any time by e-mailing the appropriate information to the Project Managers. If an issue is of sufficient concern, it can be discussed directly with the Project Managers at any time. Issues may also be of such significance that they may be recorded on the Risk Log (refer to the Risk Management Plan).

42


Issue Process Steps DescriptionIssue Identification Issue originators must record the issue using the appropriate

tracking tool. If they do not have access, they may ask a project team member to record it for them. The issue originator will record the title, the description, and the other information as mentioned above. The user reporting the issue also will have to assign an owner to the issue. If the owner of the issue is unknown, the issue owner will default to the project member reporting the issue.Any member of the project team who identifies an issue may submit it.

Issue Assignment Issues are recorded into the Issue Register and assigned an issue owner by the Project Managers. New and open issues discussed during the weekly project status meetings will be recorded in the log and assigned to a project member, along with a due date to resolve the issue. If there is a question of issue ownership, the issue should be discussed with the Project Managers. At any point, an issue can be reassigned as necessary. Project staff assigned to an issue may discuss the ownership with the Team Lead for reassignment. On approval, the issue owner may reassign the issue. If ownership is still debated, the issue should be openly discussed at the weekly project status meetings where ownership will either remain with the issue owner or be reassigned.

Issue Investigation The owner of the issue is responsible for investigating the issue. Issues originating from within specific functional project teams will be identified and reported to that team’s lead. The Team Lead may also assign an issue owner based on the type and the priority of the issue.

Issue Escalation Issues originating from within specific functional project teams will follow communication between the issue originator and the appropriate Team Lead. The issue owner will be responsible for the documentation of any information relevant to the resolution of the issue and follow up with the issue originator and other interested parties. Escalation ProcessIf an issue cannot be resolved by the owner, it may be escalated. When escalating an issue, the issue impact should be described. This escalation approach allows issues to be resolved whenever possible at the lowest possible level within the project structure, enabling the Project Management Team and the Agency to remain focused on the management and the long-term vision of the project. Escalation PathIf issues go unresolved at a particular level, they will be processed to the next level of the management structure. As the issue is elevated to higher levels of management, the issue priority, the due date, and the assigned owner are constantly reevaluated. ResponsibilityIssue Owner——If the issue owner is unable to resolve the

43


Issue Process Steps Descriptionissue or requires additional resources or information, the issue owner will escalate the issue to the appropriate Team Leader. Team Leader——If the Team Leader is unable to resolve the issue or requires additional resources or information, the Team Leader will escalate the issue to the Project Managers.

Issue Resolution Issue resolution techniques and alternative analysis also play key roles in keeping projects on track. Team Leaders and Project Managers will manage project issues on a proactive basis. These levels of management will use their experience and resources to assist in impact analysis, evaluation of alternatives, and formulation of an appropriate course of action. During an investigation, issues may be identified as duplicates. If an issue is identified as a duplicate, the resolution should document the duplicate issue number.

Issue Reporting The Project Managers will list open and resolved issues in their weekly status reports. Open issues will be discussed at the weekly issue and risk oriented meetings and weekly project status meetings. These weekly issue and risk oriented meetings serve as a forum where Team Leaders and Project Managers can give status, raise and discuss issues, and determine appropriate resolution actions.

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 Agency that is responsible for managing the project without affecting the overall project schedule, cost, or quality. Escalation will occur through the escalation path defined in the Project Governance structure.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&VIndependent 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 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.

44


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

An IV&V vendor has been selected from the Statewide IV&V price agreement. The contract is being finalized and the vendor will be brought back to the project as soon as the contract is approved by the Department of Finance and Administration.

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

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

The scope management process includes:

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

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

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

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

45


The figure below illustrates the approach to scope management.

Scope Management

The Project Team will establish a consensus about scope among key stakeholders and institute a collective scope management process, which comprises the following:

Identification, control, management, and tracing of baseline scope clarification throughout the project life cycle

Formalization of the cost/benefit analysis of each requested clarification

Production and iterative update of the Business Requirements

Scope Management Plan of the Project Management Plan to track, manage, and document project scope clarification

Scope PlanningThe Statement of Work (SOW) is determined by the CDLIS Modernization 5.2 documentation and identifies the goals and objectives for the project. The SOW authorizes the project managers to define the Project’s processes and provide guidance for the Project’s scope.

Scope DefinitionTRD has defined the deliverables required to complete the project. Many deliverables and their component requirements are defined at a sufficient level of detail to provide direction and definition.

46


Scope VerificationAs part of the ongoing efforts, the project team will document scope clarifications, schedule, work products, and technical environment, and determine cost feasibility using approved scope control and integrated control processes.

The management of project change is essential to controlling project scope. The Change Control Process and Configuration Management Plan define the high-level steps, tools, and resources needed to execute an effective change management process. The Change Control Process and Configuration Management approach describe roles and responsibilities associated with receiving, tracking, communicating, estimating, and approving changes. Changes remain active within change management until approval or rejection of a change is received.

6.3.1 6.3.1 CHANGE CONTROLCHANGE CONTROL

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

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

Change request form

Change request tracking tools

Change control approval process

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

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

Who is requesting the change?

What is the start date for the change?

What is the justification (reason and necessity)?

What is the level of urgency for the required change?

What elements of the system/project will be altered because of this change?

What is the effect of the change on the project/program?

What is the staffing plan associated with the change?

What is the effect on the schedule for implementing the change?

What is the cost effect to the project budget?

What is the risk assessment and recommended approach to complete this change?

47


Is it approved, denied, or deferred?

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

Change Management Process

Initiate - After the need for a change has been identified, the originator must complete a Change Request (CR) form. The project team will finalize the form at the beginning of the project. The originator must describe the current issue, and document specific details as necessary. The originator may optionally assign an initial priority to the request to communicate the urgency of the request. After an issue has been raised, it should be forwarded to the Technical Project Manager.

Any member of the project team who perceives a need to change a process or product may submit a change request, including the following:

Project Management Steering Committee member User Group member Team member

Initial Review - The next step is to determine whether the change warrants investigation and whether, in fact, it is in the scope of the project. If the initial review deems that the change is not in the scope and is not needed, the CR will be closed with details on potential for a future release. If the change is deemed as required by the project—whether it is in scope or out of scope—the effect of making the change will need to be evaluated.

Assign and Prioritize - If the CR is deemed to need evaluation, the project manager will assign it to a team member for evaluation. The team member performs the impact

48


analysis. The project manager, with assistance from the project team, will determine whether the request is an actual change by comparing it with the relevant original requirement.

Impact Analysis and Proposed Work Plan - Impact Analysis assesses the effect the change will have on the project. The analysis will detail the effect and cost of making the change. Examples include the following:

Effect on the system (that is, programs, database, files, and so on) Resource allocation effect (cost) Phase/project delivery time frame effect (schedule) Effect on other areas of the project Specific tasks/deliverables requiring rework and time estimates for each

Final Review - After the effect of the change has been analyzed, the CR and the impact analysis are referred to the Project Change Control Board (CCB) for final disposition of the request. The Change Request may be placed into one of the following states:

Approved and implemented into the project Approved but deferred (or not implemented) in the current project Rejected Canceled

If the change is rejected or canceled, the CR will be closed. If the change is approved, it will need to be signed off before any further action may be taken.

Implemented - If the CR is approved, the change will be assigned a target release number and date. If the change is to be implemented as part of the existing project, deliverables affected by this change must be updated accordingly. The project plan must be updated (if affected) to include the change itself (including effort required to analyze the change) and any rework of other products/deliverables. Any reworked deliverables will be reissued, and interested parties will be informed that the change has been incorporated. The team member assigned to the CR will make the change. The project manager will update the project work plan and any other relevant documentation.

Rejected - The CR may be rejected at any point in the process. Rejected CRs will be reviewed in the Project Status and CCB meetings. Any team member may request or recommend rejection of a change request.

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

49


Participant Position

Greg Saunders TRD CIO

Keith Perry MVD Director

Loretta Silva IT Project Manager

Vickie Evans MVD Project Manager

Lee Baca ITD MVD Development Manager

Sailam Vasudevan IT Business Analyst

6.4 PROJECT BUDGET MANAGEMENT6.4 PROJECT BUDGET MANAGEMENTThe MVD C-Mod project is funded by the FY09 C2 Special Appropriation (Laws of 2008: Chapter 3, Section 7, Item 5). The project budget is tied to project deliverables, presented in chronological order of delivery:

DDELIVERABLEELIVERABLE N NUMBERUMBER DDELIVERABLEELIVERABLE

4.2.2.1 Project Management

4.2.2.2 IV&V

4.2.2.3 Requirements Specifications

4.2.2.4 Design, Coding and Unit Testing

4.2.2.5 User Acceptance Testing

4.2.2.6 AAMVA Casual and Structured Testing

4.2.2.7 User Training

4.2.2.8 Implementation

50


6.4.1 B6.4.1 BUDGETUDGET T TRACKINGRACKING

The Technical Project Manager, working with the Motor Vehicle Division and Administrative Services Division Budget Bureau, will be responsible for managing the MVD C-Mod budget, and will provide updates to the MVD DRIVE Executive Steering Committee. The Technical Project Manager will provide a budget update identifying past expenditures, encumbrances, future encumbrances, personnel costs, and any other expenses 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 following table summarizes other Project communications.

51


6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

Description Target Audience Delivery Method Frequency Responsible Party

Standard

MVD C-Mod Project Status MeetingTo discuss project status with the TRD CIO

TRD CIO Face-to-Face Weekly Technical Project Manager

Recurring meetings are scheduled through OutlookUses standard format

MVD C-Mod Team Lead Status MeetingRegularly scheduled meetings:To discuss project activities, progress, issues and results of measurement and analysis activities.Event driven:When new requirements are added, existing requirements are changed, etc.

Meeting attendees (PMs, BA,Team Leads)

Meeting minutes are stored in the Project Repository

Face-to-Face Weekly Business Project Manager (contributes to agenda)

Technical Project Manager (owns meeting notice; plans agenda topics)

Business Analyst (contributes to agenda)

Recurring meetings are scheduled through OutlookUses standard formatAn agenda is distributed in advance.

MVD DRIVE Steering CommitteeThis formal meeting addresses the accomplishments and results of all MVD projects.

Meeting Attendees (PMs, TRD CIO, MVD Director, MVD Deputy)

Face-to-Face Bi-weekly Technical Project Manager

Recurring meetings are scheduled through OutlookUses standard format

DoIT MVD Reengineering Project StatusTo describe the status of the project to DoIT

DoIT Word DocumentEmail

Monthly Technical Project Manager

Follows DoIT Standard

52


Description Target Audience Delivery Method Frequency Responsible Party

Standard

MVD C-Mod Change Control Board (CCB) MeetingReview, evaluate, approve or reject, and prioritize change requests. Group approved change requests into releases.

Attendees (PMs, BA, Team Leads as needed)Meeting minutes are stored in the Project Repository

Group Meeting or conference call

As needed Business Project Manager

Meetings are scheduled through Outlook as needed.An agenda is distributed in advance.

Issue Tracking and EscalationTo provide a framework for documenting and tracking issues to closure and escalating long-standing or critical issues for senior leadership attention.

Captured and stored in the Project Repository

Project RepositoryE-mail, conference call or in person

Whenever an issue arises or needs management involvement for resolution.

Project Managers External Issue Resolution and Escalation Procedure

53


6.5.2 S6.5.2 STATUSTATUS M MEETINGSEETINGS

Project Managers and Team Leads will meet weekly to review the current status of the project and progress, review risks, identify and resolve issues, and plan project activities. An agenda will be prepared and minutes of each status meeting will be maintained in the project archive.

6.5.3 P6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

Project Status Reports will be completed weekly by the Technical Project Manager and submitted to the MVD C-Mod Project Managers and other leads as identified by TRD. The status report will document the current status of the project, including deliverables, invoices, work performed, key issues, and high risks.

The Technical Project Manager will prepare and submit bi-weekly status reports to the MVD DRIVE Executive Steering Committee and monthly status reports to the State of New Mexico DoIT.

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)The established project metrics that will be collected for measuring the progress of a project against its planned budget, schedule, resource usage, and error rates are included below.

6.6.1 B6.6.1 BASELINESASELINES

Project Area Category MeasureSchedule Time A metric to determine if the

project is on schedule.Budget Costs Are project deliverables

within budget.Requirements Requirements Status (number

approved, implemented, and verified)

A metric to show the status of each requirement in the system.

Coding Code Completion Percentage A metric to indicate the percentage of successful code changes to the systems

Testing Defect Density Ratio (DDR) A metric indicator for the number of defects in the system, by subsystem.A quality indicator that shows the number of defects in the system.

Testing Test Case Coverage Percentage

A metric to determine whether the test cases fully test system requirements.An indicator to show whether there are sufficient tests to address system requirements

Testing Test Execution Percentage by A metric to indicate the 54


Type percentage of tests executed by use case and subsystem.The status of testing efforts and a software quality indicator.

Testing Percentage of Test Cases Passed

An indicator to show the pass percentage of test scenarios and test cases

Testing Number of Defects Found by Inspection (DFI)

An indicator to show how many defects the customer has found through inspection of the software

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.

6.7.1 6.7.1 QUALITYQUALITY S STANDARDSTANDARDS

Quality standards are defined to support the acceptance criteria for each deliverable.

No. Quality Standard Tracking Tool or Measure

1 Deliverables conform to style and grammar standards? Review of deliverables

2 Are project status reports accurate and completed on time?

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

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

Issues Log, Status Meeting Minutes

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

Risk Log, Status Meeting Minutes

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

Project Schedule, Status Meeting Minutes

55


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

Review Type Quality Standard Tools Reviewer Reports

Project Management

Meets DoIT Standards

Microsoft Word, Excel, Visual Studio, Project, PowerPoint

CIO, ITD MVD Development Manager, MVD Director

PMPScheduleBudgetRisk Management PlanRisk/Issues LogChange Request LogC-Mod Status ReportDoIT Report

IV&V Meets DoIT Standards

Microsoft Word Technical Manager, MVD Business Manager, ITD MVD Development Manager, CIO, MVD Director

IV&V PlanIV&V Reports

Requirements Accurately and completely documents business requirements

Microsoft Word, Excel Technical Manager, MVD Business Manager, ITD MVD Development Manager

Business RulesUse CasesUser Interface docs

Design, Coding and Unit Testing

Accurately and completely implements business requirements

COBOL, CICS, VB.NET, ASP, SQL Server 2005, DB2

Technical Manager, MVD Business Manager, ITD MVD Development Manager

Database ChangesCode ChangesUnit Testing Results

User Acceptance Accurately and completely tests C-Mod changes to the legacy applications

Microsoft Excel IT Business Analyst, Technical Manager, MVD Business Manager, ITD MVD Development Manager

Test ScriptsTest Script Summary ReportDefect Log

AAMVA Casual and Structured Testing

Accurately and completely tests C-Mod changes to the AAMVA central site

COBOL, CICS, VB.NET, ASP, SQL Server 2005, DB2

IT Business Analyst, Technical Manager, MVD Business Manager, ITD MVD Development Manager

AAMVA Test ResultsAAMVA Certification

Training Accurately and completely train MVD personnel on C-Mod changes to legacy applications

Microsoft Word, PowerPoint

IT Business Analyst, Technical Manager, MVD Business Manager, ITD MVD Development Manager

Training ScheduleC-Mod Lessons

Implementation Successfully migrate C-Mod changes to production environments

COBOL, CICS, VB.NET, ASP, SQL Server 2005, DB2, Microsoft Word, Excel, Visual Studio, Project

IT Business Analyst, Technical Manager, MVD Business Manager, ITD MVD Development Manager, CIO, MVD Director

Rollout ScheduleCloseout Certification requestLessons Learned

56


In addition, an Independent Verification and Validation (IV&V) contractor will review the quality of the project. The contractor will interface directly with the Technical Project Manager to perform these reviews. The following deliverables will be monitored:

Project Management Plan Project Schedule Project Risk/Issue Log Project Certification documents with acceptance Requirements documentation User Acceptance Testing documentation and results Project Status Reports

6.7.3 C6.7.3 CUSTOMERUSTOMER S SATISFACTIONATISFACTION

The Technical Project Manager should assess the on-going sense of the Motor Vehicle Division about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members.

Examples:

Areas of feedback When How OftenCustomer awareness Weekly Project Status meeting WeeklyQuality of communications As part of weekly status

reporting and status reportingWeekly

Manages project tasks Weekly Project Status meeting WeeklyProductive Meetings Weekly Project Status meeting Weekly

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESSDelivery of media; manuals; contracts; licenses; services agreements; configuration settings; in-house or vendor developed code; test cases, routines, and scripts; and other items required to operate the product.

57


Deliverable Final Approval Process Customer Acceptance Criteria

Requirements Project Managers recommends approval to Executive Level Representatives

Executive Level Representatives grant final approval by signing Deliverable Acceptance Form

Design, Coding and Unit Testing Project Managers

recommends approval to Executive Level Representatives


UATProject Managers recommends approval to Executive Level Representatives


AAMVA Casual & Structured Testing Project Managers

recommends approval to Executive Level Representatives


User TrainingProject Managers recommends approval to Executive Level Representatives


ImplementationProject Managers recommends approval to Executive Level Representatives


6.8 CONFIGURATION MANAGEMENT6.8 CONFIGURATION MANAGEMENTThe Configuration Management (CM) Plan ensures that the integrity of the MVD C-Mod Project assets and work products are established and maintained. The plan describes the CM activities

58


including the planning of CM, configuration identification, configuration control, CM reporting, and baseline verification.

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

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

Statement of Work

Requirements Documentation

User Acceptance Testing Approach and Documentation

AAMVA Casual and Structured Testing Approach and Documentation

User Training Approach and Documentation

The project will use Microsoft Visual Source Safe (VSS) for source code configuration management. All configuration items are controlled within the repository using labels to manage the baselines. The versioning of Configuration Items (CIs) is handled using the native versioning within VSS and the integrity of the data is maintained through the implementation of access controls to prevent unauthorized changes.

File locking is used to prevent multiple users from updating the same file in parallel. Procedures have been implemented to ensure that only exclusively locked files are read-write in a user’s working area, unlocked files are stored as read-only.

The native operating system standards prevent users from creating and/or adding files with duplicate file names to the same location.

6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

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

Versioning

Major Version Definition1.X Initial Draft 2.X Review Ready Draft3.0 Accepted Final Deliverable

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

59


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

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

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

Requirements- Business Requirements- Use Cases / User Interface (UI) Documents

Database Deliverables Test Deliverables Training Deliverables Implementation Deliverables

6.9 PROCUREMENT MANAGEMENT PLAN6.9 PROCUREMENT MANAGEMENT PLANProcurement management involves the acquisition of resources necessary to support the execution of the project. Because the C-Mod changes are being made to legacy applications, TRD’s existing infrastructure will continue to support the MVD systems. No additional hardware or software purchases are planned.

7. 0 PROJECT CLOSE7. 0 PROJECT CLOSEThe tasks currently identified with Project Close include:

7.1 A7.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE

Activity Responsible Party

Date

Close Project Technical Manager/CIO

Reassign Team ITD MVD Development Manager

60


Release Contractors ITD MVD Development Manager

7.2 C7.2 CONTRACTONTRACT C CLOSELOSE

Activity Responsible Party

Date

Verify Project Objectives were met

Agency/Contractor

Verify Project Deliverables were met and accepted

Agency/Contractor

Complete Project Communications

Agency/Contractor

61


8. 0 ATTACHMENTS8. 0 ATTACHMENTS

APPENDIX A – MVD C-MOD PROJECT DEFINITIONSAPPENDIX A – MVD C-MOD PROJECT DEFINITIONS

"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 Fiber Channel) that connect to the back end of local area network (LAN) servers. They remove cumbersome storage

62


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.

63


APPENDIX B – MVD C-MOD PROJECT ACRONYMSAPPENDIX B – MVD C-MOD PROJECT ACRONYMS

CIO – Chief Information Officer

CR – Change Request

CRM – Customer relationship management

DAF – Deliverable Acceptance Form

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

ITD – Information Technology Department

MVD – Motor Vehicle Division

PCC – Project Certification Committee

PM – Project Manager

PT – Project team

RFI – Request For Information

RFP – Request For Proposal

SME – Subject Matter Expert

SOW – Statement of Work

TRD – Taxation and Revenue Department

WBS – Work breakdown structure

64


APPENDIX C –PROJECT MANAGEMENT DEFINITIONSAPPENDIX C –PROJECT MANAGEMENT DEFINITIONS

Below 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

65


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.

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.

Deliverable

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

Dependencies, Discretionary

Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential 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.

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.

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.

End User

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

Fast Tracking

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

Float

66


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

67


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

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.

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.

68


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

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

69


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

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.

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.

Sprint

Sprint is an interim software build as part of the agile development methodology providing early review and feedback in the software development process.

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.

70

i “During the project management lifecycle, agencies shall select and implement a phase product development lifecycle methodology approved by the Department.” PROJECT OVERSIGHT PROCESS Memorandum

Executive Sponsor – Demesia Padilla, CPA - CDLIS... · Web view2.0 Project Authority and...

Documents

Transcript of Executive Sponsor – Demesia Padilla, CPA - CDLIS... · Web view2.0 Project Authority and...