Motor Vehicle Division (MVD)

MMOTOR VVEHICLE DDIVISION (MVD)(MVD)

DDOCUMENT MMANAGEMENT SSYSTEM

PROJECTPROJECT MANAGEMENTMANAGEMENT PLANPLAN (PMP)(PMP)

EXECUTIVE SPONSOR – JOHN MONFORTE BUSINESS OWNER – MVD DIRECTOR [VACANT] PROJECT MANAGER – JAN CHRISTINE (ACTING) ORIGINAL PLAN DATE: 03/15/2012 REVISION DATE: REVISION: 0.1

PAGE | 1 REVISION HISTORY...... 4 1.0 PROJECT OVERVIEW...... 5 1.1 Executive Summary- rationale for the Project...... 5 1.2 funding and sources...... 5 1.3 constraints...... 6 1.4 dependencies...... 6 1.5 ASSUMPTIONS...... 7 1.6 Initial Project Risks Identified...... 7 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...... 8 2.1 Stakeholders...... 8 2.2 Project Governance Structure...... 8 2.2.1 Describe the organizational structure – Org Chart...... 8 2.2.2 Describe the role and members of the project steering committee...... 8 2.2.3 Organizational Boundaries, interfaces and responsibilities...... 8 2.3 Executive Reporting...... 9 3.0 SCOPE...... 9 3.1 Project Objectives...... 9 3.1.1 Business Objectives...... 9 3.1.2 Technical Objectives...... 9 3.2 Project exclusions...... 9 3.3 Critical Success Factors...... 9 4.0 PROJECT DELIVERABLES AND METHODOLOGY...... 10 4.1 Project Management Life Cycle...... 10 4.1.1 Project Management Deliverables...... 10 4.1.2 Deliverable Approval Authority Designations...... 10 4.1.3 Deliverable Acceptance Procedure...... 11 4.2 PRODUCT LIFE CYCLE...... 11 4.2.1 Technical Strategy...... 11 4.2.2 Product and Product Development Deliverables...... 11 4.2.3 Deliverable Approval Authority Designations...... 12 4.2.4 Deliverable Acceptance Procedure...... 12 5.0 PROJECT WORK...... 12 5.1 Work Breakdown Structure (WBS)...... 12 5.2 Schedule allocation -Project Timeline...... 13 5.3 Project Budget...... 13 5.4 Project Team...... 14 5.4.1 Project Team Organizational Structure...... 14 5.4.2 Project Team Roles and Responsibilities...... 14 5.5 STAFF PLANNING AND Resource ACQUISITION...... 15 5.5.1 Project Staff...... 15 5.5.2 Non-Personnel resources...... 15 5.6 PROJECT LOGISTICS...... 15 5.6.1 Project Team Training...... 15 6.0 PROJECT MANAGEMENT AND CONTROLS...... 16

PAGE | 2 6.1 Risk and issue Management...... 16 6.1.1 Risk Management Strategy...... 16 6.1.2 Project Risk Identification...... 16 6.1.3 Project Risk Mitigation Approach...... 16 6.1.4 Risk Reporting and Escalation Strategy...... 16 6.1.5 Project Risk Tracking Approach...... 16 6.1.6 ISSUE MANAGEMENT...... 16 6.2 INDEPENDENT Verification And Validation - Iv&V...... 17 6.3 Scope Management Plan...... 17 6.3.1 Change Control...... 17 6.4 Project Budget Management...... 17 6.4.1 Budget Tracking...... 18 6.5 Communication Plan...... 18 6.5.1 Communication Matrix...... 18 6.5.2 Status Meetings...... 18 6.5.3 Project Status Reports...... 18 6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)...... 18 6.6.1 Baselines...... 18 6.6.2 Metrics Library...... 18 6.7 QUALITY OBJECTIVES AND CONTROL...... 18 6.7.1 quality Standards...... 19 6.7.2 Project and Product Review AND ASSESSMENTS...... 19 6.7.3 Agency/Customer Satisfaction...... 19 6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS...... 20 6.8 CONFIGURATION MANAGEMENT...... 20 6.8.1 Version Control...... 20 6.8.2 Project Repository (Project Library)...... 20 6.9 PROCUREMENT MANAGEMENT PLAN...... 20 7. 0 PROJECT CLOSE...... 21 7.1 Administrative Close...... 21 7.2 Contract Close...... 21 ATTACHMENTS...... 21

