Project Management Plan (PMP)

POINT-OF-SALE
PROJECT MANAGEMENT PLAN

(PMP)
EXECUTIVE SPONSOR – RICK HOMANS

BUSINESS OWNER – KEN ORTIZ
PROJECT DIRECTOR – JOEL MATEK
PROJECT MANAGER – JOHN SALAZAR
ORIGINAL PLAN DATE: DECEMBER 10, 2008
REVISION DATE: JANUARY 21, 2009
REVISION: 3.1
PROJECT MANAGEMENT PLAN FOR [PROJECT NAME]
REVISION HISTORY................................................................................................. III

PREPARING THE PROJECT MANAGEMENT PLAN.................................................................................................IV
ABOUT THIS DOCUMENT................................................................................................................................... IV
Project Oversight Process Memorandum – DoIT, July 2007.....................................................................................iv
1.0 PROJECT OVERVIEW...................................................................................................................................... 1
1.1 Executive Summary- rationale for the Project.....................................................................................................1
1.2 funding and sources.............................................................................................................................................2
1.3 constraints............................................................................................................................................................2
1.4 dependencies.......................................................................................................................................................2
1.5 ASSUMPTIONS......................................................................................................................................................3
1.6 Initial Project Risks Identified.............................................................................................................................4
2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................6
2.1 Stakeholders.........................................................................................................................................................6
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............................................................9
2.2.3 Organizational Boundaries, interfaces and responsibilities........................................................................9
2.3 Executive Reporting.............................................................................................................................................9
3.0 SCOPE......................................................................................................................................................... 10
3.1 Project Objectives..............................................................................................................................................10
3.1.1 Business Objectives....................................................................................................................................10
3.1.2 Technical Objectives...................................................................................................................................10
3.2 Project exclusions...............................................................................................................................................11
3.3 Critical Success Factors......................................................................................................................................11
4.0 PROJECT DELIVERABLES AND METHODOLOGY............................................................................................. 11
4.1 Project Management Life Cycle.........................................................................................................................11
4.1.1 Project Management Deliverables............................................................................................................13
4.1.2 Deliverable Approval Authority Designations............................................................................................15
4.1.3 Deliverable Acceptance Procedure............................................................................................................16
4.2 PRODUCT LIFE CYCLE..........................................................................................................................................16
4.2.1 Technical Strategy......................................................................................................................................17
4.2.2 Product and Product Development Deliverables.......................................................................................18
4.2.3 Deliverable Approval Authority Designations............................................................................................19
4.2.4 Deliverable Acceptance Procedure............................................................................................................20
5.0 PROJECT WORK........................................................................................................................................... 21
5.1 Work Breakdown Structure (WBS)....................................................................................................................21
5.2 Schedule allocation -Project Timeline................................................................................................................23
5.3 Project Budget....................................................................................................................................................23
5.4 Project Team......................................................................................................................................................24
5.4.1 Project Team Organizational Structure.....................................................................................................24
5.4.2 Project Team Roles and Responsibilities....................................................................................................25
5.5 STAFF PLANNING AND Resource ACQUISITION.................................................................................................28
5.5.1 Project Staff................................................................................................................................................28
5.5.2 Non-Personnel resources...........................................................................................................................30
5.6 PROJECT LOGISTICS............................................................................................................................................30
REVISION: 3.0 DOIT-PMO-TEM-020 I OF VI

5.6.1 Project Team Training................................................................................................................................30

6.0 PROJECT MANAGEMENT AND CONTROLS.................................................................................................... 31
6.1 Risk and issue Management..............................................................................................................................31
6.1.1 Risk Management Strategy.......................................................................................................................31
6.1.6 ISSUE MANAGEMENT................................................................................................................................32
6.2 INDEPENDENT Verification And Validation - Iv&V.............................................................................................33
6.3 Scope Management Plan...................................................................................................................................33
6.3.1 Change Control..........................................................................................................................................34
6.4 Project Budget Management.............................................................................................................................36
6.4.1 Budget Tracking.........................................................................................................................................37
6.5 Communication Plan..........................................................................................................................................37
6.5.1 Communication Matrix..............................................................................................................................38
6.5.2 Status Meetings.........................................................................................................................................38
6.5.3 Project Status Reports................................................................................................................................38
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)......................................................................................38
6.6.1 Baselines....................................................................................................................................................39
6.6.2 Metrics Library...........................................................................................................................................39
6.7 QUALITY OBJECTIVES AND CONTROL................................................................................................................39
6.7.1 quality Standards.......................................................................................................................................39
6.7.2 Project and Product Review AND ASSESSMENTS.......................................................................................40
6.7.3 Agency/Customer Satisfaction...................................................................................................................40
6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS.......................................................................................41
6.8 CONFIGURATION MANAGEMENT......................................................................................................................41
6.8.1 Version Control...........................................................................................................................................41
6.8.2 Project Repository (Project Library)...........................................................................................................41
6.9 PROCUREMENT MANAGEMENT PLAN...............................................................................................................41
7. 0 PROJECT CLOSE........................................................................................................................................... 42
7.1 Administrative Close.....................................................................................................................................42
7.2 Contract Close...............................................................................................................................................42
APPENDIX A – WORK BREAKDOWN STRUCTURE................................................................................................ 43
APPENDIX B - PROJECT SCHEDULE/GANTT CHART.............................................................................................. 44
APPENDIX C - PROJECT BUDGET........................................................................................................................ 45
APPENDIX D - RISK ANALYSIS............................................................................................................................. 46
APPENDIX E - PROJECT LIBRARY........................................................................................................................ 47
APPENDIX F - SAMPLE PROJECT FORMS............................................................................................................. 48
Project Change Request Form.............................................................................................................................48
Project Status Report..........................................................................................................................................49
Sample issues report...........................................................................................................................................50
APPENDIX G – TRD POS PROJECT DEFINITIONS.................................................................................................. 51
APPENDIX H – TRD POS PROJECT ACRONYMS.................................................................................................... 52
APPENDIX P - Project Management Definitions...........................................................................................................53
REVISION: 3.0 DOIT-PMO-TEM-020 II OF VI

REVISION HISTORY
REVISION NUMBER DATE COMMENT

1.0 July 27th, 2007 DoIT Project Management Office Revision
2.0 December 10, 2008 Initial TRD Draft
3.0 January 20, 2009 Added object links for Visio and Project files
3.1 January 21, 2009 Minor revisions
REVISION: 3.0 DOIT-PMO-TEM-020 III OF VI

PREPARING THE PROJECT MANAGEMENT PLAN
The workbook for preparation of the Project Management Plan is built around helping the project
manager and the project team to use the Project Management Plan in support of successful
projects. Please refer to it while developing this PMP for your project.
ABOUT THIS DOCUMENT
Project Oversight Process Memorandum – DoIT, July 2007
1 “Project management plan” is a formal document approved by the executive sponsor and the
Department and developed in the plan phase used to manage project execution, control, and
project close.
2 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.
3 A project plan includes at least other plans for issue escalation, change control,
communications, deliverable review and acceptance, staff acquisition, and risk management.
4 “Project manager” means a qualified person from the lead agency responsible for all aspects
of the project over the entire project management lifecycle (initiate, plan, execute, control,
close). The project manager must be familiar with project scope and objectives, as well as
effectively coordinate the activities of the team. In addition, the project manager is
responsible for developing the project plan and project schedule with the project team to
ensure timely completion of the project. The project manager interfaces with all areas
affected by the project including end users, distributors, and vendors. The project manager
ensures adherence to the best practices and standards of the Department.
5 Project product” means the final project deliverables as defined in the project plan meeting all
agreed and approved acceptance criteria.
6 “Product development life cycle” is a series of sequential, non-overlapping phases comprised

of iterative disciplines such as requirements, analysis and design, implementation, test and
deployment implemented to build a product or develop a service.
REVISION: 3.0 DOIT-PMO-TEM-020 IV OF VI

1.0 PROJECT OVERVIEW
1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT

The New Mexico Taxation and Revenue Department (TRD) would like to be able to allow alternative
forms of payment on outstanding tax debts at the Audit and Compliance Division’s (ACD) five field
offices and the Motor Vehicle Division’s (MVD) 33 state-run, 39 municipally- and county-operated and
18 privately-owned field offices at which driver’s licenses and vehicle titles and registrations are issued .
Currently only cash and checks are accepted. The proposed Point of Sale solution (POS) would allow credit
card and debit payments to occur leading to increased annual revenues from taxpayers.
IBM completed a needs assessment of the business practices and the technical infrastructure utilized by
TRD-MVD. They stated that in a nationwide comparison the State of New Mexico MVD systems would
rate very low. A major finding of the IBM assessment is that there are three critical deficiencies in the
TRD-MVD revenue collection, reconciliation accounting and distribution processes:
1. Cash transactions are out of balance. Manual revenue collection in MVD field offices, using
unsecured cash drawers, is prone to errors, rework, and weak financial controls.
2. MVD field offices collect fees for driver’s license, title and registration information using the
MVD 2.0 system. Distributions are performed with the MVR0 system. Cash accounting
transactions do not always match between these systems.
3. Over $380 million in MVD annual revenue is not distributed (to General fund, local govt., etc.) in
a timely and accurate manner. A series of more than 40 complex custom spreadsheets are
vulnerable to inconsistencies, manual data entry errors, and data corruption.
An IBM “Must Do Now” recommendation is for MVD to purchase a Commercial-Off-The-Shelf (COTS)