PAGE | 3 REVISION HISTORY

REVISION NUMBER DATE COMMENT 0.1 03/15/2012 Jan Christine 2.0 2.1 2.2

PAGE | 4 1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The New Mexico Taxation and Revenue Department (TRD) processes approximately 12,483,480 Motor Vehicle Division (MVD)-related documents per year, including those documents processed by field offices and other units of MVD, MVD’s partner agents, and various other divisions on behalf of MVD. These document processing entities include but are not limited to:  The TRD Hearing’s Bureau handles all of MVD’s license revocation and other hearings. The bureau processes 4,700-5,700 files per year, with each file including 15-30 pieces of paper.  TRD’s Tax Fraud Investigations Division (TFID) reviews all foreign national drivers’ license applications, including 9,060 applications in 2011, and processes some 500 pages per day.  TRD’s Revenue Processing Division (RPD) processes 40-50,000 documents per day, including 35-45,000 documents that are MVD-specific documents.  MVD’s Commercial Vehicles Bureau processes something in excess of 50,000 documents per year.

All documents that are required to be preserved and available for later reference are currently photocopied and microfilmed. Some driver’s license application documents have for the past few years been scanned and retained in a document authentication system provided by the Agency’s license card vendor (L-1); but that system has not proven to be efficient or effective.

The Agency expects that New Mexico will comply with the requirements, including those relating to document management and requiring digital storage and recovery of license application documents, of the federal REAL ID Act.

1.2 FUNDING AND SOURCES

SOURCE AMOUNT ASSOCIATED APPROVERS RESTRICTIONS FY09 $734,151.59 MUST BE USED DHS Department of FOR A DMS. Homeland Security, MUST BE SPENT Driver’s License BEFORE Security Grant 09/30/2012. (DLSG). CFDA # 97.089 FY10 $700,677 .00 MUST BE USED DHS FOR A DMS.

PAGE | 5 SOURCE AMOUNT ASSOCIATED APPROVERS RESTRICTIONS Department of MUST BE SPENT Homeland Security, BEFORE Driver’s License 09/30/2012. Security Grant (DLSG). CFDA # 97.089 FY11 $565,171.41 MUST BE USED DHS Department of FOR A DMS. Homeland Security, MUST BE SPENT Driver’s License BEFORE Security Grant 09/30/2012. (DLSG). CFDA # 97.089

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

NUMBER DESCRIPTION 1 MVD will not fund the installation of purchase of equipment for Private Retail Agents, Super Title Companies, Title Service Companies, or Dealerships. 2 DHS funds must be spent for a Document Management System (DMS) by the dates specified in 1.2. 3 Some part of the DMS must be capable of scanning in and retaining identity and residency documents for Driver’s License issuance.

1.4 DEPENDENCIES Types include the following and should be associated with each dependency listed.  Mandatory dependencies are dependencies that are inherent to the work being done.  D- Discretionary dependencies are dependencies defined by the project management team. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.  E-External dependencies are dependencies that involve a relationship between project activities and non- project activities such as purchasing/procurement

PAGE | 6 NUMBER DESCRIPTION TYPE M,D,E D 1.0 THE FUNDS INDICATED MUST BE USED BY THE M SPECIFED DATES D 2.0 In the project requirements, it is mandatory that existing M systems can be used to gather index and meta data for the scanned images.

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