Point of Sale (POS) system. This critical system is for a cash register based financial point of sale system
to handle revenue collection, transaction tracking, reconciliation, deposit and disbursement of
approximately $380 million annually in MVD fees. TRD now has what has been referred to as a “cigar
box” method of collection and tracking revenue: manual cash drawers not linked to any system; faxed
paper reports; lack of standardization; use of hand-held calculators to make change and reconcile money
collected; manual paper reconciliation and daily close forms; use of 40 Excel spreadsheets to account for
and distribute (e.g. to local governments) the collected revenue. Purchase of a COTS POS system will
minimize manual revenue processing, reporting, and complexity resulting in a more efficient, productive
system improving service delivery to TRD customers. A new POS system would be designed to meet
current and future needs, such as providing the ability to add new services and interfacing with the state
enterprise financial accounting system (Statewide Human Resources, Accounting, and Management
REporting System--SHARE). This system would include appropriate audit trails and security features.
Twenty-seven other states have implemented MVD POS systems .
Initial planning of this project has been underway for some time; although we are showing a “Planned
Start Date” of 9/1/08. The previously certified Infrastructure Upgrade project included a POS planning
sub-component that is tracked separately. Hardware for POS includes the addition of new secure cash
drawers, credit card and check scanners, receipt printers, and if needed, replacement of PCs and monitors
at MVD field office locations. All POS hardware will be located directly in TRD field offices. The exact
configuration and detailed requirements will not be completed until the POS RFP has been awarded. TRD
is currently planning a separate RFP for the purchase of POS hardware, and another RFP for the POS
and/or MVD COTS replacement system.
PAGE | 1
Any required servers for POS will be located within the DoIT Data center in TRD racks, and will be
administered by TRD staff. At this time an exact hardware configuration is not known.
Network demand is expected to be consistent with the current MVD load since all MVD transactions are
already using the web-based MVD 2.0 application already. There may be a small increase in amount of
data per transaction to handle additional financial information; although this may instead be performed
locally within the POS hardware (based on type of POS hardware that is purchased).
1.2 FUNDING AND SOURCES
SOURCE AMOUNT ASSOCIATED APPROVERS

RESTRICTIONS
Laws of 2008: Chapter $2,752.5k
3, Section 7, Item 9
1.3 CONSTRAINTS
Constraints are factors that restrict the project by scope, resource, or schedule.
NUMBER DESCRIPTION
1
2
3
4
5
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 | 2
NUMBE DESCRIPTION TYPE M,D,E

R
1 Identify, acquire, and configure vendor-provided COTS E

software solution to meet business requirements
2 Identify, acquire, and configure vendor-provided POS E

hardware that is compatible w/ MVD2.0 hardware and
software environments
3 Integration of POS hardware and software w/ MVD 2.0 M

utilizing web services with XML
4 Integration of COTS solution with SHARE for daily field M

office bank deposits, and monthly distributions for MVD
beneficiaries
5 Integration of COTS solution with SHARE for reconciliation M

of fees and revenue between TRD, State Treasures Office and
DFA.
6 Modify MVD2.0 to remove financial transaction business M

rules
7 Development of a MVD Financial Transaction Engine Web M

Service
8 Development of a Table Driven Fee Schedule for each type M

of MVD Transaction
8 Configuration of POS COTS solution to add inventory items M

each possible MVD product or service, and create a fee
schedule for each item.
9 Successful Proof-of-Concept project M
10
11
12
1.5 ASSUMPTIONS
Assumptions are planning factors that, for planning purposes, will be considered true, real, or certain.
PAGE | 3
NUMBER DESCRIPTION
1 System will integrate with TRD MVD computing infrastructure
2 POS hardware/equipment will work with existing MVD2.0
3 POS hardware will work with POS COTS solution
4 POS COTS software will integrate with SHARE
5 Adequate Budget will be available
6 Adequate staffing levels with the proper skill sets necessary to ensure the
system will perform as engineered
7 Staff is trained properly on the operation of the system to ensure continued
success of the program
8 Vendor will continue to support software and release upgrades/patches on a
regular basis.
9 Business owners will embrace POS equipment
1.6 INITIAL PROJECT RISKS IDENTIFIED

In this section identify and describe how each risk will be managed. Include the steps that will
be taken to maximize activity that will result in minimizing probability and impact of each risk.
[Risk :1 IT Resources]
Probability: Medium Impact : HIGH
Description -
TRD IT resource availability Mitigation Strategy: Ensure Senior Management Stakeholders are
involved and support the project. Ensure project implementation is a
priority among TRD team members
Contingency Plan:
Have 2nd layer of individuals defined who may able to cover task/
responsibilities
[Risk 2: Integration]
Probability: Medium Impact :HIGH
Description -
Mitigation Strategy :
Utilize Central Issuance Integration Model
PAGE | 4
Contingency Plan
Integration with MVD
Utilize Central Issuance project deliverables and documentation to
computing environment
identify MVD2.0 system integration requirements.
[Risk 3: COTS solution not available]

Description -
POS COTS solution not Mitigation Strategy :
available Identify a COTS solution with similar architecture in place in MVD
computing environment
Contingency Plan
Contact possible POS vendors identified in IBM Needs Assessment
Study; Contact other states who have implemented POS solutions, and
contact MVD solution providers with POS solutions.
[Risk 4: POS hardware not supported by COTS solution]

Description -
POS hardware not Mitigation Strategy :
supported by COTS Research COTS solution and identify compatibility w POS hardware
solution Contingency Plan
Find POS equipment which is USB connected and does not require
specialized driver software or configuration
[Risk 5: User acceptance of POS hardware]

Probability: HIGH Impact :HIGH
Description -
User acceptance of POS Mitigation Strategy :
hardware Establish POS User Advisory Group responsible for assisting with
POS hardware selection and configuration
Contingency Plan
Place emphasis on the benefits of POS, and provide multiple POS
configuration models.
[Risk 6: Key project member departs]

Description -
Key project member Mitigation Strategy :
departs Have two levels of coverage for each project staff member
Contingency Plan
Communication and awareness of each team member tasks and
responsibilities
PAGE | 5
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

RICK HOMANS PROGRAM FINANCIAL TAXATION AND CABINET
RESPONSIBILITY REVENUE SECRETAR
DEPARTMENT Y
(TRD)
DONA COOK PROGRAM FINANCIAL TAXATION AND DEPUTY

RESPONSIBILITY REVENUE CABINET
DEPARTMENT SECRETAR
(TRD) Y
KEN ORTIZ PROGRAM ADMINISTRATION TRD, MOTOR MVD

RESPONSIBILITY VEHICLE DIRECTOR
DIVISION
ALICIA ORTIZ PROGRAM ADMINISTRATION TRD, MOTOR MVD

RESPONSIBILITY VEHICLE DEPUTY
DIVISION DIRECTOR
JOEL MATEK IT INFRASTRUCUTRE TRD, CHIEF

PROJECT DIRECTOR INFORMATION INFORMAT
TECHN OLOGY ION
DIVISION OFFICER
LEE BACA MVD APPLICATIONS TRD, IT

DEVELOPMENT INFORMATION MANAGER
TECHN OLOGY
DIVISION
MAC LEWIS MVD POLICY AND PROCEDURE TRD, MOTOR BUREAU

VEHICLE CHIEF
DIVISION
PAGE | 6
NAME STAKE IN PROJECT ORGANIZATION TITLE

TOBY WILLIAMS MVD FIELD OFFICE OPERATIONS TRD, MOTOR BUREAU
VEHICLE CHIEF
DIVISION
JOSIE ORTIZ MVD FIELD OFFICE OPERATIONS TRD, MOTOR BUREAU

VEHICLE CHIEF
DIVISION
MEGAN MVD TRAINING TRD, MOTOR TRAINING

MCCAWLEY- VEHICLE MANAGER
RIVERA DIVISION
TRD IT TECHNICAL SUPPORT OF TECHNOLOGY Application

TECHNOLOGY AND SYSTEMS AND SYSTEM Developer,
SYSTEM SUPPORT SUPPORT Database
Administrati
on, System
Administrati
on
JOHN SALAZAR PROJECT MANAGER CONTRACTOR Contract

employee
PAGE | 7
2.2 PROJECT GOVERNANCE STRUCTURE

2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART
Executive Sponsor Rand Tilton