NUMBER DESCRIPTION A 1.0 The budget for the entire project will not exceed $2,000,000 A 2.0 Existing applications can be used to capture the necessary index and meta data. A 3.0 The entire project can be completed before the end of State FY 2013.

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

NOTE: More will be known regarding the risks, when we have responses to the RFP.

Risk 1 - budget Probability Low Impact HIGH Description – Prices received from RFP will Mitigation Strategy Budget has been stated in the RFP exceed MVD available Contingency Plan Change the Scope funds.

PAGE | 7 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE The Project Organization describes the roles and responsibilities of the project team. It also identifies the other organizational groups that are part of the project and graphically depicts the hierarchical configuration of those groups. It exists to clarify interaction with the project team.

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

NAME STAKE IN PROJECT ORGANIZATION TITLE Demesia Padilla Project is for one of the TRD Cabinet Secretary, TRD Divisions Taxation and Revenue Department John Monforte Sponsor TRD Deputy Secretary [Vacant] Business Owner MVD Director Greg Saunders Responsible for any ITD TRD CIO ITD revisions\update to hardware

2.2 PROJECT GOVERNANCE STRUCTURE

2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART The Governance Structure will be completed after vendor selection. TRD expects a project structure similar to that used for the recently completed IVR project.

2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE Will be finalized with the contract, but expect an Executive Steering Committee containing the sponsor, business owner and TR CIO at a minimum.

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES Will be completed after vendor selection. TRD expects the boundaries and interfaces to be similar to those for the recently completed IVR project. MVD partner inclusion will only be known upon vendor selection and completion of subsequent contract negotiations.

PAGE | 8 2.3 EXECUTIVE REPORTING

3.0 SCOPE

3.1 PROJECT OBJECTIVES

3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTION B 1.0 Eliminate current redundant printing B 2.0 Scan, REtain, and manage access to all documents as per the agreed upon policy with SRCA.

3.1.2 TECHNICAL OBJECTIVES

NUMBER DESCRIPTION T 1.0 Provide a DMS having an Open architecture, such that existing applications can be used to capture data related to the documents scanned.

3.2 PROJECT EXCLUSIONS Private Retail Agents (PRAs), Super Title Service Companies (STSCs), Title Service Companies (TSCs), Dealerships, Courts, Law Enforcement will not be paid for by MVD, nor included in the project. A stipulation has been made in the RFP that pricing available to the Agency will also be available to these entities.

3.3 CRITICAL SUCCESS FACTORS Identify 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.

NUMBER DESCRIPTION Formal base-lined project plan that is managed and updated via a weekly Quality Metrics 1 status report. The project schedule, assigned tasks, resources and milestones are met. Quality Metrics 2 Project does not exceed budget Quality Metrics 3

PAGE | 9 NUMBER DESCRIPTION TRD Resources – TRD must provide adequate technical staffing, system Quality Metrics 4 resources, and user subject matter experts for a timely and successful implementation of TRD DMS. Contractor and the State meet their mutual obligations as defined by the Quality Metrics 5 contract. Early and active involvement of all stakeholders (including 3rd party Quality Metrics 6 interfaces). Evaluating processes outside of how they are performed now, improvements Quality Metrics 7 identified and implemented. Successful process and application training. Staff is adequately trained. Quality Metrics 8 System is secure, operable and stable. Quality Metrics 9 Collecting fees and revenue distributions are accurate and produced in a Quality Metrics 10 timely manner.

PAGE | 10 4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables Scope engagement with client Initiating and formulate strategic Project Charter, Assumptions, relationship. Constraints, Contract Defining project parameters Planning and building shared vision for Project Plan, Work Breakdown solution delivery. Structure, Project Schedule Complete work and Delivering the project in deliverables (Enhancements, Executing smaller sprints as negotiated System Testing, Training, at the time of contract signing. Acceptance Testing, Implementation) Status Reports, Maintain Monitoring the execution and Schedule, Risk/Issue Controlling (Monitoring) controlling variances to Management, Quality quality, time, and scope. Assurance, Variance Analysis Conclusion and closure of Product Acceptance, Closing project activities following Transition to Operations and deployment of solution. Support

For the TRD DMS project, the first deliverable in the implementation contract is to provide the the agreed upon Project Plans which may include: o Change Management Plan o Issue Management Plan o Critical Decisions Resolution Plan o Item Management Plan o Action Management Plan o Metrics Management Plan o Release Management Plan o Scope Management Plan o Requirements Management Plan o Schedule Management Plan o Cost Management Plan o Resource Management Plan o Client Relationship Management Plan o Communications Management Plan o Risk Management Plan o Supplier Agreement Management Plan o Project Schedule

PAGE | 11 4.1.1 PROJECT MANAGEMENT DELIVERABLES Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project.

4.1.1.1 Project Management Plan Description – Revisions and Deliverable Acceptance Criteria additions will be made to the PMP PMBOK standards with exceptions granted due to the size as the first deliverable in the and complexity of this project. vendor contract. Standards for Content and Format – PMBOK and DoIT Standards

Quality Review -.ESC, ITD PM, MVD PM with submission to DoIT.

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

DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED PRJ-DEL-001 Project Management Plan (PMP) TRD CIO MVD Director – when position is filled.

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE Submission. Upon completion of agreed upon Deliverables as set forth in Article 2 and Exhibit A of the contract, 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

PAGE | 12 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 Article 2 and Exhibit A; 2.) Complies with the terms and conditions of the RFP; 3.) Meets the performance measures for the Deliverable(s) and this Agreement; 4.) 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 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.

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

PAGE | 13 Phase Summary of Phase Key Deliverables As per DoIT standards with exceptions noted due to the nature of the project, and size and complexity of proposed solution. Will be agreed upon when a final set of deliverables is agreed upon as a parallel activity with contract negotiations.

Hardware and software will be installed in the field and at the Enterprise Data Center in Simms.

4.2.1 TECHNICAL STRATEGY TRD has mandated an open architecture capable of using existing or new web services and web applications across MVD and TRD. TRD has also provided all of the network connection speeds from the various office locations for the vendor. TRD has requested that storage space requirements for images and related data be provided by Offerors, along with all of the documents necessary for DOIT Architecture Review.

4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES 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. SINCE THE PROJECT IS A-TYPICAL, Requirements Definition and Design documentation may differ from the standard DoIT Templates. The format of documents and the quality review will be finalized during contract negotiation.

4.2.1 Requirements Definition (Phase 1 and 2)

Description – Review and revise Deliverable Acceptance Criteria - MVD and any other requirements specifications applicable client agree that the requirements are correct, and included the RFP #20-333-00- an RTM has been created that allows traceability through 11076 UAT of the original requirements.

Standards for Content and Format – Requirements matrix, cross-reference to use case or script document, and to the appropriate test cases.

Quality Review – Deliverable Acceptance Signoff by the Business Owner and ITPM.

PAGE | 14 4.2.2 Design (Phase 1 and 2)

Description – Design documents Deliverable Acceptance Criteria – Design addresses all Phase for the scripts, interfaces, voice 1 and Phase 2 requirements. recordings, and call distribution. Standards for Content and Format - Since the DoIT templates are not really designed to accommodate this type of system design, the content and format will be agreed upon between Contractor and TRD.

Quality Review - Deliverable Acceptance Signoff by the Business Owner and ITPM.

4.2.3 Hardware and Software Installation (Phase 1)

Description – Installation of Deliverable Acceptance Criteria - All hardware and software equipment scanner and server is tested and working correctly. Any connections via web equipment needed for the DMS services between Contractor and TRD are functioning as system. specified.

Standards for Content and Format - Architectural Diagram submitted for the TARC is completed and all connections tested.