Rick Homans MVD Project Manager
Toby Williams
MVD Bureau Chief
Rick Homans
Josie Ortiz
TRD Cabinet
MVD Bureau Chief
Secretary
Bill Allemand
Dona Cook MVD FO Manager
TRD Deputy Business Owner
Secretary Ken Ortiz Mac Lewid
MVD Policy & Procedure
Ken Ortiz
MVD Director Megan McCawley-Rivera
MVD Trainer
Alicia Ortiz
Deputy MVD
Director
IT Technical Team Lead/
Joel Matek
Project Director MVD Business Owners
TRD CIO
Joel Matek
Executive Steering Committee
Lee Baca
MVD Applications
Development Manager
Project Manager
John Salazar Sailam Vasudevan
Lead IT Developer
Venkat Dodda
IT Developer
Tirumal Rao,
IT Developer
Feng He
IT Developer
Rama Bandapelli
IT Developer
Rao Chad
DBA
IT Technical Team
PAGE | 8
2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE
ROLE RESPONSIBILITY
Executive Project The point person for the project within the highest level of the Taxation and
Sponsor Revenue Department.
Responsibilities include:
 Champion the project.
 Consider potential changes facing the organization and assess the
organizational impact
 Decide which changes will be instituted, communicate priorities
and provide resources to ensure success
 Responsible for creating an environment that enables changes to be
made on time and within budget.
 Participate in planning sessions
 Member of Steering Committee
 Ultimate project responsibility
Steering Committee Is chartered to provide governance over the direction and support of the
Member 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
 Contributes to lessons learned
2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

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

Meetings will be conducted with TRD Executive Steering Committee members, Business Owners, and
IT Technical teams on a regularly scheduled basis.
Whiteboard sessions outlining project task and resource assignment schedules and agendas are
conducted throughout the process and transferred to Microsoft project.
PAGE | 9
Project status updates reports will be verbally communicated to Business Owners conducted at weekly
staff meetings by both Divisions
TRD management will be kept informed on progress of the project periodically throughout the project
life cycle.
Special oral and written Project Management and IV&V reports will be given on project progress to the
POS Steering Committee meetings.
3.0 SCOPE
3.1 PROJECT OBJECTIVES

3.1.1 BUSINESS OBJECTIVES
NUMBER DESCRIPTION
Bus. Objective 1 Improve delivery of service to the citizens of New Mexico: A new
COTS application would result in lower wait times at MVD field offices,
a decrease in the number of errors and an increase in the accuracy of fee
distributions.
Bus. Objective 2 Reduce cost and complexity of Information Technology operations:

A new COTS motor vehicle system will streamline and integrate
processes that cross business units, multiple applications, and agency
boundaries. Migrating current MVD Revenue System (MVRO) off of
mainframe would result in a 15 - 20% cost savings for TRD/ITD.
3.1.2 TECHNICAL OBJECTIVES

NUMBER DESCRIPTION
Tech. Objective 1 Successfully implement a POS front-end system that is tightly

integrated with existing MVD 2.0 System, but is easily
configurable to integrate with any future systems that MVD may
build or purchase.
Tech. Objective 2 Successfully implement a POS system that will easily and
accurately reconcile and distribute MVD fees.
Tech. Objective 3 Purchase and install hardware that will allow MVD and Tax field
offices to accept credit cards and allow local reconciliation.
PAGE | 10
3.2 PROJECT EXCLUSIONS
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
QUALITY METRICS The project schedule, assigned tasks, resources and milestones are met.
1
QUALITY METRICS TRD resources: TRD must provide adequate technical staffing and system
2 resources for a timely and successful implementation of POS.
QUALITY METRICS Project does not exceed budget.

3
QUALITY METRICS System is secure, operable and stable

4
QUALITY METRICS Staff is adequately trained

5
QUALITY METRICS Collecting fees and revenue distributions are accurate and produced in
6 a timely manner
QUALITY METRICS Field offices operate more efficiently leading to improved customer
7 satisfaction
4.0 PROJECT DELIVERABLES AND METHODOLOGY
4.1 PROJECT MANAGEMENT LIFE CYCLE
Phase Summary of Phase Key Deliverables

Initiating Main elements include: Project Charter, Project Scope,
Authorize the project; Commit Business Requirements,
organization to project or phase; Assumptions, Constraints,
Set the overall direction; Define
top-level project objectives;
Secure necessary approvals and
PAGE | 11
resources; Assign Project

Manger; Integration
Management.
Planning Main elements include: Define Project Plan, Critical success

Project scope; Refine Project factors, Work Break Down
objectives; define all required Structures, Project Schedule
deliverables; Create frame for
project schedule; Provide forum
for information sharing between
project team members; Define all
required activities; Identify
required skills and resources;
Estimate work effort; Risk
analysis and avoidance; Define
and estimate all required costs;
Obtain project funding approval;
Communication Plan.
Executing Main elements include: Actual efforts, Project

Coordinate the resources, team deliverables completion
development; Quality Assurance;
Select subcontractors; Distribute
Information; Work the plan.
Controlling Main elements include: Manage Performance status reports,

team, stakeholders and Corrective Actions, Measurement
subcontractors; Measure progress Metrics, Plan Change Request,
and monitor performance Product Change Request, Risk
(overall, scope, schedule, costs Management, Issues
and quality); Take corrective Management
action if needed; Change request
Management; Risk Management;
Performance reports and
Communications.
Closing Main elements include: Finalize Deliverable Acceptance, Lessons

activities; Administrative close Learned
out (gather, distribute, archive
information to formalize project
completion, acceptance/signoff,
evaluation, member, appraisals,
lessons learned); Contract close
out (completion of the project
contract including resolution of
open items and final formal
acceptance)
PAGE | 12
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 Planning Documents

Description – The Project Management Plan Deliverable Acceptance Criteria –POS Executive
represents the project team’s plans for the Steering Committee (ESC) approval and DoIT
acquisition, installation, testing and implementation approval
of the POS solution. It is a working document. It
will be modified and updated (under revision Standards for Content and Format – The State
control) as the project team learns more about the PMO provides templates for content. The standard
project, brings on support vendors and responds to is based on the Project Management Institute’s
changing or evolving conditions. (PMI) Project Management Body of Knowledge
(PMBOK)
Quality Review – Review by POS ESC, the State

PMO and PCC
4.1.1.2 Project Management & Control Functions

Description – Integrated Project Control Process, Deliverable Acceptance Criteria – POS ESC
Change Control Process, Risk Management Plan,
Internal Project Communication Plan, Quality Standards for Content and Format –The
Management Plan, Issue Management Process and standard is based on the Project Management
the IV&V Plan. These are sections in the POS Institute’s (PMI) Project Management Body of
Project Manual. Knowledge (PMBOK)
Quality Review – Review by POS ESC, the State

PMO and PCC
4.1.1.3 Procure POS solution (RFP Process)

Description – Procuring the POS (the RFP Deliverable Acceptance Criteria – POS ESC
process) is estimated to require two months at the approval, signature approval by Purchasing, Legal
least. After the RFP is written, State Purchasing, and the State CIO approval
the General Council & DoIT must approve it. Then
the following steps and timeframes are required: Standards for Content and Format – The
contracts follow New Mexico standards for
 RFP must be open for proposals – 30 days
professional services contracts
 Review proposals & decide - - - - - 30 days
 Contract negotiations - - - - - - - - - 30 days Quality Review – POS ESC
 Contract Approval - - - - - - - - - 30 days.
PAGE | 13
4.1.1.4 Project Resource Management

Description – Recruit and hire project labor Deliverable Acceptance Criteria – POS ESC
resources to include, a Project Manager, and approval, signature approval by Purchasing, Legal
IV&V services vendor. Specific Deliverables and the State CIO
include:
Standards for Content and Format – The
o Project Manager Price Agreement contracts follow New Mexico standards for
o IV&V Price Agreement. professional services contracts
Quality Review – POS ESC
PAGE | 14
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) Project Director on
behalf of Executive
Steering Committee
PRJ-DEL-002 IV&V Contract & Reports Project Director on

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

behalf of Executive
Steering Committee
PRJ-DEL-004 Risk Assessment and management Project Director on

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

behalf of Executive
Steering Committee
PRJ-DEL-006 Monthly Project Status Reports to Project Director on

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

behalf of Executive
Steering Committee
PRJ-DEL-008 Hardware configuration and Project Director on

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

behalf of Executive
Steering Committee
PRJ-DEL-010 Implementation services Project Director on

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

behalf of Executive
Steering Committee
PAGE | 15

PRJ-DEL-012 Close out reports and documentation Project Director on
behalf of Executive
Steering Committee
4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE
The Project Director shall present the deliverables along with a recommendation for approval to the
Executive Steering Committee during a regularly scheduled steering committee meeting. The Executive
Steering Committee must then vote to accept or reject the deliverable with the vote reflecting a majority
decision.
If the deliverable is rejected, the Project Director must inform the vendor submitting the deliverable of the
committee’s action and must also identify, in writing, why the deliverable was rejected, and what actions
must be addressed by the vendor before the deliverable is presented for acceptance again.
4.2 PRODUCT LIFE CYCLE

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

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

deliver design documents for
authentication, reporting, and the
database feeds.
Executing The system will be open SYSTEMS ARCHITECTURE

architecture and be certified on
standard operating platforms –
Windows or Unix. Architecture
will be scalable to allow for
growth, provide interoperability
PAGE | 16
with other systems, have a secure

web front end, be security rules
based and provide multiple
security layers for user
authentication.
Executing Users will test system SYSTEM AND USER

functionality, performance, ACCEPTANCE TESTING
reporting accuracy and response
times.
IT Technical Support Staff will
test system operational
performance.
Executing The Vendor will be required to OPERATIONS

deliver design documents for REQUIREMENTS
authentication, Reporting, and
the Database feeds.
4.2.1 TECHNICAL STRATEGY

Developing a project strategy is a process of choosing an approach to the work that maximizes strengths,
minimizes weaknesses, takes advantage of opportunities and mitigates threats while balancing the
anticipated cost and potential benefit. A good strategy will minimize risk while maximizing return on
investment.
The strategic direction is to select and implement a Point of Sale (POS) solution using a Commercial-Off-
the-Shelf (COTS) software product that has demonstrated its effectiveness in the marketplace. Using a
package strategy rather than a custom development strategy has been proven effective in many situations,
and is a common strategy in both the private and public sectors.
A package strategy however, is not without its own risks. As a whole, the Information Technology (IT)
industry has found the implementation of Enterprise Resource Planning (ERP), Customer Relationship
Management (CRM), Supply Chain Management (SCM) and other large-scale automation packages to be
very difficult in many situations. Many of the high profile IT project disasters documented by the IT
trade press over the years have involved the implementation of software packages. The question then is
how to take advantage of a software package strategy while avoiding the potential pitfalls that have
plagued so many other package implementations over the years?
The project strategy is based on the strategic direction established by the TRD POS Executive Steering
Committee, and the lessons learned from others in the Information Technology industry that have
implemented package software.
PAGE | 17
4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES
4.2.2.1 – Hire Project Manager
Description – Develop and Deliverable Acceptance Criteria – Approval of contract and

execute contract for Project deliverables from management and DoIT
Manger
Standards for Content and Format – DoIT contract template
Quality Review – Review and acceptance from management and

DoIT.
4.2.2.2 Hardware proof of concept
Description – Perform proof of Deliverable Acceptance Criteria – Design specifications will be

concept for POS hardware reviewed and accepted by TRD/ITD and MVD Project Managers.
Standards for Content and Format – MS Word and design

specifications,
Quality Review – Team peer review and Project Manager

acceptance.
4.2.2.3 Issue RFP
Description – Issue two separate Deliverable Acceptance Criteria – Approval of RFP by

RFPs; one for equipment and a management, DoIT and State Purchasing.
second for POS COTS System.
Standards for Content and Format - MS Word, MVD business
requirements.
Quality Review – ITD and MVD management review and

Project Manager acceptance.
4.2.2.4 Purchase POS Hardware
Description – Purchase Hardware Deliverable Acceptance Criteria – Acceptance and delivery of

hardware
Standards for Content and Format – Purchase Requisition
Quality Review – ITD and MVD management review and

Project Manager acceptance.
4.2.2.5 Implement POS in TRD
PAGE | 18
Description – Implement POS Deliverable Acceptance Criteria – Acceptance of system

System in TRD through User Acceptance Testing.
Standards for Content and Format – MS Word, design

specifications and PMP.
Quality Review – ITD and MVD management review, Project

Manager acceptance and IV &V.
4.2.3 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.

DEL-012 Project Charter Project Director on
behalf of Executive
Steering Committee
DEL-012 Certification Form Project Director on

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

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

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

behalf of Executive
Steering Committee
DEL-012 Risk Assessment and management Project Director on

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

behalf of Executive
Steering Committee
DEL-012 Monthly Project Status Reports to Project Director on

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

behalf of Executive
PAGE | 19

Steering Committee
4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

The Project Director shall present the deliverables along with a recommendation for approval to the
Executive Steering Committee during a regularly scheduled steering committee meeting. The Executive
Steering Committee must then vote to accept or reject the deliverable with the vote reflecting a majority
decision.
If the deliverable is rejected, the Project Director must inform the vendor submitting the deliverable of the
committee’s action and must also identify, in writing, why the deliverable was rejected, and what actions
must be addressed by the vendor before the deliverable is presented for acceptance again
PAGE | 20
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.
MVDPOS
Work Breakdown
Structure
Application Implementation
Requirements Acquisition Implementation Inventory Training
Deployment Testing
Technical Hardware & Hardware Process Integration Develop Test Plan Documentation
- Hardware Peripherals Software Management Configuration Conduct UAT User Training
- Software - Vendor Selection Communications Workflow Initial Testing Test Reporting
- Network - Purchase Preliminary Testing Scanning
Business - Shipping
- integration Software
- Reporting - Vendor Selection
Staffing - Purchase
- Internal Resources
-External Resources
PAGE | 21
Identifier Work Package Description Definition/Objective Milestone/Deliverable
WBS-001 Requirements Define technical, business, Technical include:

and staffing requirements Hardware and peripherals;
POS COTS software;
MVD2.0 integration;
SHARE integration;
licensing requirements;
Network communications;
security; VPN; and
redundancy.
Business include: MVD

business rules; and
reporting requirements
Staffing requirements
include: MVD resource
identification and vendor
resource identification.
WBS-002 Acquisition Purchase hardware and Vendor selection and
software acquisition process.
WBS-003 Implementation Install hardware and Hardware installation
software including; rack installation
if required,
Software installation;
Operating systems for
servers; database
installation; configure
redundancy; and install
applications.
WBS-004 Inventory Add MVD products and Configure POS software to
services to POS software incorporate every product
and services as a POS
inventory item.
WBS-005 Application Deployment Application code Develop coding for
development for systems integration.
integration and Configure systems, initial
configuration testing by development
staff and handover to
operations staff.
WBS-006 Implementation/Testing Testing hardware and Development of Test Plan,
software develop test cases, conduct
User Acceptance Testing,
reconciliation of fees and
revenue, and validate
reports.
WBS-007 Training Conduct Training Develop documentation
for users, and support
personnel. Conduct
training of field office
personnel.
PAGE | 22
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE
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
WBS-001 – Consulting Services $276,000

WBS007
WBS-001 – Hardware $1,000,000
WBS007
WBS-001 – Software $1,176,500
WBS007
TOTALS $2,452,500
PAGE | 23
5.4 PROJECT TEAM

5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE
Executive Sponsor Rand Tilton

Rick Homans MVD Project Manager
Toby Williams
MVD Bureau Chief
Rick Homans
Josie Ortiz
TRD Cabinet
MVD Bureau Chief
Secretary
Bill Allemand
Dona Cook MVD FO Manager
TRD Deputy Business Owner
Secretary Ken Ortiz Mac Lewid
MVD Policy & Procedure
Ken Ortiz
MVD Director Megan McCawley-Rivera
MVD Trainer
Alicia Ortiz
Deputy MVD
Director
IT Technical Team Lead/
Joel Matek
Project Director MVD Business Owners
TRD CIO
Joel Matek
Executive Steering Committee
Lee Baca
MVD Applications
Development Manager
Project Manager
John Salazar Sailam Vasudevan
Lead IT Developer
Venkat Dodda
IT Developer
Tirumal Rao,
IT Developer
Feng He
IT Developer
Rama Bandapelli
IT Developer
Rao Chad
DBA
IT Technical Team
PAGE | 24
5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES

The State Department of Information Technology (DOIT) will provide project management oversight
and the TRD POS Executive Steering Committee will provide strategic direction for the project.
The TRD POS Executive Steering Committee (ESC) provides strategic, high-level guidance with regard
to procedures, progress, and risks. The Steering Committee is charged with taking a department view to
ensure this project supports the delivery of an enterprise/department model. The project team reports
status and progress to the Steering Committee on a regular basis. The TRD POS ESC will also review,
and approve deliverables, monitor the activities of the Project Team, assure adherence to the project plan
and ensure involvement of participants in order to meet deadlines.
The TRD POS project team will handle the day-to-day tasks and decisions brought to the attention of the
Steering Committee. The workgroup is comprised of staff members from the the MVD Business Owners
and the IT Technical Team. Tasks performed by these two teams include: project management and
planning, analyzing requirements, data gap analysis and data mapping, making program specific
decisions, helping determine the system and operational processes, business process reengineering,
training and deployment.
The Department of Information Technology Office will provide increased emphasis on strategic
information technology planning and management. This ensures the proper and efficient administration of
all Information Technology projects in the state.
Resources are to be contracted through the competitive vendor request (CVR) process to implement
IV&V.
Given in the table below are the roles and responsibilities of each of the team members.
PAGE | 25
Role Responsibilities
 Meet at least once monthly
Executive Steering
 Provide strategic direction and promote the vision for Point of Sale
Committee (ESC)
 Advise project on policy issues
 Review, evaluate, and provide direction to the Project Director and Project
Team Members on implementation and deployment strategies
 Monitor the project progress
 Provide recommendations on issues escalated to the committee
 Assist in mitigating strategic project risks
 Direct the Project Director on issues and risks
 Address, review, and approve all deliverables, such as project structure and