4.2.4 Testing (Phases 1 & 2)

Description – End to end, Deliverable Acceptance Criteria – integrated testing of DMS 1. Requirements from RFP functionality. #20-333-00-11076are satisfied. 2. Test results from Contractor testing are provided in a commonly agreed upon format. 3. Tests provide 100% coverage of all test scenarios specified by the Department.

Standards for Content and Format – Agreed upon format for Test Scripts congruent with formats used by other major Department projects.

PAGE | 15 4.2.5 Training (Phases 1 & 2)

Description - Deliverable Acceptance Criteria -

Standards for Content and Format -

Quality Review -

Deliverable Acceptance Criteria – Training design and draft materials are approved by the appropriate parties as having sufficient detail for the specific User roles. Materials are provided in electronic format to the Department.

Standards for Content and Format – Content must include all items in appropriate Contract Deliverable.

4.2.6 Maintenance and Support (Phases 1& 2)

Description – Support and Deliverable Acceptance Criteria – Status report and services Maintain the installed software and as outlined in contract TR12-XX. hardware. Standards for Content and Format – To be agreed upon between Contractor and Department.

Quality Review – Deliverable Acceptance Signoff by the Business Owner, ITPM, and TRD ITD Ops Representative.

4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS Will be completed in parallel with contract negotiations.

DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED PROD-DEL-002 Requirements Definition Business Owner IT PM PROD-DEL-003 Design Business Owner IT PM PROD-DEL-004 Installation Business Owner IT PM

PAGE | 16 DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED Designated ITD Rep PROD-DEL-005 Testing Business Owner IT PM ITD Ops Designee PROD-DEL-006 Training Business Owner PROD-DEL-007 Maintenance and Support Business Owner ITD Ops Designee

4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE Submission. Upon completion of agreed upon Deliverables as set forth in Article 2 and Exhibit A of the contract, 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 Article 2 and Exhibit A; 2.) Complies with the terms and conditions of the RFP; 3.) Meets the performance measures for the Deliverable(s) and this Agreement; 4.) 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.

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

5.0 PROJECT WORK

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

Identifier Work Package Description Definition/Objective Milestone/Deliverable

NOT AVAILABLE AT THIS TIME

PAGE | 18 5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE The project timeline is a high-level view of project activities with a focus on project milestones. The project timeline does not replace the need for a detailed project schedule and it is to highlight key events such as deliverable due dates and when go/no-go decisions are made. Please provide a more detailed project schedule as an attachment to this plan

Identifier Task/Activity Resource Milestone Effort/ Start Finish Dependent Name Name (Y/N) Duration Task

Not available at this time.

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

Identifier Work Package or Budget Category Cost

SPECIFICS NOT AVAILABLE AT THIS TIME

Phase / Activity Associated Deliverables Estimated Budget Umbrella Tasks Phase 1 Project plan $20,000 Project Preparation Project Schedule & Planning IV&V Contract $30,000 Phase 2 Implementation $1,950,000 Phase 3 $0 Project Closing

PAGE | 19 Phase / Activity Associated Deliverables Estimated Budget TOTALS $2,000,000

5.4 PROJECT TEAM

5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE The project team is not yet set or appointed. The final org structure will be created in parallel with contract negotiations.

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

ROLE RESPONSIBILITY NAME FUNCTIONAL AREA Contractor Team Provide project plans and Contractor All weekly status reports, prerogative design, installation, implementation, training and testing. Business Owner Ensure all resources Adam Diamond Field Ops necessary for project And RPD USPS success are provided by the Intake appropriate Division. Ensure timely review of all documents. IT PM Internal and external status Jan Christine All reports, including budget updates.

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

NOTE: SUBJECT TO CHANGE DURING CONTRACT NEGOTIATIONS.

5.5.1 PROJECT STAFF

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

Business Owner 0 Unknown Available Field Ensure all resources Office and necessary for project success RPD are provided by the Intake appropriate Division. Ensure experience timely review of all documents.