team activities
 Monitor the project activities, assuring adherence to the project plan
 Ensure involvement of participants in order to meet deadlines
 Review and approve expenditures of funds
 Represent the point of view of key stakeholders including technology-
enabled customers and state government executives
 Provide project implementation oversight
NM DOIT
 Ensure proper project management and cost reporting
 Certify and approve funding prior to each phase of the project
 Report to ESC on project status, issues, budget, and activities
Project
 Address, review, and submit deliverables to ESC from the TRD Project
Director/Project
Team members
Manager
 Prepare Steering Committee meeting agenda and meeting materials
 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 POS selection criteria
 Procure hardware and software for POS
 Comply with approved IT Infrastructure policies & procedures
 Plan system interfaces and document migration processes
 Manage testing and validating for POS solution
 Provide contract and Vendor oversight
 Assure Vendor deliverables meet the business & system requirements
 Monitor the project and contract to ensure delivery of complete, accepted
deliverables on schedule
 Serve as a contact for the Vendor Team Manager, review and accept
weekly status reports, project milestones, deliverables, and issues logs
 Advise the Vendor Team(s) on issues and risks
 Review and approve all Vendor documentation
 Document Point of Sale Model
PAGE | 26
Role Responsibilities
 Provide subject matter expertise for MVD business requirements
MVD Business
 Participate in workgroups and status meetings to determine best course of
Owners Team
action, options, and alternatives
Members
 Review ITC PCC documentation for certification
 Participate in developing POS selection criteria
 Make recommendations to POS Project Director concerning the project
deliverables
 Assist with project coordination and issues where escalation is necessary
 Review Vendor deliverables and participate in test walk-through
 Approve and sign off on project documentation
 Work closely with Project Director to create an approved, published point-
of-sale framework
 Participate in Hosting Strategy Development
IT Team Members
 Support installation of hardware and technology infrastructure
 Develop applications as required
 Perform installation of hardware and software
 Configure hardware and software
 Provide IT subject matter expertise
IT Specialists System
 Work with Project Director to determine hardware, software, network and
Administrators,
technical requirements.
System Experts and
 Work with Project Director to define technical system interface
Developers
requirements.
 Provide IT perspective and guidance for technology issues
 Ensure compliance with the Contract and the approved work plan.
Vendor(s)
 Develop and submit all deliverables as required by the Contract.
 Meet the Project schedule and milestones as defined in the Work Plan and
the Contract.
List the team members, their role, responsibility and functional manager. Make sure to include a
comprehensive listing including those from the organization managing the project, business members
involved to ensure business objectives are met and the vendor members that may have a specific role.
ROLE RESPONSIBILITY NAME FUNCTIONAL AREA

CABINET PROGRAM FINANCIAL RICK HOMANS TAXATION AND
SECRETARY RESPONSIBILITY REVENUE
DEPARTMENT
(TRD)
DEPUTY PROGRAM FINANCIAL DONA COOK TAXATION AND
CABINET RESPONSIBILITY REVENUE
SECRETARY DEPARTMENT
(TRD)
MVD DIRECTOR PROGRAM KEN ORTIZ TRD, MOTOR
ADMINISTRATION VEHICLE
RESPONSIBILITY DIVISION
PAGE | 27
ROLE RESPONSIBILITY NAME FUNCTIONAL AREA

MVD DEPUTY PROGRAM ALICIA ORTIZ TRD, MOTOR
DIRECTOR ADMINISTRATION VEHICLE
RESPONSIBILITY DIVISION
CHIEF IT INFRASTRUCUTRE JOEL MATEK TRD,
INFORMATION INFORMATION
OFFICER TECHN OLOGY
DIVISION
IT MANAGER MVD APPLICATIONS LEE BACA TRD,
DEVELOPMENT INFORMATION
TECHN OLOGY
DIVISION
BUREAU CHIEF MVD POLICY AND MAC LEWIS TRD, MOTOR
PROCEDURE VEHICLE
DIVISION
BUREAU CHIEF MVD FIELD OFFICE TOBY WILLIAMS TRD, MOTOR
OPERATIONS VEHICLE
DIVISION
BUREAU CHIEF MVD FIELD OFFICE JOSIE ORTIZ TRD, MOTOR
OPERATIONS VEHICLE
DIVISION
TRAINING MVD TRAINING MEGAN TRD, MOTOR
MANAGER MCCAWLEY- VEHICLE
RIVERA DIVISION
Application TECHNICAL SUPPORT OF TRD IT TECHNOLOGY

Developer, SYSTEMS TECHNOLOGY AND AND SYSTEM
Database SYSTEM SUPPORT SUPPORT
Administration,
System
Administration
5.5 STAFF PLANNING AND RESOURCE ACQUISITION

Complete the chart below identifying the project team members and details concerning their project
commitment. Project staff should include State, Contract, Customer (Business Owner), or Vendor team
members
PAGE | 28
5.5.1 PROJECT STAFF

Cost Estimated Availabili Work
Resource Estimate Hours ty Skill Set Product/Deliverable
Project Manger 160,000 2000 Full-time Project All
Manager
IT Project Staff 500,000 2000 As-needed IT expert All
MVD Business Owners 500,000 2000 As-needed MVD All
experts
PAGE | 29
5.5.2 NON-PERSONNEL RESOURCES

Use this section to list services or product (HW/SW and such) needed for project
Estimated
Cost units/hour Availabili Work
Resource Estimate s ty Source Product/Deliverable
POS Hardware 1,000,000 300 POS TBD Hardware
workstatio
ns
POS Software 1,500,000 300 client TBD Software
5.6 PROJECT LOGISTICS

Logistics describes how the project manager, project team, the business owner/customer and any vendor
resources will physically work together. Include anything to do with moving or starting resources.
Training specifically related to project team members should be included here.
5.6.1 PROJECT TEAM TRAINING
Describe training if any needed by project team members. This is not to include training for end users,
system administrators or business owners; those should be handled within a training document or part of
the transition to operations planning.
Cost Estimated
Resource Estimate Hours Availability Skill Set Work Product/Deliverable
PAGE | 30
6.0 PROJECT MANAGEMENT AND CONTROLS
6.1 RISK AND ISSUE MANAGEMENT

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

Provide a detailed explanation on the strategy for how risks are identified, analyzed/ quantified, mitigated,
reported, escalated and tracked. Include the use of tools such as project management software, forms, and
templates. A separate risk management plan may also be developed if needed for the project and
included as an Appendix to this document. If that is the case, a high level summary of this plan needs to
be included here with the specific reference.
The best way to deal with a large amount of data/information is to categorize it in such a way to begin
understanding the relationships between the data and start to see structure. The Software Engineering
Institute (SEI) has developed a Taxonomy of Software Project Risk that offers a way to systematically
think about the potential risks that are faced by software development/implementation projects. This
taxonomy is used to stimulate thinking about the potential risks that the POS project may face. To ease
the documentation and tracking of identified risks, a risk evaluation tool is used, built with an excel
spreadsheet that was originally provided by TRD. This is the primary tool to be used to list and
categorize POS project risks. The Risk Analysis is shown in Appendix D. The sequence of activity is as
follows:
1. Risk Identification – The process of identifying potential risks and documenting the specific
characteristics of each.
2. Risk Analysis – The process of determining the impact and likelihood of the identified risks.
This process may employ both qualitative and quantitative techniques as deemed necessary to
objectively evaluate potential risks to the project.
3. Risk Mitigation – The process of mitigating the possibility of the risk and assigning responsible
individuals to identified risks. All identified risks will have appropriate mitigation
strategies/plans. For those risks that are highly probable and have, significant impact to the
project will develop contingency plans.
4. Risk Monitoring and Control – The process of tracking, evaluating and responding to ongoing
developments relative to project plans, risk mitigation plans and specific contingency plans. Risk
management is an integral component of integrated project control. This is an ongoing process
for the duration of the project and will be part of every project status meeting.
PAGE | 31
Risk identification is the responsibility of all members of the project team. The Project Director and
Project Manager are responsible for tracking risks and for developing mitigation strategies and
contingency plans that address the risks identified by the team.
The POS project will follow a continuous risk management strategy. Risk will be assessed routinely to
ensure that identified risks are being dealt with appropriately and that new risks are identified and dealt
with as early as possible
6.1.6 ISSUE MANAGEMENT
6.1.6.1 Internal Issue Escalation and Resolution Process

With any project, no matter how comprehensive the planning process, issues arise that need to be
addressed. This section of the project manual addresses how this process will be managed for the POS
project.
When the project team identifies an issue, it will be added to a document called POS Project Issues.doc
stored in the project library. An issue can also be identified by anyone affiliated with the project although
the project team will be primarily responsible for tracking issues through to resolution. The project team
will review the issues list twice a month. Issues, which could negatively affect the project, will be
brought to POS ESC attention according to the change control process in section 7.4. The process of
tracking an issue is outlined here:
1) An issue is identified.
2) It is added to the issue document, assigned an issue number with a brief explanation of the issue
and date entered.
3) The issue is assigned to someone and potential action to be taken.
4) As action is taken, it is noted with the issue.
5) If possible, an estimated completion date is entered.
6) Upon completion of an issue, the actual completion date is noted with the resolution.
Listed below are examples of how an issue can be resolved:
 An issue can become a task added to the project plan with proper approval, if new, or within
scope of the project. See section 7.2 and 7.4 for further details of these processes.
 It could be resolved by an action taken.
 A document can be created which addresses the issue.
 A resolution could create new issues that need to be addressed.
 A new policy could be created which addresses the issue.
The project team is primarily responsible to resolve issues or follow-up to be sure action is being taken to
resolve an issue.
PAGE | 32
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 Division that is responsible for managing the project
without affecting the overall project schedule, cost, or quality. POS project will log internal and external
issues as stated in format 6.1.6.1 in order for all issues to be documented in a formal process. The
mitigation process for resolving external issues will depend on contract terms and requirements agreed to
by the Agency and external vendors.
6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V
INDEPENDENT VERIFICATION AND VALIDATION (IV&V) IS A RISK MITIGATION STRATEGY DESIGNED TO

PROVIDE MANAGEMENT WITH PROJECT OVERSIGHT THROUGH AN INDEPENDENT EVALUATION OF A
PROJECT’S PRODUCT AND PROCESS QUALITY. THE POS PROJECT HAS ADOPTED A LOW RISK
IMPLEMENTATION STRATEGY BY USING A PACKAGE SOLUTION THAT IS CURRENTLY IMPLEMENTED IN
MULTIPLE COMMERCIAL AND GOVERNMENT SITES. GIVEN THAT THE PROJECT HAS ADOPTED A PACKAGE
SOLUTION STRATEGY, ITS IV&V PLAN WILL BE TAILORED TO ADDRESS THE UNIQUE RISKS ASSOCIATED
WITH PACKAGE IMPLEMENTATION PROJECTS.
The IV&V plan will:
 Evaluate and verify that processes, contracts, and system designs comply
with the specified requirements of the Enterprise Architecture and
Standards
 Evaluate and validate that products and deliverables of a given
development phase fulfill the requirements and performance outcomes set
forth in the scope and project plan
 Provide a “close-out” report to the Executive Board at the end of project.
A Competitive Vendor Request (CVR) will be submitted to the TRD POS Executive Steering Committee
for approval. Once the CVR has been approved, the project team will initiate contact with approved
IV&V vendors. The IV&V vendor will develop a complete IV&V plan in conjunction with the project
team.
6.3 SCOPE MANAGEMENT PLAN
PROJECT CONTROL IS THE MECHANISM BY WHICH THE PROJECT DIRECTOR IN CONJUNCTION WITH THE
PROJECT TEAM ASSESSES PROGRESS RELATIVE TO THE PROJECT PLAN. THE PROJECT CONTROL PROCESS IS
IMPLEMENTED THROUGH A WEEKLY PROJECT STATUS MEETING. THE MEETING WILL BE DESIGNED TO
IDENTIFY VARIANCES FROM THE PROJECT PLAN AND TO IDENTIFY AND INITIATE CORRECTIVE ACTIONS
WHERE APPROPRIATE.
PAGE | 33
 Cost Control –The project director maintains a copy of the current budget and is to notify TRD of
budget variances as they are identified.
 Schedule Control – The project team is responsible for establishing and maintaining a project
schedule. The project team will assess the current project schedule status and report variances as
they are identified. Additionally, the team will identify and implement the appropriate corrective
actions to eliminate or minimize schedule variances.
 Scope Control – The project scope is defined and documented in the Section 3 of this document.
The detailed scope definition contained in Section 3 will be used to evaluate project scope issues.
Significant variances from scope will be submitted to a formal project change control mechanism
(Section 7.4 Change Control Process).
 Quality Management – TRD POS project quality management will be established for each
deliverable based on the quality mechanisms of the responsible organization, and the TRD POS
Quality Management Plan (Section 6.7) of this document.
 Risk Management – Risk management is an ongoing process of identification and assessment.
Risk Assessment is included as part of the routine status process of the project. This maintains an
awareness of risk and the associated risk assessment and monitoring tasks required to manage the
project effectively.
These five parameters of the project are integrally linked and any significant change in one will likely
cause changes in the others. Project control establishes the mechanism to routinely track and report on
these parameters. If issues arise that result in significant variances in these parameters, the project team
will prepare and submit a Project Change Request form through the Project Change Control process.
The process below is designed to capture project status information on a weekly basis. The information is
then used to trigger corrective action, risk mitigation and a variety of reporting processes. This process is
critical to successful project communication and is the foundation on which a successful project control
system will be built. The process should allow for flexibility in dealing with project control issues while
ensuring that project status information is captured and documented.
6.3.1 CHANGE CONTROL
6.3.1.1 Change Control Process

Change Control establishes how change will be managed, including capturing, tracking, communicating,
and resolving change. Due to much ambiguity regarding change, it is vital that we document and discuss
the change process with the executive sponsor.
6.3.1.2 Change Control Board (CCB)

A formal change control process is an essential component of a successful IT project. The key to
controlling project change, is managing the impact to the project plan, budget, and implementation
schedule.
Some changes are unavoidable – instances where changes have to be made to comply with legal,
federal/state regulations, policy changes, compliance with changes in the business direction of the
PAGE | 34
enterprise, or where technology may dictate change. Other non-essential changes can be avoided through
management of a formal change control process.
Scope changes (sometimes referred to as scope creep) are the continual addition of functional
enhancements to the product requirements throughout the project life cycle. Excessive scope changes are
directly related to poorly defined product requirements and specifications. A well thought out change
control process will assist the project management team in controlling “scope creep”.
Three (3) steps are necessary to control scope changes:
1. Establish the baseline product.

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

The POS project plan is developed around a “package” strategy. Further, the strategy specifically
specifies minimal modifications to the package. No functional modifications are to be made to the
selected POS product. The package plus the Work Breakdown Structure and product descriptions in
section 5.1 of this document represents the baseline product and therefore the criteria for determining the
approved scope.
Agreement from the POS ESC
The baseline product described above and strategy for implementation is to be reviewed and approved by
the POS Executive Steering Committee. Requests to change the scope will also be reviewed and
approved by the POS ESC.
Enforce a formal change control process
The software package/implementation process is never static. Some changes are to be expected during
the POS implementation, and a formal process has been defined and is to be followed to make sure all
changes to the product are made in an orderly manner. As scope change requests are made, a change
control process ensures
 Only necessary changes are made,

 Changes are communicated to all affected parties, and
PAGE | 35
Changes are implemented in an orderly fashion

MVDPOS Project
Integrated Control Process
Emerging
Issues &
Risks
Cost
Baseline
Baseline Weekly Schedule Current
MVDPOS plan
Plan Status Process Scope Status
Quality
Status
Weekly Status
Report
Corrective
Yes Action
Required ?
MVDPOS
Corrective Action
Document
Planning Process
Archive
- - Website -
Revised - No -
Plans Weekly
Continue Status
Planned Information
Does Work
Corrective Cost
Yes Action Exceed Schedule
Change Request Authorized Scope
Form Variance ? Quality
Change Control
Process - No - Project Work
Revised
Plans
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
PAGE | 36
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).
6.4.1 BUDGET TRACKING

The Motor Vehicle Division’s Budget Bureau will be responsible for managing the POS budget, and will
be a member of the POS Executive Steering Committee. The budget bureau employee will provide a
budget update at each Steering Committee Meeting, identifying past expenditures, encumbrances, future
encumbrances, personnel costs, and any other expense associated with the project budget.
6.5 COMMUNICATION 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.
Communication is fundamental to effective project management. The Communications Plan outlines the
roles and responsibilities of participants in the dissemination, review and approval of project information.
A communications plan that is well implemented will help manage expectations of the project, assure
appropriate levels of communication with internal and external project stakeholders, provide relevant,
accurate, consistent information at all times and help generate and sustain enthusiasm and support for the
project.
The communication strategy covers all the informational needs of the project stakeholder community.
Many will receive routine information about the project. Others will be able to visit the project website
and obtain the specific information that they are seeking and all may receive ad hoc communication from
the project team at any time depending on the need.
The Executive Steering Committee will meet at a minimum on a monthly basis in order to review project
progress, deliverables/milestones, provide direction to the Project Director, and team. The Project
Director is required to provide formal status reports to the ESC and will present the report during the ESC
meetings. The Project Director is also required to report on the overall status of the project on a monthly
basis, per standard DoIT procedures.
Specific requests for expenditure authorization should be forwarded to the ESC representatives for the
agencies. If funding approval is an agenda item on the regular ESC meeting, the request and associated
justification for spending should be circulated to committee members at least seven (7) days in advance of
the ESC meeting. If funding approval is required in a timeframe that does not coincide with the ESC
meeting schedule, it is the responsibility of the Project Director to send a request and justification directly
to the ESC committee members. A reminder notice should be sent out after seven (7) days if there has
been no response from ESC committee members. A final attempt to contact ESC members should be
made at fourteen (14) days if there has been no response. Summary of any such action should be
documented in team status reports and reported to the ESC at the next meeting.
PAGE | 37
6.5.1 COMMUNICATION MATRIX