TRD IT Project Manager 0 Unknown Available PMP Internal and external status reports, including budget updates. Contract Management.

Contractor Project Included in Full Time Available PMP Updates to all plans provided Manager hosting preferred by Contractor. Status reports. agreement

Contractor additional staff Included in As required Available As needed Discretion of Contractor hosting by by agreement Contractor contractor

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

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

NOT KNOWN AT THIS TIME

5.6 PROJECT LOGISTICS

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

5.6.1 PROJECT TEAM TRAINING

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

NOT AVAILABLE AT THIS TIME

6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT

6.1.1 RISK MANAGEMENT STRATEGY

RISK MANAGEMENT WILL BE PERFORMED AS PER DOIT GUIDELINES, UNLESS NOTED HERE AND IN THE CONTRACT. PMBOK©: Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” Issue: “A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.”

6.1.1 RISK MANAGEMENT STRATEGY 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 will be available as a separate project deliverable.

PAGE | 22 6.1.2 PROJECT RISK IDENTIFICATION 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 PROJECT RISK MITIGATION APPROACH For each identified risk a mitigation approach will be identified to minimize the likelihood of occurrence and impact to the project.

6.1.4 RISK REPORTING AND ESCALATION STRATEGY Risks will be escalated for visibility or information if:  The risk has impact outside of the NM TRD IVR/VPDMS 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 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 PROJECT RISK TRACKING APPROACH 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 Management 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.

PAGE | 23 • 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.

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

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

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

PAGE | 25 6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V Contact for IV&V will be signed before TRD appears before the PCC for Implementation Certification. The IV&V plan will:  Evaluate and verify that processes, contracts, and system designs comply with the specified requirements of the Enterprise Architecture and Standards  Evaluate and validate that products and deliverables of a given development phase fulfill the requirements and performance outcomes set forth in the scope and project plan  Provide a “close-out” report to the Executive Board at the end of project. The intention of the project team is to select an IV&V vendor from the State Price Agreement list.

6.3 SCOPE MANAGEMENT PLAN Scope management and change control are critical to maintaining schedule, achieving the desired outcomes on time, deploying on time, and delivering to the expected level of quality. Project scope is not static and may evolve, which emphasizes the importance of proper scope control. Project scope management is conducted in the context of program-level integrated planning and dependency management, allowing alignment between individual stages of the project and other concurrent efforts to produce the desired project results. The scope management process includes:  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. The figure below illustrates the approach to scope management.

PAGE | 26 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 Requirements Traceability Matrix (RTM)  Scope Management Plan of the Project Management Plan to track, manage, and document project scope clarification Scope Planning The contractual Statement of Work (SOW) as part of the contract 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 Definition TRD 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; however, some requirements and deliverables may require further elaboration among the Project teams to deliver successfully. As such, a Deliverable Expectation Document (DED) will be used to outline and define acceptance criteria for each major deliverable. The DED will provide an early opportunity for the Project teams to coordinate and collaborate about the contents of each deliverable, thus yielding a higher-quality deliverable and a more successful project.

PAGE | 27 Scope Verification As 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. Using the DED created for each deliverable, the Project Team will maintain responsibility for reviewing each major deliverable before submission to the Agency for acceptance. On approval by the Contractor project manager, we will submit the deliverable to the Agency for acceptance. Under the proposed terms of this procurement, the Agency will accept or reject the deliverable with comments within 15 days. 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 CHANGE CONTROL 6.3.1.1 Change Control Process The 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?

PAGE | 28  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 Contractor 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 analysis. The project manager, with assistance from the project team, will determine

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

PAGE | 30 6.3.1.2 Change Control Board (CCB) The Change Control Board (CCB) for the New Mexico TRD MVD System Reengineering project will include the following participants who will be authorized to participate in to support review of and approval of changes to the project.

Participant Position

Greg Saunders TRD CIO

Adam Diamond Business Owner

Jan Christine TRD ITD Project Manager

Contractor Project Manager

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

6.4.1 BUDGET TRACKING Monthly reports from the TRD Administrative Services Division include the project budget and a expenditure, encumbered POs and unencumbered POs for the project to date.

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

6.5.1 COMMUNICATION MATRIX

Description Target Delivery Frequency Responsible Standard Audience Method Party

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

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

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

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

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

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

DoIT TRD DoIT Word Monthly  TRD Lead Follows DoIT IVR/VPDMSDMS Project Document Project Standard Status Manager Email To describe the status of the project to DoIT

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

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

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

6.5.2 STATUS MEETINGS Project Managers 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 PROJECT STATUS REPORTS Project Status Reports will be completed weekly by the Contractor Project Manager and submitted to the TRD IVR/VPDMSDMS 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 TRD Technical Project Manager will prepare and submit bi-weekly status reports to the MVD DRIVE Executive Steering Committee and month status reports to the State of New Mexico DoIT

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

PAGE | 34 6.6.1 BASELINES Project Area Category Measure Schedule Time A metric to determine if the project is on schedule. Budget Costs Are project deliverables within budget. Requirements Requirements Status A metric to show the status of each (number approved, requirement in the system. implemented, and verified) Build Build Completion A metric to indicate the percentage of Percentage successful builds of the software Testing Defect Density Ratio A metric indicator for the number of (DDR) defects in the system, by subsystem. A quality indicator that shows the number of defects in the system. Testing Test Case Coverage A metric to determine whether the test Percentage cases fully test system requirements. An indicator to show whether there are sufficient tests to address system requirements Testing Test Execution A metric to indicate the percentage of tests Percentage by Type executed by use case and subsystem. The status of testing efforts and a software quality indicator. Testing Test Execution A metric to indicate the percentage of tests Percentage by Type executed by use case and subsystem Testing Percentage of Test Cases An indicator to show the pass percentage Passed of test scenarios and test cases Testing Number of Defects An indicator to show how many defects Found by Inspection the customer has found through inspection (DFI) of the software Testing Defect Removal The metric can be calculated for the entire Effectiveness (DRE) development process, for the front-end (before code integration), and for each phase. It is called early defect removal and phase effectiveness when used for the front-end and for specific phases, respectively. The higher the value of the metric, the more effective the development process and the fewer the defects that escape to the next phase or to the field. This metric is a key concept of the defect removal model for software development.

6.6.2 METRICS LIBRARY Due to the simplicity of this project, cost and schedule metrics will be included in the status report. Test metrics will be found in one test script, on first tab of the *.xls test.

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

6.7.1 QUALITY STANDARDS

No. Quality Standard Tracking Tool or Measure

Technical Writer 1 Deliverables conform to style and grammar standards? review of deliverables

Agency-approved Contractor Status 2 Are project status reports accurate and completed on time? Report Template, E- mail Transmittals, Status Log

Are project issues being handled within appropriate timeframes Issues Log, Status 3 and being escalated as appropriate (avoiding stale issues)? Meeting Minutes

Are risks reviewed regularly with mitigation plans developed for Risk Log, Status 4 high impact/probable risks? Meeting Minutes

Project Schedule, Is the project schedule current on the progress of project 5 Status Meeting activities? Minutes

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS

Plan At the end of Project Planning Phase Gate Architecture At the completion of the Architecture Plan Technical Design At the end of Design Phase Gate and Technical Pre-Deploy At the end of Test, prior to Release Phase Gate and Technical

In addition, an Independent Verification and Validation (IV&V) auditor will periodically audit the quality of the project. The auditor will interface directly with the Agency IT PM to perform these audits. The following deliverables will be monitored:  Project Management Plan  Project Schedule  Project Risk/Issue Log  Project Certification documents with acceptance  High-level design document  Requirements documentation  Interface descriptions