Stakeholders (PD = Project Director, PM = Project Manager)
Deliverable/Description Target Delivery Frequency Responsible
Audience Method Party
POS Project Status TRD CIO Face-to-Face Weekly POS PM
POS Project Status TRD Team Face-to-Face As needed PD/PM
POS Project Status POS ESC Email 2nd & 4th Mon PD/PM
POS ESC Meeting POS ESC Face-to-Face 2nd & 4th Weds. PD/PM
POS ESC Meeting Minutes POS ESC Email 2nd & 4th Fri. PM
DOIT POS Project Status DOIT Email Monthly PM
Project Web Page As needed Web Page As needed PM Team
Ad hoc As needed As needed As needed As needed
6.5.2 STATUS MEETINGS

See above Matrix.
6.5.3 PROJECT STATUS REPORTS

See above Matrix.
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 | 38
6.6.1 BASELINES
Project Area Category Measure
Schedule Time Is project on schedule
Budget Costs Are project deliverables within

budget
Quality Has testing results matched

expectations
6.6.2 METRICS LIBRARY
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
Describe the agency, industry or regulatory project performance standards that will be followed and
assessed by the project. These quality standards will be used to assess whether the quality objectives were
achieved.
Identify each of the project quality standards that are directly related to the project and not to the
performance of the actual product and/or service. For each quality standard, identify the tracking tool or
measure such as number of project reviews or Project Status.
No. Quality Standard Tracking Tool or Measure
1 • Project Management
The project schedule, assigned tasks, resources and milestones Plan comparing
are met. estimated to actuals
2 • Project Management
TRD resources: TRD must provide adequate technical staffing Plan tracking tasks
and system resources for a timely and successful implementation to resources
of POS.
3 • Project budget
Project does not exceed budget.
4 • UAT results
System is secure, operable and stable
5 • User lessons learned

Staff is adequately trained
PAGE | 39
No. Quality Standard Tracking Tool or Measure
6 • Independent Audit
Collecting fees and revenue distributions are accurate and by Tax Fraud
produced in a timely manner Division
7 • MVD Bureau chiefs
Field offices operate more efficiently leading to improved comparing wait-
customer satisfaction times before POS,
and After POS
6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS
Quality
Review Type Tools Reviewer Reports
Standard
Requirements
Plans
Milestones
Testing
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
Agency awareness Project Initiation Quarterly
Quality of communications Project Initiation Monthly
Manages project tasks Project Initiation Monthly
Productive Meetings Project Initiation Monthly
PAGE | 40
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.
Customer Acceptance
Deliverable Final Approval Process Criteria
Hardware Project Director recommends ESC grants final approval
approval to ESC
Software Project Director recommends ESC grants final approval
approval to ESC
UAT Project Director recommends ESC grants final approval
approval to ESC
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.
6.8.1 VERSION CONTROL

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

A project repository, consisting of a shared server with multiple folders and a project web site will be
developed by TRD IT staff members as a means to provide a central repository for all project
documentation and deliverables.
6.9 PROCUREMENT MANAGEMENT PLAN

All procurement for project goods and services must be performed under the guidance and direction of
New Mexico State Procurement Statues, which will be made available from the POS project website.
PAGE | 41
7. 0 PROJECT CLOSE
Project Close will always consist of administrative project activities and possibly contractual project
activities and an external vendor is employed. Completing both sets of activities is a mandatory step in
the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is
responsible for managing the project, such as lessons learned, recording the last hours against the project,
and providing transition for the staff to other assignments. Contractual activities meet the contractual
needs, such as executing a procurement audit and formal acceptance of the project work products.
7.1 ADMINISTRATIVE CLOSE

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

Contract close is similar to administrative close in that it involves product and process verification for
contract close.
PAGE | 42
APPENDIX A – WORK BREAKDOWN STRUCTURE
MVDPOS
Work Breakdown
Structure
Application Implementation
Requirements Acquisition Implementation Inventory Training
Deployment Testing
Technical Hardware & Hardware Process Integration Develop Test Plan Documentation
- Hardware Peripherals Software Management Configuration Conduct UAT User Training
- Software - Vendor Selection Communications Workflow Initial Testing Test Reporting
- Network - Purchase Preliminary Testing Scanning
Business - Shipping
- integration Software
- Reporting - Vendor Selection
Staffing - Purchase
- Internal Resources
-External Resources
PAGE | 43
APPENDIX B - PROJECT SCHEDULE/GANTT CHART

If you would like a current soft copy of the MS Project file, please send an email to
John.Salazar@state.nm.us
ID Task Name
October November
10/19 10/26 11/2 11/9
1 Develop POS strategy and research COTS applications John Salazar,Lee Baca,Rand Tilton
2 Identify COTS POS solution John Salazar,Lee Baca,Rand Tilton
3 Identify POS hardware configuration John Salazar,Lee Baca,Rand Tilt
4 Document existing application logic for MVD2.0 fee collection process John Salazar,Lee Baca,Rame
5 Document existing application logic for MVRO revenue distribution Ramesh Tavare,John
6 Acquire Microsoft POS (1 Headquarters License, 2 Office Licenses & 4 clerk register units) John Salazar,Rand Tilton
7 Acquire IBM SurPos 300 register equipment (4 registers) John Salaz
8 Install COTS Headquarter and Field Office software Nanda kumar
9 Install Register Hardware, POS Client Software and configure POS registers Justin Snee,Nand
10 Integrate POS security into MVD Active Directory Justin Snee,Na
11 Modify MVD2.0 Driver System to provide MVD transaction type to POS solution Venkat Dodda
12 Develop SOA Web Services to communicate with MVD2.0 and RMS POS solution for data exchange Ramesh Tavare
13 Develop process to handle multiple MVD transation into a single POS receipt Angel Martine
14 Develop COTS end-of-day clerk closing reports Katie Pache
15 Develop COTS end-of-day office closing reports Angel Mart
16 Develop COTS end-of-month distrubition reports Angel
17 Modify MVD 2.0 to accept fee schedule from POS solution via SOA Web Services Rao Tirumal,Venk
18 Develop process for generating receipts from POS solution Bill A
19 Develop process for creating daily distribution transactions Ang
20 Develop process for creating daily bank deposits
21 Develop process to interface fee collection from field offices to SHARE system
22 Develop reporting requirements for TRD Financial Services Bureau
23 Develop User Acceptance Testing Requirements
24 Conduct User Acceptance Testing
25 Document Prototype Results and Recommendations
PAGE | 44
APPENDIX C - PROJECT BUDGET

If you would like a current soft copy of the Project Budget, please send an email to
PAGE | 45
APPENDIX D - RISK ANALYSIS

For the most up to date POS Project Risk report, please email the TRD POS Project Manager at
John.Salazar@state.nm.us.
PAGE | 46
APPENDIX E - PROJECT LIBRARY

The project library is an electronic storage place where all documentation relating to the project is stored
and updated. TRD POS project website provides project specific information. See www.TRD
POS.state.nm.us . This is a single source of project information for all stakeholders. The website includes
Information:
 Project Objectives
 Project Organization
 Project Status
 Governance, including project status reports and meeting minutes
 Project Manual
 Project Background and Definitions
 POS Requirements Matrix
 POS Architecture Design
PAGE | 47
APPENDIX F - SAMPLE PROJECT FORMS

PROJECT CHANGE REQUEST FORM
This is the form to initiate the Change Control process.
Project Change Request
Project Name Date

Project Director Project Managers
AGENCY AND PROJECT INFORMATION

Requested by Date
Authorized by Date
DESCRIPTION
IMPACT Technical Schedule Cost Other
ACTION PLAN
Mark One This change Is Is Not within scope.

Mark One This change is Accepted Denied On Hold Delayed
ESC Approval
Signature
Name
Date
PAGE | 48
PROJECT STATUS REPORT

Please see the status reports on the website at www.TRD POS.state.nm.us under the Governance link, or
the Project Status link
PAGE | 49
SAMPLE ISSUES REPORT

For the most up to date POS Project Issues report, please email the TRD POS Project Manager at
PAGE | 50
APPENDIX G – TRD POS 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 Fibre Channel) that connect to the back end of local area network (LAN)
servers. They remove cumbersome storage functions from the server, thus improving overall
LAN and WAN performance. A typical SAN includes a blend of storage devices (such as
automated tape libraries or RAID) capable of communicating with multiple hosts and with each
other over a fast, fault-tolerant storage pipeline (the SAN). The SAN is actually a dedicated
storage access I/O channel (containing network properties) optimized for handling storage tasks.
“Website” means a presence on the internet or intranet containing information that represents an agency
or presents information on specific subjects or allows transactions to be conducted through the
use of links or web pages. A website is normally hosted and maintained by an agency or by
another entity sharing internet resource or through an internet service provider.
PAGE | 51
APPENDIX H – TRD POS PROJECT ACRONYMS
APD – Advance Planning Document