PAGE | 36  Project Status Reports

6.7.3 AGENCY/CUSTOMER SATISFACTION The project manager should assess the on-going sense of the customer agency about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members. Examples: Areas of feedback When How Often Weekly Project Status meeting Weekly Agency awareness As part of weekly status Weekly Quality of communications reporting and status reporting Weekly Project Status meeting Weekly Manages project tasks Weekly Project Status meeting Weekly Productive Meetings

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS How the client takes procession of the product. Delivery of media; manuals; contracts; licenses; services agreements; configuration settings; status of patches to COTS products; in-house or vendor developed code; test cases, routines, and scripts; and other items required to operate the product. Deliverable Final Approval Process Customer Acceptance Criteria UAT Business Owner Approvals via the IT PM Deliverable Acceptance Sponsor form. MVD Director Reports, Documentation, Business Owner Approvals via the and Training IT PM Deliverable Acceptance form.

6.8 CONFIGURATION MANAGEMENT Configuration Management determines how project information (files, reports, designs, memos, documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control, etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team awareness are critical. Configuration Management will be applied across the life cycle of the project to provide the appropriate level of control for all project configuration items.

PAGE | 37 Each of these groups, listed below, consist of formally controlled configuration items (CIs). Changes to these formally controlled items are managed via change control:  Proposal Documents  Estimate Documentation  Requirements Documentation  Statement of Work  Supplier Statement of Work  Architecture  Design Specifications  Application Source and Executables  Business Organization Components  Bills of Materials  Build Construction Guides  Deployment Sources

The project will use Microsoft Team Foundation Server (TFS) for source code configuration management. TFS will be configured to control all source code for the NM MVD project. 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 TFS 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 VERSION CONTROL 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 Definition 1.X Internal Draft 2.X Client Ready Draft 3.0 Accepted Final Deliverable

6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)

PAGE | 38 Projects often have some element of procurement, i.e. the requirement to purchase goods and/or services from outside the organization. The procedures to be used to handle these procurements should be included here. Activities such as a make-or-buy analysis; writing requirements; solicitation planning, evaluation and selection; inspection and acceptance; contract closeout should all be included. The Project Library is an electronic storage place where all documentation relating to the project is stored and maintained. The TRD MVD Driver Reengineering 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  Architecture Plan  Requirements - Requirements Traceability Matrix - Use Cases / User Interface (UI) Documents - Letters, Forms, Reports Definition  Design Deliverables  Test Deliverables  Implementation Plan and Deliverables

6.9 PROCUREMENT MANAGEMENT PLAN

Procurement management involves the acquisition of the hardware and software necessary to support the execution of the project. The Contractor Technical Services staff assists the project team by collaboratively defining a procurement plan that includes procurement schedules and time lines, which is executed through the Infrastructure work stream. A formal Procurement Management is not needed for this rapid, low procurement complexity project.

7. 0 PROJECT CLOSE The tasks currently identified with Project Close are delineated in 7.1 and 7.2.

7.1 ADMINISTRATIVE CLOSE

Activity Responsible Party Date

PAGE | 39 Conclude Project Control Agency/Contractor Reassign Team Contractor Appoint Support Contacts Agency/Contractor

7.2 CONTRACT CLOSE Contract close will not occur until the end of the support and maintenance period in contract TR11-28. A partial close will be performed at the end of system UAT, which will include:

Activity Responsible Party Date Verify Project Objectives were Agency/Contractor met Verify Project Implementation Agency/Contractor Deliverables were met and accepted Complete Plan Components Contractor Complete Project Agency/Contractor Communications

ATTACHMENTS NONE at this time.

Attachments will be included for additional information, but are not formally considered part of the Project Plan for approvals and change management purposes. Examples  Acronyms, abbreviations and definitions  Technical glossary of IT terms  Project Work breakdown schedule  Project timeline

PAGE | 40