CIO – Chief Information Officer
CRM – Customer relationship management
DAM – Digital Asset Management
DFA – Department of Finance and Administration
DoIT – Department of Information Technology
ERP – Enterprise Resource Planning
ESC – Executive Steering Committee
IT – Information Technology
ITC – IT Commission, a State CIO sponsored commission
PD – Project director
PMBOK – Project Management Book of Knowledge
PMI – Project Management Institute
PT – Project team
RFP – Request for proposal
TRD – Taxation and Revenue Department
WBS – Work breakdown structure
PAGE | 52
APPENDIX P - 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
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
PAGE | 53
Critical Path is a series of activities that determines the duration of the project. The critical path usually
defined as those activities with float less than or equal to specified value often zero. It is the longest path
through the project.
Dependencies, Discretionary
Dependencies defined by the project management team. They should be used with care and usually
revolve around current Best Practices in a particular application area. They are sometimes referred to as
soft logic, preferred logic, or preferential logic. This may also encompass particular approaches because a
specific sequence of activities is preferred, but not mandatory in the project life cycle.
Dependencies, Mandatory
Dependencies inherent to the work being done. In some cases, they are referred to as hard logic.
Dependency Item
A product, action, piece of information, etc., that must be provided by one individual or group to a second
individual or group so they can perform a planned task.
Deliverable
Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project
or part of a project that is subject to approval by the project sponsor or customer.
Duration
The number of work periods (not including holidays or other nonworking periods) required to complete
an activity or other project element.
Duration Compression
Shortening the project schedule without reducing the project scope. Often increases the project cost.
End User
The individual or group who will use the system for its intended operational use when it is deployed in its
environment.
Effort
The number of labor units required to complete an activity or other project element, usually expressed as
staff hours, staff days, or staff weeks.
Fast Tracking
Compressing the project schedule by overlapping activities that would normally be done in sequence,
such as design and construction.
Float
The amount of time that an activity may be delayed from its early start without delaying the project
finished date.
Formal Review
A formal meeting at which a product is presented to the end user, customer, or other interested parties for
comment and approval. It can also be a review of the management and technical activities and of the
progress of the project.
Integrated Project Plan
A plan created by the project manager reflecting all approved projects and sub-projects.
PAGE | 54
Lessons Learned
The learning gained from the process of performing the project. Lessons learned may be identified at any
point during the execution of the project.
Method
Method is a reasonably complete set of rules and criteria that establish a precise and repeatable way of
performing a task and arriving at a desired result.
Methodology
A collection of methods, procedures, and standards that defines an integrated synthesis of engineering
approaches to the development of a product.
Milestone
A scheduled event for which some individual is accountable and that is used to measure progress.
Non-technical Requirements
Agreements, conditions, and/or contractual terms that affect and determine the management activities of
an architectural and software project.
Performance Reporting
Collecting and disseminating performance information. This includes status reporting measurement, and
forecasting.
Procurement Planning
Determining what to procure and when.
Product Scope
The features and functions that characterize a product or service.
Project Leader (Technical)
The leader of a technical team for a specific task, who has technical responsibility and provides technical
direction to the staff working on the task.
Project Management
The application of knowledge, skills, tools, and techniques to project activities to meet the project
requirements. Project Management is also responsible for the oversight of the development and delivery
of the architecture and software project.
Program
A group of related projects managed in a coordinated way. Programs include an element of ongoing
work.
Program Management Office
An organizational entity responsible for management and oversight of the organization’s projects. As a
specific reference in this document, the Office of the Chief Information Officer.
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.
PAGE | 55
Project Charter
A document issued by senior management that formally authorizes the existence of a project. It provides
the project manager with the authority to apply organizational resources to project activities.
Project Management Plan
A formal, approved document used to guide both project execution and project control. The primary uses
of the project plan are to document planning assumptions and decisions, facilitate communication among
stakeholders, and documents approved scope, cost, and schedule baselines. The Project Management Plan
(PMP) is a project plan.
Project Schedule
A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities
and for meeting milestones. Software products such as ABT’s Workbench and Microsoft Project are tools
used to develop project schedules.
Project Scope
The work that must be done to deliver a product with the specified features and functions.
Project Sponsor
The individual that provides the primary sponsorship for an approved project. This individual will play a
key role in securing funding, negotiating for resources, facilitating resolution of critical organizational
issues, and approving key project deliverables.
Quality
The degree to which a system, component, or process meets specified requirements.
The degree to which a system, component, or process meets customer or user needs or expectations.
[IEEE-STD-610]
Quality Management
The process of monitoring specific project results to determine id they comply with relevant standards
and identifying ways to eliminate causes of product non-compliance.
Risk
Possibility of suffering loss.
Risk Management
An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a
more accurate understanding of, the risks involved. Risk Management includes risk identification,
analysis, prioritization, and control. Risk mitigation seeks to reduce the probability and/ or impact of a
risk to below an acceptable threshold.
Risk Management Plan
The collection of plans that describes the Risk Management activities to be performed on a project.
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
PAGE | 56
The period of time that begins when a software product is conceived and ends when the software is no
longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase,
design phase, implementation phase, test phase, installation, and checkout phase, operation and
maintenance phase, and, sometimes, retirement phase.
Stakeholder
Individuals and organizations that are actively involved in the project, or whose interests may be
positively or negatively affected as a result of project execution or project completion. They may also
exert influence over the project and its results.
PAGE | 57

Project Management Plan (PMP)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management Plan (PMP)

Uploaded by

Copyright:

Available Formats

POINT-OF-SALE

PROJECT MANAGEMENT PLAN

EXECUTIVE SPONSOR – RICK HOMANS

REVISION HISTORY................................................................................................. III

REVISION: 3.0 DOIT-PMO-TEM-020 I OF VI

5.6.1 Project Team Training................................................................................................................................30

REVISION: 3.0 DOIT-PMO-TEM-020 II OF VI

REVISION NUMBER DATE COMMENT

REVISION: 3.0 DOIT-PMO-TEM-020 III OF VI

PREPARING THE PROJECT MANAGEMENT PLAN

ABOUT THIS DOCUMENT

Project Oversight Process Memorandum – DoIT, July 2007

6 “Product development life cycle” is a series of sequential, non-overlapping phases comprised

REVISION: 3.0 DOIT-PMO-TEM-020 IV OF VI

1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT

An IBM “Must Do Now” recommendation is for MVD to purchase a Commercial-Off-The-Shelf (COTS)

1.2 FUNDING AND SOURCES

SOURCE AMOUNT ASSOCIATED APPROVERS

NUMBE DESCRIPTION TYPE M,D,E

1 Identify, acquire, and configure vendor-provided COTS E

2 Identify, acquire, and configure vendor-provided POS E

3 Integration of POS hardware and software w/ MVD 2.0 M

4 Integration of COTS solution with SHARE for daily field M

5 Integration of COTS solution with SHARE for reconciliation M

6 Modify MVD2.0 to remove financial transaction business M

7 Development of a MVD Financial Transaction Engine Web M

8 Development of a Table Driven Fee Schedule for each type M

8 Configuration of POS COTS solution to add inventory items M

9 Successful Proof-of-Concept project M

1.6 INITIAL PROJECT RISKS IDENTIFIED

[Risk 3: COTS solution not available]

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

[Risk 5: User acceptance of POS hardware]

[Risk 6: Key project member departs]

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL

NAME STAKE IN PROJECT ORGANIZATION TITLE

DONA COOK PROGRAM FINANCIAL TAXATION AND DEPUTY

KEN ORTIZ PROGRAM ADMINISTRATION TRD, MOTOR MVD

ALICIA ORTIZ PROGRAM ADMINISTRATION TRD, MOTOR MVD

JOEL MATEK IT INFRASTRUCUTRE TRD, CHIEF

LEE BACA MVD APPLICATIONS TRD, IT

MAC LEWIS MVD POLICY AND PROCEDURE TRD, MOTOR BUREAU

NAME STAKE IN PROJECT ORGANIZATION TITLE

JOSIE ORTIZ MVD FIELD OFFICE OPERATIONS TRD, MOTOR BUREAU

MEGAN MVD TRAINING TRD, MOTOR TRAINING

TRD IT TECHNICAL SUPPORT OF TECHNOLOGY Application

JOHN SALAZAR PROJECT MANAGER CONTRACTOR Contract

2.2 PROJECT GOVERNANCE STRUCTURE

Executive Sponsor Rand Tilton

Executive Steering Committee

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

2.3 EXECUTIVE REPORTING

3.1 PROJECT OBJECTIVES

Bus. Objective 2 Reduce cost and complexity of Information Technology operations:

3.1.2 TECHNICAL OBJECTIVES

Tech. Objective 1 Successfully implement a POS front-end system that is tightly

3.2 PROJECT EXCLUSIONS

3.3 CRITICAL SUCCESS FACTORS

QUALITY METRICS Project does not exceed budget.

QUALITY METRICS System is secure, operable and stable

QUALITY METRICS Staff is adequately trained

4.0 PROJECT DELIVERABLES AND METHODOLOGY