Executive Sponsor(s) – Dianna J. Duran, Secretary of … Business... · Web view2015/05/27 · Executive Sponsor(s) – Dianna J. Duran, Secretary of State Mary quintana, Deputy

SOS BSOS BUSINESSUSINESS F FILINGILING S SYSTEMYSTEM P PROJECTROJECT

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

EXECUTIVE SPONSOR(S) – DIANNA J. DURAN, SECRETARY OF STATE

MARY QUINTANA, DEPUTY SECRETARY OF STATE

PROJECT SPONSOR – KEN ORTIZ, CHIEF OF STAFF

BUSINESS OWNERS – CHRISTINA ESPINOZA AND STACY STARR- GARCIA

BUSINESS SERVICES AND CORPORATIONS DIRECTORS

PROJECT MANAGER – JOHN SALAZAR, CSW ENTERPRISES

VENDOR PROJECT MANAGER – RAGHU CHANDRA, PCC TECHNOLOGY GROUP

VENDOR PROJECT EXECUTIVE – VISHAL HANJAN, PCC TECHNOLOGY GROUP

ORIGINAL PLAN DATE: MAY 7, 2013REVISION DATE: MAY 12, 2014

REVISION: 5 .0

PROJECT MANAGEMENT PLAN FOR SOS BUSINESS FILING SYSTEM PROJECT

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................................................................................................11.2 FUNDING AND SOURCES...........................................................................................................................................21.3 CONSTRAINTS....................................................................................................................................................21.4 DEPENDENCIES..............................................................................................................................................31.5 ASSUMPTIONS...............................................................................................................................................31.6 INITIAL PROJECT RISKS IDENTIFIED...........................................................................................................................4

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...........................................................................13

2.1 STAKEHOLDERS....................................................................................................................................................132.2 PROJECT GOVERNANCE STRUCTURE.........................................................................................................................16

2.2.1 Describe the organizational structure – Org Chart...................................................................................162.2.2 Describe the role and members of the project steering committee.........................................................172.2.3 Vendor Organizational Structure.............................................................................................................182.2.4 Organizational Boundaries, interfaces and responsibilities.....................................................................21

3.0 SCOPE......................................................................................................................................................... 21

3.1 PROJECT OBJECTIVES............................................................................................................................................213.1.1 Business Objectives..................................................................................................................................223.1.2 Technical Objectives................................................................................................................................22

3.2 PROJECT EXCLUSIONS............................................................................................................................................223.3 CRITICAL SUCCESS FACTORS...................................................................................................................................23

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................23

4.1 PROJECT MANAGEMENT LIFE CYCLE........................................................................................................................234.1.1 Project Management Deliverables...........................................................................................................244.1.2 Deliverable Approval Authority Designations..........................................................................................314.1.3 Deliverable Acceptance Procedure...........................................................................................................32

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................374.2.1 Technical Strategy...................................................................................................................................384.2.2 Product and Product Development Deliverables......................................................................................384.2.3 Deliverable Approval Authority Designations..........................................................................................634.2.4 Deliverable Acceptance Procedure...........................................................................................................66

5.0 PROJECT WORK........................................................................................................................................... 66

5.1 WORK BREAKDOWN STRUCTURE (WBS)..................................................................................................................665.4 PROJECT TEAM....................................................................................................................................................70

5.4.1 Project Team Organizational Structure....................................................................................................705.4.2 Project Team Roles and Responsibilities..................................................................................................71

5.5 STAFF PLANNING AND RESOURCE ACQUISITION................................................................................................735.5.1 Project Staff.............................................................................................................................................735.5.2 Non-Personnel resources.........................................................................................................................74

5.6 PROJECT LOGISTICS.........................................................................................................................................765.6.1 Project Team Training..............................................................................................................................76

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................77

REVISION: 2.0 i OF vi


6.1 RISK AND ISSUE MANAGEMENT..............................................................................................................................776.1.1 Risk Management Strategy......................................................................................................................776.1.2 Project Risk Identification........................................................................................................................786.1.3 Project Risk Mitigation Approach............................................................................................................786.1.4 Risk Reporting and Escalation Strategy...................................................................................................796.1.5 Project Risk Tracking Approach................................................................................................................806.1.6 ISSUE MANAGEMENT..............................................................................................................................81

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V...........................................................................................826.3 SCOPE MANAGEMENT PLAN..................................................................................................................................83

6.3.1 Change Control........................................................................................................................................836.4 PROJECT BUDGET MANAGEMENT............................................................................................................................86

6.4.1 Budget Tracking.......................................................................................................................................876.5 COMMUNICATION PLAN........................................................................................................................................87

6.5.1 Communication Matrix............................................................................................................................886.5.2 Status Meetings.......................................................................................................................................896.5.3 Project Status Reports..............................................................................................................................90

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................926.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................92

6.7.1 quality Standards.....................................................................................................................................936.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................956.7.3 Agency/Customer Satisfaction.................................................................................................................986.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................98

6.8 CONFIGURATION MANAGEMENT.................................................................................................................1016.8.1 Version Control......................................................................................................................................1016.8.2 Project Repository (Project Library).......................................................................................................103

7. 0 PROJECT CLOSE......................................................................................................................................... 104

7.1 Administrative Close.................................................................................................................................1047.2 Contract Close...........................................................................................................................................105

ATTACHMENTS................................................................................................................................................ 105

Acronyms and Abbreviations..........................................................................................................................107Definitions......................................................................................................................................................107

REVISION: 2.0 ii OF vi


REVISION HISTORYREVISION HISTORY

REVISION NUMBER DATE COMMENT

1.0 May 7, 2013 Initial PMP by SOS CIO

2.0 November 20, 2013 Updated by PM to include Implementation Phase

3.0 January 13, 2014 Updated by PCC PM1) Initial Project Risks Identified2) Stakeholders3) Role and Members of Steering Committee

Meeting4) Executive Reporting5) Deliverable Approval Authority

Designations6) Risk and Issue Management7) Communication Plan8) Change Control Process9) Quality Objectives and Control10) Vendor Organizational Structure

4.0 January 23, 2014 Jointly updated by SOS PM and PCC PM in order to incorporate feedback from IV&V vendor to strengthen documentation in the following areas:

1) Change Control Process2) Change Control Board3) Version Control4) Project Repository5) Glossary

5.0 May 12, 2015 Update PMP with current project dashboard information and contract amendment information.

REVISION: 2.0 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

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

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

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

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

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

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

REVISION: 2.0 iv OF vi


1.0 PROJECT OVERVIEW The Project Overview sets the stage for the details of the project and begins the story of the project and plan.

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The 15 year old Secretary of State’s Knowledgebase System (SOSKB) is running on obsolete hardware, is too old for successful equipment migration, has documented security vulnerabilities, and is currently at high risk of failing. The small IT staff is currently overburdened by reacting to problems in an overly complex and antiquated IT environment. System downtime and lost or inaccurate data is common due to the age, lack of system controls, and overall data integrity issues in the current systems. This puts the New Mexico Secretary of State’s Office (SOS) at risk of being unable to conduct its many daily statutory obligations.

Due to the constitutional amendment passed in the 2012 general election and the subsequent passing of House Bill 46 during the 2013 legislative session, the PRC Corporations Division will be moved into the SOS effective July 1, 2013. This will bring another silo type filing system under the umbrella of the SOS that is burdensome on both users and IT staff. The current system requires redundant key entry, manual business processes, and daily IT data fixes to keep it functioning.

The SOS was awarded $220,000 in FY 13 to complete a business requirements study to analyze and document all business processes, system requirements, statutory obligations, and record retention rules within the Business Services Division and the PRC Corporations Division. Using the requirements outlined during the assessment, an RFP will be issued in June 2013 for the Business Services Software Replacement Project, in order to purchase and implement a new integrated business filings software program.

The assessment completed during FY 13 documents many inefficient and manual processes, inconsistencies in the way documents are stored (i.e. paper, digital image, or microfilm), system errors, and double key entry in both the existing SOS and PRC systems. The volume of documents filed on a daily basis combined with the inefficiencies and bugs in the software currently utilized at PRC have resulted in a huge document backlog. CSW Enterprises, the vendor charged with completing the assessment, describes the systems running at SOS as being on borrowed time due to the inability to recover from a disaster due to the age of the systems.

The vision of the Secretary is that corporate filing transactions will be integrated into the Business Services Division creating a one-stop shop for all business filings within the office. The Business Services Software Replacement Project will utilize the $1.215 million awarded in FY 14 to purchase and implement a customizable COTS solution for capturing business filings maintained by the SOS Business Services Division and will support the one stop shop vision of the Secretary. This original request did not account for the additional expense of integrating the corporate filings into the scope of work. The RFP will be issued so that it encompasses all business filings, including corporate, to lay the foundation of creating an integrated system, though a future funding request might be necessary due to the expansion in the scope of work.

PAGE | 1


Version 2.0 PMP Update:

The SOS developed an RFP for a replacement centralized system based upon user defined requirements, and SOS technical expertise with hardware and software products. Additionally, research was performed to identify software products successfully implemented in other states. The RFP was published in July of this year and six companies submitted proposals. The RFP proposals were evaluated in August and September, with two companies identified as Finalists. These two companies were invited to perform oral presentations and to demonstrate the proposed software solution based on software workflow scenarios developed by the SOS. One of the two Finalists demonstrated a product that in most cases exceeded all SOS requirements. The SOS is currently moving towards awarding the contract to the top finalist based upon the RFP point structure.


The RFP was awarded to PCC Technologies, a vendor with a solid implementation history in two other states and with an existing software framework that meets the business and technical requirements of the Office of the New Mexico Secretary of State.

1.2 FUNDING AND SOURCES

SOURCE AMOUNT ASSOCIATED RESTRICTIONS

APPROVERS

C-2 GENERAL FUND

$1.215 HB-2 ENABLING LEGISLATION

PCC CERTIFICATION

DOIT PROJECT CERTIFICATION COMMITTEE AND DEPARTMENT OF FINANCE AND ADMINISTRATION

GENERAL FUND $11.0 LAWS 2014, CHAPTER 63, SECTION 4 (PG 50)

NM 2014 LEGISLATIVE SESSSION

GENERAL FUND $60.0 LAWS 2015, CHAPTER 101, SECTION 4 (PG 50)

NM 2015 LEGISLATIVE SESSSION

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

PAGE | 2


NUMBER DESCRIPTION

1 Internal staff resources are available only on a part time basis due to other assignments.

2 Added time constraints must be accounted for in project schedule due to timeline for RFP, contract and procurement process, and project certification.

3 Budget projections have been estimated without having full project requirements defined.

4 Budget, scope, and time of project are inter-related - a change in one changes the others.

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

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

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

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

NUMBER

DESCRIPTION TYPE M,D,E

1 Vacant IT FTEs will be filled in order to sustain this and other project initiatives.

E

2 Contract approval and project certification will occur at time and budget identified in project plan.

E

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

NUMBER DESCRIPTION

1 Existing technical architecture will support new system implementation

PAGE | 3


NUMBER DESCRIPTION

2 Executive sponsors and leadership stakeholders support the project and will provide adequate staffing resources in the IT and business units to accomplish deliverables by the project schedule.

3 A customizable COTS software solution will be identified that meets the critical business requirements identified during the requirements study.

4 The project organization structure described will be put in place and used to perform work and resolve issues in a timely manner.

5 The project charter and subsequent project management plan will be followed by the project team and updated as needed.

6 Conversion of old hard copy or microfilm records to digital format is not budgeted or accounted for in this project scope of work.

7 Corporations Division move to the SOS was not accounted for at the time the C-2 funds of $1.215 were requested. System requirements for Corporations Division system requirements will be included in RFP in support of the integrated system model, however, a subsequent funding request may be necessary to incorporate this expanded SOW.

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

Risk 1

Description -

Loss of core project team members

Probability: Low Impact : HIGH

Mitigation Strategy:Determine key personnel and develop back-up plans if that person left.Contingency Plan:Monitor workload and personnel assignments closely.

PAGE | 4


Risk 2

Description -

Reliance on contracted resources to accomplish project goals

Probability : High Impact : HIGH

Mitigation Strategy:All critical tasks are to be assigned to state personnel. Closely monitor internal staff resources and have internal staff manage outside contractor tasks and workloads.Contingency Plan: Make sure internal staff is trained and capable of completing project tasks.

Risk 3

Description -

Current vacancies in Corporations, Business Services, and IT Division are impacting staff availability to assist with project implementation.

Probability : Low Impact : MEDIUM

Mitigation Strategy: Hiring of additional staff members.Contingency Plan: Have personnel from other areas assist during implementation.

Risk 3 - Version 4.0 PMP Update: The NM SOS has been able to hire additional resources and is now fully staffed in the IT area. In the Business Services and Corporations area, temporary workers have been hired to assist with the workload. Due to temp workers, improvements in system design, and improved business processes, the Corporation’s backlog was reduced dramatically the past several months.

Risk 4

Description -

Competing Demands on staff resources - Same IT staff are involved in maintaining existing systems while also working on new project initiatives.

Probability : High Impact : HIGH

Mitigation Strategy:Executive management is strongly committed to the success of this project; resource contention is addressed regularly in weekly project meetings to facilitate resolving issues quickly and managing expectations of stakeholdersContingency Plan: Implement project over a longer period of time and add additional external resources as needed to accomplish project goals.

PAGE | 5


Risk 5

Description -

Failure to identify all user requirements

Probability: Medium Impact: Medium

Mitigation Strategy:Thorough needs assessment planned with experienced subject matter experts with several levels of approval.Contingency Plan: Address missed functionality in future software release.

Risk 5 - Version 4.0 PMP Update: The Agency and PCC (Vendor) are conducting in-depth Joint Application Development meetings in order to document existing and future user requirements

Risk 6

Description -

Failure to acquire full project funding due to expanded SOW caused by Corporations Division move to SOS

Probability: Low Impact: Medium

Mitigation Strategy:Request comprehensive solution that includes full SOW in RFP and attempt to acquire full solution with existing funding.Contingency Plan:Possible scope reduction depending on funding deficiencies and\or request additional special funds in next fiscal year to complete full project implementation.

Version 2.0 PMP Update: Risk 6 reduced to a Low Probability based on the RFP price proposal. The proposed solution will include Corporation’s functionality within the budget.

Risk 7

Description -

Underfunding in base budget for recurring support costs

Probability: Low Impact: Medium

Mitigation Strategy:Estimation of recurring costs appears to be in line with cost reallocation.Contingency Plan:Request base budget expansion to cover costs or determine other cost saving measure to cover cost difference.

Version 2.0 PMP Update: Risk 7 reduced to a Low Probability based on the RFP price proposal for on-going maintenance support. Additionally, the proposed solution will include a six-month warranty period, before the annual maintenance costs kicks in.

PAGE | 6


Maintenance costs, for the proposed solution, will be less than existing maintenance costs for software products to be replaced by the proposed solution.

Risk 8

Description –

Difficulty with data conversion


Mitigation Strategy: Include an analysis of data migration in scope of needs assessment; development data conversion strategy.Contingency Plan:None – Data migration is required but difficulties may increase project cost.

Risk 9

Description –

Impacting normal business operations during project implementation


Mitigation Strategy:Implementation and testing will be done in parallel to minimize downtime; Deployment strategy will be discussed and documented by project team; deployment will be phased by module to minimize impact to end user and public.Contingency Plan:Extend service hours or end user work hours to meet demand for services during deployment.

Risk 10

Description –

Subject Matter Expert (SME) Availability for User Acceptance Testing (UAT) in Question.

Probability: HIGH Impact: Medium

Mitigation Strategy: Extend service hours or SME work hours to meet demand for services during User Acceptance Testing.Contingency Plan: Provide alternate SME resource to meet demand for services during User Acceptance Testing and Signoff on testing.

PAGE | 7


Risk 11

Description –

Process for Development Database Changes could create delays.

Probability: HIGH Impact: Medium

Mitigation Strategy: Use communication of viable options to reach a mutually acceptable process.Contingency Plan: Provide access to PCC database administrator for changes to be made in the database.

Risk 12

Description –

Online Intake Process Implementation.1. The proposed

application provides an option to search the filings for all modules based on defined search criteria.

2. The proposed solution has the capability to configure the online filing in one flow without a hold and approve mechanism, which was demonstrated during the Orals and also mentioned in our RFP response.

3. However, the online intake process is a new requirement and the proposed application online module needs to be modified to handle the online intake process with a hold and approve mechanism.

Probability: High Impact: High

Mitigation Strategy:1. PCC proposes to SOS team that in-house and public

inquiry portions will be customized for all Segment 1 release items, which will be released on July 1st 2014.

2. PCC proposes to SOS team to move online intake process as part of Segment 2 release to March’2015.

Contingency Plan: Provide an online intake process for heavily used filing such as service of process or notary or trademarks.

PAGE | 8


Risk 13

Description –Communications to UCC web and bulk filers to notify them of a new system could generate negative feedback based on the timeframes required to train the Users on new processes. Additionally, bulk-filing specifications have not yet been defined, and Testing Environment is not operational for Testing.


Mitigation Strategy:1. PCC is providing SOS with the marketing methodology

utilized during the Vermont and Connecticut Rollouts2. NM SOS is planning on migrating existing UCC web

filers from the legacy (SOSKB) system to the PCC solution.

Contingency Plan:1. NM SOS to announce new system on their existing website.2. NM SOS to migrate existing UCC legacy filers to the PCC proposed solution.3. NM SOS to contact an existing UCC XML Bulk Filer to request their assistance with testing the proposed system.

Risk 14

Description –4. Loss of Patricia

Herrera to retirement (SOS Business Services Director with extensive institutional knowledge of existing business processes)


Mitigation Strategy:1. NM SOS has announced that Christina Espinoza, a

seasoned SOS employee with 15 plus years of experience, will be filling Patirica's project role.

Contingency Plan:Monitor workload and personnel assignments closely.

PAGE | 9


Risk 15

Description –Vendor identification of the need to push back Phase 2 delivery. The complexity and volume of phase 2 gap analysis will push back the development and testing period resulting in the vendor not being able to meet the March 2015 production target.


Mitigation Strategy:SOS must request Funding extension from the Legislature and budget for additional project management and IV&V resources beyond June 2015Contingency Plan:SOS and Vendor would need to establish a March-June contingency plan clarifying what could be delivered within the contract and fiscal year framework.

Risk 16

Description –Vendor target Dates beyond current Fiscal Year Appropriation. Funds are to be expended in this fiscal year and that the Legislature may not extend the funding appropriation beyond the current June 30th date..


Mitigation Strategy:Mitigation Plan is for SOS to request legislative extension of the funding into the next fiscal year.Contingency Plan:SOS and vendor to establish scope of project based on current funding time frame.

PAGE | 10


Risk 17

Description –Legislative Process extends uncertainty through April. Legislative extension would not take effect until roughly the end of April.


Mitigation Strategy:SOS Management to lobby legislative support for funding extension.Contingency Plan:SOS and vendor to establish scope of project based on current funding time frame.

Risk 18

Description –Additional SOS funding will be required for Project Management and IV&V services. Funding for extension of Project Management and IV&V services would not be available to cover the additional time frame for the project


Mitigation Strategy:Reduce project management services, and/or have SOS IT staff members fill the role.Contingency Plan:Agency management staff members are looking at alternative funding sources.

Risk 19

Description –Project Scope will be impacted by tasks to be completed within the contractual year, features and functionality will not be available to SOS


Mitigation Strategy:SOS and vendor to establish scope of project based on current funding time frame.Contingency Plan:SOS and Vendor to determine more limited scope for Phase 2 deliverable features and functionality

PAGE | 11


Risk 20

Description –PCC Vendor Staffing uncertainty. PCC vendor assigned developer is new to the company and not yet a permanent staff member. This means mastery of a learning curve for the PCC product and meeting the performance expectations and time frames


Mitigation Strategy: The Vendor has assured the Agency that the new developer is only responsible for the software build process, and he is not involved in the software coding process.Contingency Plan: Have Agency personnel interview the Vendor staff member in order to assess the individauls skills.

Risk 21

Description –Vendor Change control will limit SOS feature request flexibility in the development and testing process. Risk is that PCC needs SOS to sign off on specifics of the Phase 2 to enable the PCC vendor to establish the functional requirements documentation.


Mitigation Strategy: This is actually a mitigation strategy by the vendor to manage change control for phase 2 to avoid the “flexibility” that impacted phase 1.Contingency Plan: This will require SOS staff comfort with the Gap analysis findings and willingness to sign off on these. It will also require a more firm change control process between SOS and the PCC vendor.

PAGE | 12


Risk 22

Description –Avoidance of Phase 1 testing and quality assurance issues/risks. Risk is that SOS is not confident in the PCC Vendor testing and quality assurance process based on the phase 1 experience of functionality/quality not being in place during numerous User Acceptance Testing sessions.


Mitigation Strategy: There needs to be close SOS planning and monitoring of the development and testing plan and touch points or milestones established. SOS proposed testing guidelines from phase 1 should be followed.Contingency Plan: SOS might consider bringing in additional testing resources to support the process if it cannot assign its own to this process. Phase 1 was heavily dependent upon the project manager for the pre-user acceptance testing process, which was really beyond the scope of project management.

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTUREThe 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 STAKEHOLDERSList all of the major stakeholders in this project, and state why they have a stake. . Stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.

NAME STAKE IN PROJECT ORGANIZATION TITLE

DIANNA J. DURAN EXECUTIVE SPONSOR

SECRETARY OF STATE’S OFFICE

SECRETARY OF STATE

MARY QUINTANA EXECUTIVE SPONSOR

SECRETARY OF STATE’S OFFICE

DEPUTY SECRETARY OF STATE

PAGE | 13



KEN ORTIZ PROJECT SPONSOR SECRETARY OF STATE’S OFFICE

CHIEF OF STAFF

KARI FRESQUEZ INTERNAL PROJECT MANAGER

IT DIVISION CIO

BLEZOO VARGHESE SOS TECHNICAL LEAD

IT DIVISION DEPUTY CIO

IT OPERATIONS STAFF

IT IMPLEMENTATION AND ONGOING SUPPORT

IT DIVISION IT OPERATIONS STAFF

CHRISTINA ESPINOZA BUSINESS SPONSOR BUSINESS SERVICES

BUREAU CHIEF

STACY STARR-GARCIA

BUSINESS SPONSOR CORPORATIONS BUREAU CHIEF

BUSINESS SERVICE STAFF

BUSINESS USERS & SUBJECT MATTER EXPERTS

BUSINESS SERVICES DIVISION

BUSINESS OPS SPECIALISTS

JOHN SALAZAR

CATHY SISNERSOS

PROJECT MANAGER CSW ENTERPRISES

PROJECT MANAGERS

NICOLAS BEHRMANN IV&V VENDOR

IV&V DELIVERABLES

SOLE PROPRIETOR

IV&V CONTRAC-TOR

VISHAL HANJAN SOFTWARE IMPLEMENTATION VENDOR - PROJECT EXECUTIVE

PCC TECHNOLOGY GROUP

PROJECT EXECUTIVE

RAGHU CHANDRA SOFTWARE IMPLEMENTATION VENDOR - PROJECT MANAGER


PROJECT MANAGER

JONATHAN CHRISTY SOFTWARE IMPLEMENTATION VENDOR - BUSINESS ANALYST


BUSINESS ANALYST

EXTERNAL ENTITIES INTERNET USERS WANTING TO

EXTERNAL USERS

REGISTERED PORTAL

PAGE | 14



(I.E.. REGISTERED AGENTS, LAW FIRMS, CONSTITUENTS, ECT.)

PERFORM SELF-SERVICE TRANSACTIONS VIA THE INTERNET

USERS

GENERAL PUBLIC GENERAL PUBLIC SEARCHING SOS SYSTEMS FOR PUBLIC INFORMATION

PUBLIC GENERAL PUBLIC

PAGE | 15


2.2 PROJECT GOVERNANCE STRUCTURE2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART

PAGE | 16


2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE

ROLE RESPONSIBILITY

EXECUTIVE SPONSOR(S)

Ensure appropriate resources and priority is set for the project.

PROJECT SPONSOR Ensure clear requirements and direction is provided for the project. Approve plans, schedules, and budgets, and ensure timely availability of resources.

PROJECT MANAGER(S)

Ensure project resources are being managed, project deliverables are being met, deliverable acceptance is occurring, appropriate communication is occurring, and issues are being identified, reported, and mitigated and that the overall project is being completed as defined.

STEERING COMMITTEE

Core project stakeholders including management and project team members will assist in driving the direction and decisions of the project, setting projects requirements, participating in the RFP, and evaluating solution providers.

PROJECT TEAM

Business users

IT Administrators

External Solution Providers

Act as subject matter experts, share expertise, and responsible for producing deliverables within the project scope as defined by the project sponsor and project manager. Business users will generally be responsible for testing and accepting deliverables. IT Administrators will be responsible for infrastructure deployment and implementation oversight. External solution providers will be selected by the steering committee and will be primarily responsible for major project implementation deliverables. Project Team members will be pulled into project at appropriate times to complete deliverables.

IV&V PROVIDER During implementation, IV&V will be utilized to ensure requirements are being implemented as defined in the planning phase of the project.


PCC Technology Group to provide deliverable-based services to complete detailed specifications, customize user and data interfaces, and facilitate system acceptance and implement the Business Filing System set forth in PCC’s RFP Response and subsequent negotiated contract.

PAGE | 17

Dianna J. Duran, Secretary of State

Executive Sponsor

Mary Quintana, Deputy Secretary of StateExecutive Sponsor

Ken Ortiz, Program DirectorProject Sponsor

Christina Espinoza, Business Services Director

Project Stakeholder

Business Services Subject Matter Experts

STacy Starr-Garcia, Corporations Director

Corporations Subject Matter Experts

Kari Fresquez, CIO Blezoo Varghese, Deputy

CIO Internal Project Managers

IV&V Contractor - Nicolas Behrmann

John Salazar & Cathy Sisneros - Contract Project

ManagersIT Support Staff


2.2.3 VENDOR ORGANIZATIONAL STRUCTURE

Name Role Responsibilities

Steering Committee NMSOS - Core project stakeholders including management and project team members will assist in driving the direction and decisions of the project, settings project requirements, participating in the RFP, and evaluating solution providers.

John Salazar NMSOS Project Manager

- Ensure project resources are being managed, project deliverables are being met, deliverable acceptance is occurring, appropriate communication is occurring, and issues are being identified, reported, and mitigated and that the overall project is being completed as defined.

Vishal Hanja

[email protected]

860.466.7245

PCC Project Executive

- Oversee project at the Delivery level.- Elevated problem resolution.- Manage PCC/NMSOS relationship.

Raghu Chandra

[email protected]

860.466.7242

PCC Project Manager - Manages/controls the on-time progress and delivery of all aspects of the project from a PCC perspective.

- Single point of contact between NMSOS and PCC resources.

PAGE | 18

Raghu ChandraProject Manager

New Mexico SOS Steering Committee

Sreeji VijayanTechnical Manager

Jeremy StebenSubject Matter Expert

Alohita NandagiriQuality Assurance

Analyst

John SalazarNMSOS Project

Manager

New Mexico SOSFunctional Lead

Blezoo VargheseTechnical Lead

Tom BryersDatabase

Administrator

Bhanu NagallaSenior Developer

Millisent Fury Hopkins

CRD Trainer

Ray JohnsonData Modeler

Anand BalasubramanianProject Executive

Vishal HanjanConversion Manager

PCCDevelopers

mailto:[email protected]



Name Role Responsibilities- Drives the Communication and

Reporting mechanisms to reduce risk.- Monitors and initiates Change

Management activities.- Acts as liaison between Business and

Technical teams.- Provide status information and create,

maintain, and distribute a project-tracking document as the implementation work progresses.

- Provides CRD system subject matter expertise.

- Provides CRDTM business subject matter expertise.

- Provides high-level technical and architectural guidance to the PCC team.

- PCC resource manager.

Sreeji Vijayan

[email protected]

860.466.7250

PCC Technical Manager

- Architect the CRDTM design.- Plays system consultant to PCC

development team during analysis phase.

- Leads development effort of the CRDTM

Architecture.- Coordinate the communications between

the customer and in-network developers.

Jeremy Steben

[email protected]

860.466.7202

PCC Subject Matter Expert

- Assess & document application design.- Plays system consultant to the team and

coordinate all NMSOS activities.- Monitors and reports on ongoing quality

and adherence to specifications.- Coordinates QA support staff- Develop Acceptance Test Plan- Take a lead role during the testing and

sign off phase.- Design, develop and implement training

for all users.

Jonathan Christy

[email protected]

PCC Subject Matter Expert

- Assess & document application design.- Plays system consultant to the team and

coordinate all NMSOS activities.- Monitors and reports on ongoing quality

and adherence to specifications.- Coordinates QA support staff- Develop Acceptance Test Plan- Take a lead role during the testing and

sign off phase.- Design, develop and implement training

for all users.

Alohita Nandagiri PCC Quality - Software Test Plan Preparation

PAGE | 19





Name Role Responsibilities

[email protected]

860.466.7227

Assurance Lead and Implementation.- Review Test Cases- Analyze the requirements during the

requirements analysis phase of the project.

- Track and report testing activities - testing results, test case coverage, required resources, defects discovered and their status, performance baselines, etc.

- Log project related issues in the defect-tracking tool identified for the project.

Vishal Hanjan

[email protected]

860.466.7239

PCC Conversion Manager

- Develop conversion strategy and plan- Develop data mapping document- Develop data conversion scripts- Develop exception reports

Ray Johnson

[email protected]

860.466.7239

Data Modeler - Works with the business and technical teams to understand the requirements and port them into data elements

- Updates the current CRDTM product’s data model to align with NMSOS requirements

Millisent Fury Hopkins

[email protected]

860.466.7274

PCC Training Lead (CRD Trainer)

- Prepare the training material- Develop a training plan- Develop a training schedule- Develop training exercises- Train the trainer training- County user training- Conduct class room exercises

Tom Bryers

[email protected]

860.466.7205

PCC Database Administrator

- Develop and enforce CRDTM database standards, guidelines and operational policies and procedures

- Review physical structures and design of the database

- Review SQL performance and Tuning Review maintenance and utilities associated with each structure.

- Reviewing application's access to the database structures

- Review backup & recovery strategies- Monitoring database performance issues- Review Conversion Scripts and Stored

PAGE | 20







Name Role ResponsibilitiesProcedures

Bhanu Nagalla

[email protected]

860.466.7233

PCC Senior Developer - Provides CRDTM Platform technical subject matter expertise during all project phases.

- Provides decision-making and design for all major architecture decisions.

- Ensures conformance to all standards and practices for coding, data and security concerns.

- Leads the development team and configuration management process under the direction of the Technical Manager.

- Assigned the most critical development tasks.

2.2.4 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

Project Manager and project steering committee will interface with executive management and subject matter experts located at the PRC for product delivery requiring input from PRC department staff members. Project Manager is expected to coordinate meetings and product delivery.

2.3 EXECUTIVE REPORTINGExecutive sponsor(s) are included in the bi-weekly project status meetings and are included on bi-weekly status report correspondence. Project sponsor is responsible for communicating project status to executive sponsors when they are unable to attend status meetings.

The Agency CIO is responsible for reporting to the DoIT and the Project Certification Committee members.

3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTION

BUSINESS Improve user efficiency - Provide staff with updated technology so

PAGE | 21



NUMBER DESCRIPTION

OBJECTIVE 1 they may better serve public demand for information and services.

BUSINESS OBJECTIVE 2

Enhance service delivery to constituents - Establish online services to maximize public access to information and services maintained by the agency.

BUSINESS OBJECTIVE 3

Establish standardization and uniformity in maintaining all business filings and in accordance with statutory guidelines.

3.1.2 TECHNICAL OBJECTIVES

NUMBER DESCRIPTION

TECHNICAL OBJECTIVE 1

Improve system reliability and reduce system downtime.


Reduce IT infrastructure complexity.


Utilize IT to support and streamline business processes.


Replace and consolidate legacy equipment and applications and ensure security compliance.


Ensure business continuity requirements of mission critical applications are addressed.


Ensure IT best practices are implemented and followed.


Maintain systems on a standard refresh cycle.


Ensure adequate system controls and security is in place.


Reduce risk of system disaster and missing records.

3.2 PROJECT EXCLUSIONSDuring the assessment conducted during phase one it was discovered that no records retention plan is in currently in place for the PRC Corporations Division and statutory retention guidelines may not be being adequately met. Conversion of old hard copy or microfilm records to digital format or digital records to microfilm format is not budgeted or accounted for in this project scope of work.

PAGE | 22


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

NUMBER DESCRIPTION

QUALITY METRICS 1 Team members need to be empowered in order to makeo Technical Decisionso Creative Decisions

QUALITY METRICS 2 Regular executive steering committee meetings must be held for the duration of the project to facilitate:

o Requirements managemento Financial oversighto Change managemento Deliverables acceptance

QUALITY METRICS 3 Project development methodology must be followed

QUALITY METRICS 4 Project stays on time, on scope, and within budget

QUALITY METRICS 5 Enhance service delivery to the public

QUALITY METRICS 6 Reduce reactive support time of IT staff

4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

PROJECT PHASE DELIVERABLE

INITIATION PHASE: DEFINE

Define software requirements and implementation strategy

Software replacement RFP Issuance

PLANNING PHASE: DESIGN

Project Management Professional Services Contract – CSW Enterprises

IV&V Contract – Vendor Nicholas Behrmann

PAGE | 23


IMPLEMENTATION PHASE: DEVELOP\ IMPLEMENT

Software and Implementation Contract – Vendor PCC Technology Group

Map Business Requirements to Functional Design

Define Technical and Application Specifications & Architecture including security

Database Entity Relationship Diagrams

System Design & Development Plan – Finalize system design requirements, customizations, reporting, and security profiles

Data Conversion Plan

User Acceptance and Test Plans

End User Training Documentation

Implementation Strategy – solution moved to production environment and production state monitored

CLOSEOUT PHASE: MAINTENANCE

IT Administration standards and business continuity model implemented

Software maintenance terms documented

Lessons Learned

4.1.1 PROJECT MANAGEMENT DELIVERABLES

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

DELIVERABLE NUMBER

DELIVERABLE DESCRIPTION ACCEPTANCE

DEL-1 Project Charter

The Project Charter for Certification sets the overall scope for the project, the governance structure, and when signed is considered permission to proceed with the project. The Project Charter for Certification is used to provide the Project Certification Committee with adequate knowledge of the project and

Deliverable Acceptance Criteria

According to DoIT requirements and State of NM policies and procedures.

PAGE | 24


related planning to certify the initiation phase of the project.

Standards for Content and Format

According to DoIT requirements, standards and templates.

Quality Review

Monthly by business owners and project team.

Presentation as required and certification by DoIT and PCC.

DEL-2 Certification Form

The Request for Certification and Release of Funds form is submitted when a project goes for any of the certification phases. It deals with the financial aspects of the project, as well as other topics that indicate the level of planning that has gone into the project. Many of the questions have been incorporated into the preparation of the project charter.


According to DoIT requirements and State of NM policies and procedures.



Quality Review



PAGE | 25


DEL-3 Project Management Plan

Project management plan is a formal document approved by the executive sponsor and the Office of the Secretary of State and developed in the plan phase used to manage project execution, control, and project close. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost and schedule baselines. A project plan includes at least other plans for issue escalation, change control, communications, deliverable review and acceptance, staff acquisition, and risk management.





Quality Review



DEL-4 IV&V Contract & Reports

Independent verification and validation (IV&V) means the process of evaluating a project to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the lead agency. Independent verification and validation assessment reporting. The Department requires


Shall be reviewed and approved by the SOS project steering committee of all tasks being completed and tested.

PAGE | 26


all projects subject to oversight to engage an independent verification and validation contractor unless waived by the Department.


Will be according to DoIT requirements for IT Professional Services Contract scope, terms and conditions and shall be determined by the approval of the Project Steering Committee and project team.

Quality Review


DEL-5 IT Service Contracts

The Department of Information Technology and the State Purchasing Division of General Services have established a template for all IT related contracts.


Shall be reviewed and approved by the SOS project steering committee of all tasks being completed and tested.

PAGE | 27




Quality Review


DEL-6 Risk Assessment and Management

The DoIT Initial PROJECT RISK ASSESSMENT template, which is meant to fulfill the following requirement: Prepare a written risk assessment report at the inception of a project and at end of each product development lifecycle phase or more frequently for large high-risk projects. Each risk assessment shall be included as a project activity in project schedule. Project Oversight Process memorandum.


As set forth in the Contract Agreement or required by the Project Team and according to DoIT requirements, standards and templates.



PAGE | 28


Quality Review

Weekly monitoring and risk updates by Project Manager to Project Team and Executive Steering Committee.

Project Manager follows proper escalation steps with changes to existing or new risks.

Risk Management Plan and Risk Log included as required with certification documents for DoIT and PCC presentations and monthly reporting.

DEL-7 Project Schedule

A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. The de-facto standard is Microsoft Project.


Weekly: Project Manager and project team monitor tasks and document progress and issues.

Weekly: updated project schedule included with Project Status Report to Executive Sponsors and Steering Committee.

Updated schedule provided as required with DoIT and PCC certification documents.

PAGE | 29



MS Project or MS Excel Format.

Quality Review

Weekly review by Project Team and Project Sponsors.


DEL-8 Monthly Project Status Reports to DoIT

Project status reports. For all projects that require Department oversight, the lead agency project manager shall submit an agency approved project status report on a monthly basis to the Department.


Project Manager provides SOS with updated Monthly Report in DoIT format by the 9th of each month.

Monthly Status Report submitted to DoIT by the 10th of each month.


DoIT Monthly Report template.

Quality Review

Review by DoIT Project Oversight and clarification provided as needed by SOS

PAGE | 30


DEL-9 Project Closeout Report

This is the Template used to request that the project be officially closed. Note that project closure is the last phase of the certification process.


According to DoIT requirements and templates and State of NM policies and procedures.


DoIT and State of NM.

Quality Review



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 NUMBER

DELIVERABLE APPROVERS (WHO CAN APPROVE)

DATE APPROVED

DEL-001 Project Charter Project Sponsor & Agency CIO

May 8, 2013

DEL-002 Initiation & Planning Phase Certification Form

Project Sponsor & Agency CIO

May 8, 2013

DEL-003 Project Management Plan (PMP) Project Sponsor & Agency CIO

PMP will be updated, ongoing and as required for remainder of project term.

PAGE | 31


DELIVERABLE NUMBER


DATE APPROVED

DEL-004 IV&V Contract

IV&V Reports

Project Sponsor & Agency CIO

Upon final signature

DEL-005 IT Service Contracts Project Sponsor & Agency CIO


DEL-006 Risk Assessment and Management Project Sponsor & Agency CIO


DEL-007 Project Schedule Project Sponsor & Agency CIO

Weekly, as updated

DEL-008 Monthly Project Status Reports to DoIT

Agency CIO Monthly, as produced

DEL-009 Project Closeout Report Project Sponsor & Agency CIO

On project close

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

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

The Project Sponsor and the project team will review completed deliverables to certify that specifications and requirements and/or contract obligations have been satisfied. The project team will vote to accept or reject the deliverable and provide the team’s majority decision, in writing, to the Project Sponsor for approval of payment of vendor invoices.

If the deliverable is rejected, the project team will inform the Project Sponsor, in writing, of the reason for the rejection, and actions required by the vendor before the deliverable is presented for acceptance again.


The following Deliverable review process has been agreed to between the PCC Technology Group and the SOS. Deliverable reviews are for the purpose of determining whether each such Deliverable substantially meets Contract specifications.

Once the detailed project plan is approved by the Procuring Agency, the following sections detail the process for submission and review of Deliverables during the life of the project/Contract.

PAGE | 32


1. General

a. When submitting a Deliverable for review and acceptance, PCC Technology Group shall produce one (1) master (both soft and hard copy, where applicable) and two (2) additional hard copies, if requested and where applicable, to the Procuring Agency Project Manager as identified in the Contract.

b. Once a Deliverable is approved and accepted by the Procuring Agency, PCC Technology Group shall provide a final updated and corrected electronic copy. The Procuring Agency may, at its discretion, waive this requirement for a particular Deliverable.

c. The electronic copy shall be provided in software currently utilized by the Procuring Agency or provided by PCC Technology Group.

d. Deliverables will be evaluated by the Procuring Agency under Quality Assurance.

2. Deliverable Submission

a. Prior to development and submission of each Contract Deliverable, PCC Technology Group will submit a Deliverables Expectation Document ( DED ) containing a description of the format and content of each Deliverable will be delivered to the NM SOS Business Filing Executive Steering Committee for review and approval. The DED shall contain, at a minimum, the following:

1) Cover letter outlining the purpose of the Deliverable;

1) A Table of Contents with a brief description of the content of each section;

2) Anticipated number of pages; and

3) Identification of anticipated appendices/exhibits.

4) The DED shall contain an approval/rejection section that can be completed by the Procuring Agency. The DED will be returned to the

PAGE | 33


Contractor within a mutually agreed upon time frame.

b. Deliverables shall be developed by PCC Technology Group according to the approved format and content of the DED for each specific Deliverable. The DED is not an amendment of the Agreement, but is a roadmap for production of the Deliverable.

c. At a mutually agreed to meeting, on or before the time of delivery to the Procuring Agency, PCC Technology Group shall schedule and provide a walkthrough of each Deliverable to be presented.

d. Deliverables shall be submitted no later than 5:00 PM, per the approved Contract Deliverable schedule and shall be accompanied by a Deliverable sign-off form with the appropriate sections completed by PCC Technology Group.

3. Deliverable Review

a. General

1) The Procuring Agency’s review time begins on the next working day following receipt of the Deliverable.

2) The Procuring Agency’s review time will vary by Deliverable, and will be defined in the table at the end of this section or by Article 4 of the Agreement if not included in the table.

3) The Procuring Agency has up to _5__ working days to determine if a Deliverable is complete and ready for review. Unless otherwise negotiated, this is part of the Procuring Agency’s review time.

4) Any subsequent Deliverable, whose requirements are directly dependent upon a prior Deliverable, will not be accepted for review until the previous Deliverable has been accepted.

5) After review of a Deliverable, the Procuring Agency will return to PCC Technology Group the project Deliverable sign-off form (attached to the end of this Exhibit) with the Deliverable submission

PAGE | 34


and review history section completed.

b. Accepted

1) If the Deliverable is accepted, the original Deliverable sign-off form signed by the appropriate Procuring Agency representatives will be returned to PCC Technology Group.

2) Once the Contractor receives the original Deliverable sign-off form, the Procuring Agency can then be invoiced for the Deliverable per the procedures set out in the Agreement.

c. Rejected - Comments/Revisions Requested by the Procuring Agency

If the Procuring Agency has comments and/or revisions to a Deliverable, the following will be provided to PCC Technology Group:

1) The original Deliverable sign-off form with an updated entry to the Deliverable submission and review history section.

Attached to the Deliverable sign-off form will be a detailed explanation of the revisions to be made and/or a marked up copy of the Deliverable.

2) The Procuring Agency’s first review and return with comments will be completed within the times specified in the Agreement.

3) PCC Technology Group will have fifteen (15) days, unless otherwise mutually agreed to, for review, acceptance and/or rejection of the Procuring Agency’s comments, and resubmission of the Deliverable.

4) A meeting (called by PCC Technology Group) to resolve outstanding issues shall be completed within five (5) working days after completion of PCC Technology Group review or a mutually agreed upon time frame.

5) Agreements made during meetings to resolve issues shall be documented and attached to the Deliverable sign-off form. Any such Agreements are not Amendments to the Contract. Amendments to the Contract shall follow the procedures set out in Article 25 of this Agreement.

PAGE | 35


6) Once an agreement is reached regarding changes, PCC Technology Group shall incorporate them into the Deliverable for resubmission to the Procuring Agency.

7) All changes shall be easily identifiable by the Procuring Agency.

8) Resubmission of the Deliverable shall occur within fifteen (15) days or a mutually agreed upon time frame of the resolution of any outstanding issues.

9) The resubmitted Deliverable shall be accompanied by the original Deliverable sign-off form.

10) PCC Technology Group will have the opportunity to resubmit a Deliverable to the Agency a minimum of three times per Article 4(c) of the Agreement.

11) During the re-review process, the Procuring Agency may only comment on the original exceptions noted, unless changes to the Deliverable cause new issues to arise.

12) All other items not originally commented on are considered to be acceptable by the Procuring Agency, unless changes to the Deliverable cause new issues to arise.

13) Once all revisions have been accepted, the original Deliverable sign-off form signed by the appropriate Procuring Agency representatives will be returned to PCC Technology Group.

14) PCC Technology Group shall provide one (1) updated and complete master paper, if applicable, and associated electronic copy of each Deliverable after approval and acceptance by the Procuring Agency.

PAGE | 36


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

Initiation Project scope of work and deliverables identified

Project Charter

Planning & Design Definition of system requirements, work breakdown schedule

RFP

Project Management Contract

IV&V Contract

Implementation Implementation and configuration of project software, hardware, databases, and customizations including reports

Software and Implementation Contract

Software Licenses

Data Conversion Services

Software Implementation Services

Testing User acceptance testing (UAT)

UAT Test Plans

Delivery Sign Off Documents

Deployment Transition to operations in production environment

Production Cutover Plan

End user training

System Documentation

Maintenance Maintenance of new systems; decommissioning old systems; project closeout and lessons learned

Maintenance and support plan for internal IT operations

Annual maintenance agreements with vendors

PAGE | 37


4.2.1 TECHNICAL STRATEGY

Discuss the key technical strategies for achieving success in this project.

The technical strategy for this project is to purchase a commercial off the shelf (COTS) software solution that can be customized to meet the business requirements specific to the SOS Business Services Division. This approach is being utilized so that the provided solution is sustainable with the aid of current vendor support. A complete custom or in house solution may not but sustainable given the small size of the SOS IT staff and the large number of competing responsibilities on the IT staff. In addition, staff turnover is likely to have a lower impact with a well-documented COTS solution versus an in house solution. It is imperative that the customization capabilities, technical architecture, and security features of the COTS solution be well demonstrated during the RFP process to ensure that the solution will meet the needs of the business users and project stakeholders and that the system architecture is sustainable by current IT staff and in current IT architectural model.

PCC will provide a technical design document as part of their contract deliverables.

4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES

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

DELIVERABLE NUMBER

DELIVERABLE DESCRIPTION ACCEPTANCE

DEL-1 Project Kickoff Contractor will conduct a project kickoff meeting at the SOS facilities in New Mexico. This will cover the following topics:1. Team Introductions and Roles

and Responsibilities2. Review Draft Project

Management Plansa. Communicationb. Riskc. Staffingd. Change Controle. Quality Assurancef. Training


As defined in contract scope of work and approved by project steering committee and IT operations staff

PAGE | 38


3. Review Project Schedule4. Prepare for Gap Analysis

Sessions


As defined in contract scope of work

Quality Review

Weekly status meeting with project steering committee

DEL-2 Detailed Project Plan Final Implementation Plan and Milestone Deliverable Matrix

Detailed Project Schedule/Work Plan

Change Management Plan

Risk Management Plan

Quality Assurance/Issue Management Plan

Staffing Plan

Communications Management Plan





PAGE | 39


Quality Review


DEL-3 Development Environment Installation/ Configuration

Install/Configure Development Environments





Quality Review


PAGE | 40


DEL-4 Gap Analysis Sessions Segment 1: Conduct Gap Analysis Sessions to Gather Business Requirements

Segment 1: Document Functional and Business Changes

Conduct review session(s)





Quality Review


PAGE | 41


DEL-5 Segment 1- Data Model and Database Design

Update Data Model and Database Design Document






Quality Review


PAGE | 42


DEL-6 Segment 1 - Functional Requirements

Functional Requirements Document (FRD) Detail Updated Process Flows and Scenarios

FRD Update Requirements Traceability Matrix (RTM)






Quality Review


PAGE | 43


DEL-7 Segment 1 - Technical Design

Update Technical Design Document1. OVERVIEW

2. ARCHITECTURE APPROACH, TOOLS AND TECHNOLOGIES

2.1 ARCHITECTURE APPROACH

2.2 KEY ARCHITECTURAL CONSIDERATIONS

2.3 SEQUENCE OVERVIEW

2.4 ARCHITECTURE PATTERNS AND COMPONENTS

2.5 TOOLS AND TECHNOLOGIES

3. PROPOSED SOLUTION OVERVIEW

3.1 BUSINESS PROCESS RE-ENGINEERING

3.2 EXTERNAL INTERFACE COMMUNICATION PROCESS

3.3 BULK FILING PROCESS

4. ENVIRONMENT DETAILS

4.1 PRODUCTION ENVIRONMENT

4.2 QA/TESTING ENVIRONMENT

4.3 TRAINING ENVIRONMENT

4.4 DEVELOPMENT ENVIRONMENT

5. HARDWARE AND SOFTWARE REQUIREMENTS

5.1 HARDWARE REQUIREMENTS

5.2 SOFTWARE REQUIREMENTS

6. SECURITY

6.1 INFRASTRUCTURE LEVEL SECURITY

6.2 APPLICATION LEVEL SECURITY

6.3 SSL REQUIREMENT

7. OPERATION AND SUPPORT

8. TECHNICAL REFERENCE

8.1 SAMPLE ENTITY/RELATIONSHIP DATABASE DIAGRAM

8.2 PROPOSED PROCESS FLOW DIAGRAM

9. DISASTER RECOVERY

10. RESPONSE TO IDENTIFIED SYSTEM ISSUES






Quality Review


PAGE | 44


DEL-8 Segment 1- QA Plan 1. Update QA Plan and Test Cases for Customized Modules

Test Cases will include Step/Action tables that guide the user through the process of executing a specific Use Case within the system, and include necessary test data and descriptions of expected results. Each step provides ability to indicate success or failure and map issues to the online issue tracking system identifiers.

2. Conduct review session(s)





Quality Review


PAGE | 45


DEL-9 Segment 1 - Training Plan

1. Update Training Plan and Approach

The PMBOK-compliant training plan includes:1 TRAINING PLAN OVERVIEW

1.1 Training Introduction1.2 Background and Scope

2 PCC TRAINING STRATEGY2.1 Strategy Overview2.2 Training Plan Summary

3 TRAINING METHODOLOGY3.1 Systematic Approach to Training Using the ADDIE Method3.2 Modular Curriculum Design3.3 Learning Exercises

4 TRAINING APPROACH4.1 Training User Groups4.2 Specific Training Needs by User Group

5 RESOURCES AND FACILITIES5.1 Training Facilities5.2 Resources, Roles and Responsibilities

6 TRAINING MATERIALS LIST7 SCHEDULE8 GLOSSARY OF TRAINING TERMS






Quality Review


PAGE | 46


DEL-10 Segment 1- Data Conversion

1. Data Conversion

CONTRACTOR WILL DEVELOP, TEST AND EXECUTE THE DATA CONVERSION SCRIPTS AND ACTIVITIES






Quality Review


PAGE | 47


DEL-11 1. Segment 1- Application Customization

2. Integration Testing

3. Application Demonstration review session(s)

1. Contractor to install Segment 1 application code and updated database module in the Agency’s computing environment(s). Contractor will configure and customize application components to meet the full requirements documented in the FRD and tracked through the RTM Documentation 2. Conduct review session(s)

2. Contractor will perform system integration testing in the test environment to ensure the solution is operating sufficiently in order to proceed to the UAT system phase.

3. Contractor will conduct application demonstration review session(s) for Agency key stakeholders in order to provide verification that the configured system meets the Agency’s expectations for being UAT ready





Quality Review


PAGE | 48


DEL-12 Segment 1-User Acceptance Testing (UAT) 2. Integration Testing

1. Finalize UAT Plan Contractor will perform system integration testing in the test environment to ensure the solution is operating sufficiently in order to proceed to the UAT system phase.

2. Execute Segment 1 UAT3. Track and Resolve UAT Issues4. Conduct review session(s)





Quality Review


PAGE | 49


DEL-13

DEL-13A

DEL-13B

Segment 2 - Gap Analysis Sessions

(Corporations, Partnerships and NSF)

1. Segment 2: Conduct Gap Analysis Sessions to Gather Business

2. Segment 2: Document Functional and Business Changes






Quality Review


PAGE | 50


DEL-14 Segment 1-Training 1. Segment 1 – Training Materials/Documentation

2. Segment 1 – User Training





Quality Review


PAGE | 51


DEL-15 Segment 1 - Data Conversion Production Pull

1. Data Conversion Production Pull Segment 1






Quality Review


PAGE | 52


DEL-16 Segment 1 - Application Operational in Production

1. Segment 1 Deployment and Production Implementation

2. Test Production Environment





Quality Review


PAGE | 53


DEL-17 Segment 2 - Data Model and Database Design

1. Update Data Model and Database Design Document






Quality Review


PAGE | 54


DEL-18

DEL-18A

DEL-18B

Segment 2 - Requirements Documents


1. Functional Requirements Document (FRD) Detailing Updated Process Flows and Scenarios

2. FRD Update Requirements Traceability Matrix (RTM)






Quality Review


PAGE | 55


DEL-19

DEL-19A

Segment 2 – Prototype Design

(Corporations and Partnerships)

1. Develop software prototype2. Conduct review session(s)





Quality Review


PAGE | 56


DEL-20

DEL-20A

Segment 2 – Data Conversion

1. Data Conversion and migration2. Conduct review session(s)





Quality Review


PAGE | 57


DEL-21

DEL-21A

DEL-21B

Segment 2 – Applications Customization


1. Segment 2 Coding and Database Updates

2. Integration Testing3. Application Demonstration and

Code Walkthrough





Quality Review


PAGE | 58


DEL-22

DEL-22A

Segment 2 – User Acceptance Testing

(Partnerships and Corporations)

1. Finalize UAT Plan Contractor will perform system integration testing in the test environment to ensure the solution is operating sufficiently in order to proceed to the UAT system phase.

2. Execute Segment 2 UAT3. Track and Resolve UAT Issues






Quality Review


PAGE | 59


DEL-23

DEL_23A

Segment 2-Training

(Corporations and Partnerships)

1. Develop Segment 2 – Training Materials/Documentation

2. Execute Segment 22 Training





Quality Review


PAGE | 60


DEL-24

DEL-24A

Segment 2-Data Conversion Production Pull

(Partnerships and Corporations)

1. Data Conversion Production Pull2. Conduct review sessions(s)





Quality Review


PAGE | 61


DEL-25

DEL-25A

Segment 2 Application in Production

(Partnership and Corporations)

1. Segment 2 Deployment and Production Implementation

2. Test Production Environment





Quality Review


PAGE | 62


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.

Note: The Date Approved Column for the Deliverable Table presented below, will be managed by the use of the Agency’s Dashboard project methodology utilized by the Agency to provide pertinent project information in a single consolidated document.

DELIVERABLE NUMBER


DATE APPROVED

DEL-1 Project Kickoff Project Team, Business Owner, and Project Sponsor

1/31/14

DEL-2 Detailed Project Plan Project Team, Business Owner, and Project Sponsor

1/31/14

DEL-3 Development Environment Installation/Configuration

Project Team, Business Owner, and Project Sponsor

2/20/14

DEL-4 Segment 1 - Gap Analysis Sessions


2/20/14

DEL-5 Segment 1- Data Model and Database Design


3/6/14

DEL-6 Segment 1 - Functional Requirements


3/20/14

DEL-7 Segment 1 - Technical Design Project Team, Business Owner, and Project Sponsor

3/20/14

DEL-8 Segment 1- QA Plan Project Team, Business Owner, and Project Sponsor

3/20/14

DEL-9 Segment 1 - Training Plan Project Team, Business Owner, and Project Sponsor

2/28/15

PAGE | 63


DELIVERABLE NUMBER


DATE APPROVED

DEL-10 Segment 1- Data Conversion Project Team, Business Owner, and Project Sponsor

1/5/15

DEL-11 Segment 1- Application Customization


8/31/14

DEL-12 Segment 1-User Acceptance Testing (UAT)


8/31/14

DEL-13 Segment 2 – Corporations Gap Analysis Sessions


2/28/15

DEL-13A Segment 2 - Partnerships Gap Analysis Sessions


2/28/15

DEL-13B Segment 2 – NSF Gap Analysis Sessions


2/28/15

DEL-14 Segment 1-Training Project Team, Business Owner, and Project Sponsor

6/30/14 – 12/31/14

DEL-15 Segment 1 - Data Conversion Production Pull


6/30/14 – 12/31/14

DEL-16 Segment 1 - Application Operational in Production


6/30/14 – 12/31/14

DEL-17 Segment 2 - Data Model and Database Design


DEL-18 Segment 2 – Corporations Requirements Documents


DEL-18A Segment 2 – Partnership Requirements Documents

Project Team, Business Owner,

PAGE | 64


DELIVERABLE NUMBER


DATE APPROVED

and Project Sponsor

DEL-18B Segment 2 – NSF Requirements Documents


DEL-19 Segment 2 – Partnership Prototype Design


DEL-19A Segment 2 – Corporations Prototype Design


DEL-20 Segment 2 – Corporations Data Conversion


DEL-20A Segment 2 – Partnerships Data Conversion


DEL-21 Segment 2 - Corporations Application Customization


DEL-21A Segment 2 - Partnership Application Customization


DEL-21B Segment 2 - NSF Application Customization


DEL-22 Segment 2 – Partnerships User Acceptance Testing


DEL-22A Segment 2 – Corporations User Acceptance Testing


DEL-23 Segment 2-Partnerships Training Project Team, Business Owner, and Project Sponsor

PAGE | 65


DELIVERABLE NUMBER


DATE APPROVED

DEL-23A Segment 2- Corporations Training


DEL-24 Segment 2-Partnerships Data Conversion Production Pull


DEL-24A Segment 2- Corporations Data Conversion Production Pull


DEL-25 Segment 2 - Partnerships Application Operational in Production


DEL-25A Segment 2 - Partnerships Application Operational in Production


4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

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

The Project Sponsor and the project team will review completed deliverables to certify that specifications and requirements and/or contract obligations have been satisfied. The project team will vote to accept or reject the deliverable and provide the team’s majority decision, in writing, to the Project Sponsor for approval of payment of vendor invoices.

If the deliverable is rejected, the project team will inform the Project Sponsor, in writing, of the reason for the rejection, and actions required by the vendor before the deliverable is presented for acceptance again.

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.

PAGE | 66


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

An attachment is provided with the SOS Project Management Plan in order to identify and document the Work Breakdown Structure for the project. Please refer to the detailed project plan SOS_Business_Filing_System_Project_Plan v1 2014 01 13 for more details.

PAGE | 67


5.2 Schedule allocation -Project Timeline

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

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

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

PAGE | 68


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

Phase / Activity Associated Deliverables Estimated Budget(*k = $1,000.00)

Umbrella Tasks

Initiation & Implementation

Procurement Management ServicesProject Management ServicesIV&V ServicesSecurity Assessment

$365.0k

Implementation Software costs $861.0k

PAGE | 69


Phase / Activity Associated Deliverables Estimated Budget(*k = $1,000.00)

Phase Implementation costsTraining costs

TOTALS $1,226.0k

5.4 PROJECT TEAM5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE

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

PAGE | 70


5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES

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

PAGE | 71

Mary Quintana, Deputy Secretary of StateExecutive Sponsor

Ken Ortiz, Chief of StaffProject Sponsor

Patricia Herrera, Business Services Director

Project Stakeholder

Business Operations Subject Matter Experts

Stacy Starr-Garcia, Corporations Project

Stakeholder

Corporations Subect Matter Experts

Kari Fresquez, CIOBlesoo Varghese, Deputy CIO

Internal Project Managers

PCC Technology Group - Software Implementation

Vendor

John Salazar /Cathy Sisneros – Contract Project Manager

IT Operations Staff

Nicolas Behrmann - IV&V Vendor


ROLE RESPONSIBILITY NAME FUNCTIONAL

AREA

Business Services & Corporations

Subject Matter Experts

Define existing business processes; user acceptance testing

Christina EspinozaLaPriel DuranLea OrtegaJames PerezMarcella GallegosStacey Starr-GarciaRobert QuintanaErica ChambersPaul De HererraTeresa Otero

Business Services & Corporations Division

SOS IT Systems SOSKB systems expertise; system architecture implementation; IT operations

Kari FresquezBlezoo VargheseAubraMatthew

IT Division

PRC IT Systems CIS systems expertise Nanda Kumar IT Division

Executive Steering Committee

Manage Project Tasks, Responsibilities and Deliverables

Mary QuintanaKen OrtizKari FresquezChristina Espinoza

SOS Leadership Team

Project Management and Business Analysis

Provide project management and implementation oversight

John SalazarCathy Sisneros

Vendor – CSW Enterprises

Software Implementation Vendor

Complete software implementation deliverables

Raghu Chandra Vendor – PCC Technology Group

Software Vendor Executive Support Member

Manage Vendor Project Tasks, Responsibilities and Deliverables

Anand Balasubramanian/Vishal Hanjan

Vendor Leadership Team – PCC Technology Group

IV&V IV&V project validation deliverables

Nicolas Behrmann Vendor

PAGE | 72


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

5.5.1 PROJECT STAFF

ResourceCost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Ken Ortiz .4 Management Project Direction

Christina Espinoza .5 Management Project Direction

Stacy Starr-Garcia .5 Management Project Direction

Kari Fresquez .3 IT Management

Task Direction/workflow process/internal project manager

Blezoo Varghese .5 Application Development

IT sub-project tasks

Matthew .1 IT IT Sub-project tasks

Aubra .1 IT IT sub-project tasks

John Salazar .8 Project Management & Implementation Oversight

Project Management Deliverables

Cathy Sisneros .5 Project Management & Implementation Oversight

Project Management Deliverables

PCC Technology Group Software Vendor

1 Software implementation

Software implementation project tasks

Nick Behrmann– IV&V 1 IV&V Services

IV&V Deliverables

PAGE | 73


5.5.2 NON-PERSONNEL RESOURCES

Use this section to list services or product (HW/SW and such) needed for project. The resources identified below are required to support the project during the Testing Phase of the Project.


Estimated units/hours Availability Source Work Product/Deliverable

Production Application Servers1) In-House Filing,

E-Filing and Inquiry

06/01/2013 Dell PowerEdge R710 Server or equivalent with Windows Server 2012 Standard Edition

8 Core and 32 GB RAM

Production Database Server

1) In-House , E-Filing and Inquiry

Backup Database ServerIn-House, E-Filing and Inquiry

06/01/2013 Dell PowerEdge R710 Server or equivalent with Windows Server 2012 Standard Edition


Production Storage 06/01/2013 Existing, as specified in the RFP we assume NM SOS has adequate storage capacity.

Training Application Server and Database Server

05/01/2013Dell PowerEdge R620 Server or equivalent with Windows Server 2012 Standard Edition


QA/Testing Application Server and Database Server

05/01/2013Dell PowerEdge R620 Server or equivalent with Windows Server 2012 Standard Edition


PAGE | 74


Production Database Server

06/01/2013SQL Server 2012 Standard Edition.

Training Database Server

05/01/2013SQL Server 2012 Standard Edition.

Test Database Server 05/01/2013SQL Server 2012 Standard Edition.

Production SSL Certificate

06/01/2013Verisign or equivalent 128-bit

Training SSL Certificate

05/01/2013Verisign or equivalent 128-bit

Test SSL Certificate 05/01/2013Verisign or equivalent 128-bit

PAGE | 75


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

NM SOS will provide an office for the PCC Technology Group Project Manager at the SOS IT Facilities located in the basement of the Bataan Building. PCC Technology Group will also be bringing other staff members to New Mexico as required. These other individuals will share space with the PCC Project Manager, and or space will be made available in the IT conference room if the space is not allocated for other SOS agency functions.

The PCC Technology Group Project Manager will be on-site at the NM SOS facilities on a mutually agreed to schedule, and the schedule will be maintained and managed on the SOS Business Filing Dashboard. For the most part, PCC Technology Group will be supporting the Project with personnel housed in their headquarters in Connecticut.

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.


Estimated Hours Availability Skill Set Work Product/Deliverable

N/A

PAGE | 76


6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENTPMBOK©:

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

Issue: A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.

Both Risks and Issues can 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 agreed upon NM SOS/PCC approach embraces the concept of continuous risk management. Continuous risk management mandates that risk identification, monitoring, and mitigation be performed periodically throughout the lifecycle of the project. Risks are analyzed on an on-going basis to deal with changing conditions and priorities on the project. As new risks are identified, strategies and plans to deal with them are developed and executed.

The following principles of continuous risk management are integrated into the PCC approach:

Open Communication requires encouraging free-flowing information at and between all project levels, enabling formal, informal, and impromptu communication, and bringing unique knowledge and insight to identifying and managing risk.

Forward-looking View requires thinking toward tomorrow by identifying uncertainties, anticipating potential outcomes and managing project resources and activities while anticipating uncertainties.

Shared Vision requires arriving at mutual expectations based on common purpose, shared ownership and collective commitment by focusing on results.

Global Perspective requires viewing projects within the context of client peers and best practices, therefore being able to mitigate risks to the project due to external issues.

Integrated Management requires making continuous risk management an integral and vital part of project management by adapting its methods and tools to a project’s infrastructure.

PAGE | 77


Collaboration requires working cooperatively to achieve a common goal and pooling talent, skills and knowledge.

Continuous Process requires sustaining constant vigilance while identifying and managing risks routinely throughout all phases of the project life cycle.

Proposed Risks are presented to the NM SOS Executive Steering Committee for formal Recognition and Acceptance before Risks are documented on the PCC Risk Management Tool or the NM SOS Dashboard Tool.

6.1.2 PROJECT RISK IDENTIFICATION

Each risk identified will be documented in the Project Risk Assessment Summary Document. Project management will review and track the risks periodically. Risks will be regularly reviewed at weekly project status meetings, as well as the Project Steering Committee meetings when appropriate. In general, risks will be created and maintained by the Project Managers. Risks must have documented mitigations steps that can be followed if the risk is to be reduced or eliminated.

As the project proceeds through each project stage, and through the use of frequent communication meetings, the PCC and NMSOS Project Managers will identify specific risks associated with each stage. The project team leads will then review these risks and identify additional, more specific risks during the detailed work planning process. The consequences should be described as tangible or quantifiable impacts. Risk items will change during the course of a project. As the project team identifies new risks as the project progresses, and existing risks are successfully mitigated, it will be the project managers’ responsibility to ensure that the Risk Plan is up-to-date and that the progress on the mitigation activities are on course.

6.1.3 PROJECT RISK MITIGATION APPROACH

Each risk identified will have at least one mitigation action. These mitigations are designed to help avoid the risk.

The objective of this step is to identify cost-effective activities to reduce, contain and otherwise control project risk. There are two types of corrective risk action:

Preventive – involves modifying the project environment to minimize the identified risk. When risk situations are identified, alternative courses of action will be evaluated to determine if the undesirable outcome can be avoided at a reasonable cost.

Contingency – provides a buffer to address unanticipated events or known risks where preventive action is either unavailable or the cost of prevention is prohibitive. The Project Manager must determine that a contingency plan is realistic. The cost required to implement the identified actions should then be estimated.

PAGE | 78


6.1.4 RISK REPORTING AND ESCALATION STRATEGY

As mentioned above, the key to successfully mitigating the probability of risks from impacting the project is to continually assess the risk landscape and putting in place those actions that will limit the impact on the outcome of the Business Filing System Project. With this in mind, the process of monitoring and reporting on the status of these activities is a project-wide responsibility. The PCC Project Manager will be responsible for presenting the Risk Matrix at the status meetings with NMSOS, and for maintaining the Risk Management Plan as described below.

Risk Management Log

The Risk Management Log is created as an initial step during the project-planning phase, and is continually reviewed and updated by the PCC Project Manager. Risk status will be communicated regularly to the NMSOS Project Management Team as part of the project management process. The Risk Management Plan contains a task-based approach that:

Identifies the risk Addresses the severity and likelihood of the risk Constructs a risk mitigation plan for serious risks Evaluates and documents the status of the risk on an on-going basis

PCC makes every effort to ensure that the State’s Risks are documented, reviewed, tracked and handled effectively. However, if PCC’s operation does not produce the results the State needs or if the problem changes in risk level, the State can escalate the problem. It is the PCC team’s objective to be an excellent business partner, and it may be possible to reprioritize based on special needs, circumstances, or business opportunities.

PCC understands the importance of a well-defined risk escalation path. The escalation path will ensure executive support from both PCC and State for a timely mitigation or resolution of all the identified risks.

The risk escalation path shall consist of the following:Support Incident Escalation Contact

Initial Contact John Salazar

Initial Contact Raghu Chandra

PCC Executive Escalation Vishal Hanjan

State Executive Escalation Kari N. Fresquez

State Executive Escalation Ken Ortiz

PAGE | 79


6.1.5 PROJECT RISK TRACKING APPROACH

An integral part of a successful risk management and mitigation methodology is a sound and consistent means of classifying and prioritizing risks that are being analyzed. Risk classification requires that certain risk criteria be negotiated between project management and the stakeholder and user groups. These criteria will establish the limits that qualify the risk categories. The following tables present sample project risks and classification of these risks. Each risk will be assigned a probability of occurrence that will determine the mitigation strategy.

Classification Consequence Description – ImpactHigh Schedule Slippage – slippage in the schedule of a key deliverable or

milestone that is greater than or equal to two months.Cost Overruns – Cost overruns for the change that are equal to or exceed 10% of the agreed upon fixed cost for the named tasks.

Significant Schedule Slippage – slippage in the schedule of a key deliverable or milestone that is greater than one month but is less than two months.Cost Overruns – Cost overruns that are greater than 5% of the agreed upon fixed cost for the named tasks but are less than 10%.

Low Schedule Slippage – slippage in the schedule of a key deliverable or milestone that is greater than one week but is less than one month.Cost Overruns – Cost overruns that are greater than 2% of the agreed upon fixed cost for the named tasks but are less than 5%.

Negligible Schedule Slippage – slippage in the schedule of a key deliverable or milestone that is less than one week.

Classification Consequence Description – ProbabilityHigh (> 70%) Occurrence of this risk is very likely and may not be controlled by following

existing processes or procedure. In such cases exceptions are made and mitigating actions are expedited through the system.

Significant (40% to 70%)

Occurrence of this risk is likely. Mitigating actions may be effective if put into action immediately. This classification is most difficult to plan contingencies for, as likelihood of the risk occurring is not clearly understood.

Low (20% to 39%)

Occurrence is unlikely. Mitigating actions however are devised and are ready to implement if required.

Negligible (< 20%)

Occurrence is very unlikely. It is likely that mitigating actions and / or re-planning will avoid realization of this risk.

PAGE | 80


6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution Process

Given the size and complexity of the Business Filing System Project, issues and exceptions are certain to arise. An issue is used here as a generic term for an error that occurs or something that is unplanned. An Issue may also be simply an item important to the closure of a deliverable that needs clarification or investigation. The jointly agreed upon methodology between NM SOS and PCC approach ensures that issues are resolved as close to the point of origin as possible. This assures that the staff with the knowledge and skills required for resolving the issues efficiently are assigned ownership and exhaust all resolution options prior to further escalation. Effective Issue Management is a critical success factor for the management of a project.

As Issues are raised by project team members and stakeholders, Issues are managed to closure through a series of actions to resolve the issue. The Project’s issue resolution process documents, prioritizes and tracks issues that arise in a way that is efficient and easily accessible. The PCC and SOS Project Managers will jointly be responsible for the management of issues. The PCC and SOS Project Managers are responsible for monitoring issues to assure that issues are appropriately prioritized and assigned, and that status and resolution is being communicated in a timely manner. Key activities within the Issue Resolution Process include:

Documentation of the issue through its life cycle, from identification to resolution. Instituting procedures to identify and log issues proactively, while limiting redundancy or

ambiguity. Frequent review of the overall problem log as a proactive measure to identify trends or

patterns that may indicate risk. Ensure that appropriate agreement on issue resolution is obtained according to the project

guidelines for Acceptance, Change Control and Schedule Control outlined in this document.

6.1.6.2 External Issue Escalation and Resolution ProcessIssues are tracked through the use of the PCC on-line Testing Administration System (TAS) and the NM SOS Dashboard where documentation pertaining to the details of the issue, resolution, and any associated Change Request or action item, is managed. . An example of a TAS issue ticket is illustrated below:

PAGE | 81


Issues are assigned to a Use Case and Test Plan as a means to organize the issues into like categories. At the start of a project, issues with analysis and requirements definition are logged using generic categories until specific use cases have been identified. Various fields are available for tracking the full history of information on an issue, including the following:

Type of issue (error, enhancement request, etc.) Who reported the issue and when Detailed description of the problem and what testing criteria was used to generate it Who is assigned to resolve it and with what level of priority Where in the life cycle is the issue (status)? Comments related to resolution or clarification.

Search screens and printable problem logs allow testers and project leads to effectively monitor testing and issue management at any level throughout the project. Instructions or demonstrations on the use of the TAS tool will be provided to project participants as needed from the start of the project, but is an integral part of the kickoff of the Acceptance Testing Phase to assure success in Issues Management.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&VIndependent Verification and Validation (IV&V) means the process of evaluating a system to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the development organization. Describe the process that will be employed to meet IV&V requirements.

PAGE | 82


The Business Filing IV&V Contract was developed to include oversight of deliverables relating primarily to requirements being met and user acceptance testing being completed. Additionally, the Business Filing IV&V contract requires that IV&V vendor to validate that the project utilizes NM DoIT Project standards, methodologies and best practices. The Business Filing RFP requested a customizable COTS solution that will operate on existing NM SOS IT infrastructure reducing the need for IV&V in the areas of development methodologies or operating environment validation. Additionally, the Business Filing Project will utilize the services of a third party vendor to perform a thorough security assessment of the proposed software solution and the resident computing environment.

6.3 SCOPE MANAGEMENT PLANDescribe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations.

The following process will be followed if a change to the SOW is required.

A Project Change Request (PCR) will be the vehicle for communicating change. The PCR must describe the change, the rationale for the change and the effect the change will have on the project.

The designated Project Manager of the requesting party will review the proposed change and determine whether to submit the request to the other party.

Both Project Managers will review the proposed change and recommend it for further investigation or reject it. A PCR must be signed by authorized representatives from both parties to authorize investigation of the recommended changes. The investigation will determine the effect that the implementation of the PCR will have on price, schedule and other terms and conditions of the Agreement.

A written Change Authorization and/or PCR must be signed by authorized representatives from both parties to authorize implementation of the investigated changes. Until a change is agreed in writing, both parties will continue to act in accordance with the latest agreed version of the SOW.

6.3.1 CHANGE CONTROL

6.3.1.1 Change Control ProcessChange request initiated by the NM SOS:

A formal change control procedure is in place to monitor change requests to the original scope. The purpose of this procedure will be to analyze the impact of the change requests on the work schedule and cost. Changes to be implemented will be commenced only after agreement with any necessary changes in time and price or other obligations under the contract.

PAGE | 83


The change control procedure will begin with NMSOS or PCC logging an issue into the Testing Administration System and submitting it to the PCC Project Manager. PCC will make reasonable efforts to investigate the impact of any change on relevant obligations under the contract. PCC will inform the NMSOS Executive Steering Committee prior to conducting the investigation, if there will be any charges applicable to the investigation. If the NM SOS Executive Steering Committee approves a Change Request, the change request may result in revised schedule and additional price above the contract price. The schedule impact and additional cost, if any, will be determined by the PCC Team and submitted to NMSOS Executive Steering Committee for approval via an official Customer Change Request (CCR) document. Upon written approval of the change request, the PCC / NMSOS Executive Steering Committee will jointly prioritize the change request and assign it to the project team for implementation. If the parties cannot agree to the necessary changes to price, timetable, Statement of Work or other obligations under the subcontract, the change will not be implemented.

A change request could result from, but not be limited to the following:

Change in NMSOS requirements Additional work/deliverables not part of the Scope of Work as per Section 2

A change request could be initiated at any stage of the project. The cost and schedule impact may vary and may escalate as the parties proceed further on the project.

If the schedule change is to be implemented from PCC into the existing project, all deliverables affected by this change must be updated accordingly and revised baselines recorded. Also, the project plan must be updated to reflect any rework that must be done, including updating deliverables, re-coding, and re-testing.

In the event of delays outside of the PCC Team’s control, which materially impact the project schedule or price, the PCC Team will submit a change order in accordance with the Change Control Procedure. The PCC Team will immediately advice the New Mexico Business Filing System Project Manager of any anticipated delays and other schedule risks. The PCC Project Management Team will monitor delays.

Change request initiated by PCC:

Per Article 14 of the Professional Services Contract # 30-370-13-00014 between NM SOS and PCC, PCC must operate by the constraints of the Contract identified below:

A. Changes. Contractor may only make changes or revisions within the Scope of Work as defined by Article 2 and Exhibit A after receipt of written approval by the Executive Level Representative. Such change may only be made to Tasks or Sub-Task as defined in the Exhibit A. Under no circumstance shall such change affect the:

1. Deliverable requirements, as outlined in Exhibit A;

2. Due date of any Deliverable, as outlined in Exhibit A;

3. Compensation of any Deliverable, as outlined in Exhibit A;

PAGE | 84


4. Agreement compensation, as outlined in Article 3; or

5. Agreement termination, as outlined in Article 5.

B. Change Request Process. In the event that circumstances warrant a change to accomplish the Scope of Work as described above, a Change Request shall be submitted that meets the following criteria:

1. The Project Manager shall draft a written Change Request for review and approval by the Executive Level Representative to include:

(a) the name of the person requesting the change;

(b) a summary of the required change;

(c) the start date for the change;

(d) the reason and necessity for change;

(e) the elements to be altered; and

(f) the impact of the change.

2. The Executive Level Representative shall provide a written decision on the Change Request to the Contractor within a maximum of ten (10) Business Days of receipt of the Change Request. All decisions made by the Executive Level Representative are final. Change Requests, once approved, become a part of the Agreement and become binding as a part of the original Agreement.

In the event of delays posed by PCC, which materially impact the project schedule, the NM SOS Executive Steering Committee will consider a change order in accordance with the Change Control Procedure. Along with the Change Request, PCC will immediately develop an in-depth Change Request Analysis Report identifying the new proposed project schedule, anticipated delivery dates of impacted deliverables and justification as why the NM SOS Executive Steering Committee should not execute their right to terminate the contract by exercising their right to terminate via Article 16 Default/Breach of the executed Professional Services Contract. As per the contract terms, the NM SOS Executive Steering Committee will have up to 10 business days to make a decision to accept the Change Order or to Terminate contract.

6.3.1.2 Change Control Board (CCB)Insert a graphic or textual description identifying the Change Control Board (or function) for this project. The CCB may be an individual or group of individuals authorized to approve changes to the project plan.

PAGE | 85


The NMSOS Executive Steering Committee is the only body authorized to approve changes to the project plan, contract deliverables, or contract deliverable due dates, compensation amounts or other contract terms.

The Change Control Process Flow is shown in the following diagram:

Users Reviewer Status Assigned To

Users/ Stakeholders identify new

functionality or schedule change to existing

functionality Assigned to project

manager New-Unassigned Approve Request

CCB performs initial review of change request

PM Assigns to project team to

perform feasibility analysis

Assigned to project team for planning, design, coding,

testing

Implementation plan developed

Changes applied to production

Project manager closes

In Review

In Progress

In UAT

Approved

Closed

CCB performs detailed review of

analysis

Users perform UAT on new

functionality

Approve request

Approve request

No

No

Yes

Yes

Yes

6.4 PROJECT BUDGET MANAGEMENT

PAGE | 86


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

6.4.1 BUDGET TRACKING

Deliverables Estimated Budget(k=$1,000.00)

Actual Cost

Procurement Management Services $10.0k $10.0k

Security Assessment $11.0K $11.0K

Project Management Activities $145.0k

IV&V $50.0k

Software/Implementation $861.0k

Transition to Operations $50.0k

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

Project management control includes guidelines, policies, and procedures for team interaction, project team issue resolution, and project status reporting. It is the means by which the Project Team Members will give an account to the stakeholders and senior management of the status and progress made on the Business Filing System project.

The proposed organizational structure will clarify reporting guidelines and solidify a framework for communication, issue resolution, and status reporting. The project management concerns and information needs for effective control of project activities vary, thus specific control and reporting mechanisms are tailored to provide salient information regarding each of the goals of the agreed upon Project Management Methodology.

PAGE | 87


6.5.1 COMMUNICATION MATRIX

Communication will be primarily managed by the project manager using the project dashboard to assign tasks and deadlines to project team members. Status meetings with project members will be held weekly and email will be used for regular communication by team members throughout the week. Project Sponsor will inform executive sponsors of project status at least monthly. A detailed communication matrix is included in the attached project dashboard.

The table below illustrates the status reporting mechanisms, content of each report, and the recipients of these reports.

Reporting Method Content of Report

Frequency of Delivery

Recipients

Individual Staff Status Reports

Progress since last report Deliverables status Activities planned for next

reporting period Task level issues or risks to

schedule or work completion

Ad-hoc PCC/NMSOS Project Managers

Project Status Report

Progress since last report Deliverable and work product

status Activities planned for next

reporting period Team wide issues or risks

identified Pending or agreed upon Change

Management Items. Updated Project Plan/Schedule

Weekly PCC/NMSOS Management Team

Executive Level Status

Progress of project plan since last report

Status of deliverables and work products

Project wide issues or risks identified

Resource status report for current reporting period

Expected resource levels for next reporting period

Activities, work products,

Monthly NMSOS Business Sponsor, PCC Delivery Executive, PCC/NMSOS Management Team

PAGE | 88


Reporting Method Content of Report

Frequency of Delivery

Recipients

deliverables planned for next reporting period

Significant Change Management Activities.

6.5.2 STATUS MEETINGS

Project Team Status Meetings:

Conducted weekly to report on achievements from the previous report’s tasks and issues arising against the project plan. Topics may also include technical and development processes and adherence or changes to policies and procedures. Tasking for the upcoming report is reviewed and discussed as needed. These weekly meetings will be held by conference call when PCC representatives are not already onsite, subject to agreement by NMSOS. PCC anticipates being onsite for these meetings on the weeks when coupled with the Monthly Executive Oversight Meetings, whenever possible.

Includes: PCC Project ManagerNMSOS Project ManagerPertinent Project Team membersIV&V Vendor

Intra-Team Individual Status Meetings

These are Ad-hoc NMSOS or PCC specific team meetings geared towards the discovery and reporting of progress and issues related to the ongoing efforts by the business and technical support staff to meet project requirements.

Executive Steering Committee Oversight Meetings:

Conducted bi-weekly to provide status updates to the project stakeholders and obtain resolution/authorization for issues unresolved at the team management level. Adherence to plan and financial implications of pending issues are also discussed. PCC anticipates an on-site presence for these meetings whenever possible.

Includes: PCC Project ManagerNMSOS Project ManagerNMSOS IT ManagerNM SOS IT Staff MembersNMSOS Business SponsorSteering Committee MembersPCC Delivery Executive

PAGE | 89


IV&V Vendor

The Project Status Reports since the last meeting will be reviewed as the baseline for discussion.

6.5.3 PROJECT STATUS REPORTS

Team members will be responsible for preparing a weekly status report to communicate accomplishments, issues, risks, and work plans for the prior and upcoming week. The Project Manager will consolidate status and a project status will be completed each week. Monthly, the Project Manager will prepare the DoIT Monthly Status Report that will be forwarded to the SOS CIO on the ninth day of the month. The SOS CIO will forward the DoIT Monthly Status Report to the DoIT Project Oversight staff on the regular reporting schedule.

The weekly Project Status Report will be based on the agreed upon format, as illustrated below:

PAGE | 90


PAGE | 91


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.

The project management team members are providing the Executive Steering Committee members with Project Plans that identify the percentage completed for each task associated with project deliverables. These criteria are utilized to identify Deliverable Earned Value Metrics Information for the project.

6.7 QUALITY OBJECTIVES AND CONTROLOverall acceptance of a system requires not only acceptance of the specific application, but also validation of any interfaces within the scope of work. This section presents the system acceptance process for Business Filing System.

The key to effective and controlled testing is a well-defined test plan. A test plan is essential in that it defines what will occur in testing. It defines the strategy that has been adopted and the approach that will be taken in testing. The test plan shall address hardware, system software, application software, communications and networking facilities, individually or in combination. The test plan may be complex or simplistic, based upon the scope and levels of testing that are required. It should provide detailed answers to the following questions:

what is being tested;

why it is being tested;

how the testing will be conducted;

who will perform the testing;

when the testing will be done;

how success or failure will be determined;

what happens if it fails;

how / where to report findings; and

resolution of findings

Test plans are frequently developed well in advance of the execution of testing, as PCC believes that the generation of a test scenario is most accurate when the requirements that drive it have been recently obtained or documented. The test scenarios and test cases that are included may be

PAGE | 92


applied to different levels of testing (Unit, System, and User Acceptance) to ensure consistency in the approach to testing.

6.7.1 QUALITY STANDARDS

The NM SOS has agreed to utilize the existing PCC project methodology for ensuring quality standards.

PCC believes that testing of a solution at both the unit and system level and then under acceptance test criteria is a critical component of a successful implementation. PCC will submit test plans that will exercise all components of the system for review and written sign-off prior to execution. Acceptance Testing will begin upon written signoff that the test system is fully functional and the NMSOS is ready to begin the Acceptance period.

PCC utilizes a Use Case methodology for testing an application to ensure quality. Major functional areas of an application will be identified as Use Cases ( Business Registration , for instance). These will then be broken down into multiple, specific Test Case Scenarios that clearly lay the path for proving the Use Case Requirements have been met and the system functions in an acceptable manner. The construction of Use Cases will be based on the requirements documentation.

Issues and defects discovered during each testing phase are logged and monitored using PCC’s Testing Administration System (TAS).

Unit Testing

Each internal PCC developer performs unit testing as a unit of code is completed. This assures that obvious errors and defects within a single module or function are resolved prior to the testing at the System level. PCC will develop appropriate test cases to address all unit and sub-unit development. Unit testing will consist of individual tests as development work is completed. Each test case will comprise inputs, expected results, and actual results. Where expected results do not match actual results, steps taken and associated documentation will be recorded in the TAS System. The basis for the Unit Test will be the requirements stated in the Functional Requirements Document and specification refinements/changes made during the project in the form of Change Control. Unit test cases will be developed prior to the development of any code to ensure testing is not overlooked and developers understand the expectations for quality.

System Testing

System testing is the second phase of testing performed by PCC prior to release of the application to NMSOS for Acceptance Testing. The System Test Plan will contain a summary explaining the approach of the test and how it will facilitate testing all functional requirements of the application. Upon receiving approval of the test plan by the NMSOS Executive Steering Committee, system testing will be initiated.

PAGE | 93


The PCC method for developing the system test plan is to create a series of Use Cases based on NMSOS business processes. The business processes will be cross-indexed to the functional requirements defined during the project, ensuring that all identified requirements are included within the test.

Upon completion of the test, PCC will provide a deliverable to the NMSOS Executive Steering Committee summarizing the test results, detailed scripts of what has been performed, and a log of problems identified and the subsequent resolution via the TAS System.

Acceptance Testing

The Acceptance Test Plan is developed by PCC and provided to the NMSOS Executive Steering Committee for approval. Upon receiving approval of the plan, signoff on the completed System Test, and signoff on the installation of the Test Environment, the Acceptance Test period will be initiated.

PCC will use the System Test as the basis for the development of the Acceptance Test Plan. As discussed in the System Test section above, the Test Plan will consist of a series of Business Processes that, in sum, will cover all the business functions NMSOS users will be performing in day-to-day operations. For each business process, associated scripts will be developed that are cross-indexed back to the agreed-upon requirements. The test scripts will be comprehensively written to include input criteria, required response times, business rules, and expected results, to enable the NMSOS users to perform the test with minimal assistance.

PCC has found this approach to provide several key benefits. First, the approach ensures that all needed functionality required by the business unit is addressed. Secondly, the approach provides inherent training to participating NMSOS staff members, as they will be performing tests that are directly related to their day-to-day activities.

A PCC resource will be assigned as the Testing Coordinator for this effort. This coordinator will provide pre-test training, be on-site and available to answer questions from NMSOS staff during the critical first week of testing, monitor the TAS System to ensure proper escalation and tracking of items, and schedule re-tests as needed. The testing coordinator will also be responsible for communicating high-risk issues to the PCC Project Manager for dissemination to the extended project team.

Upon completion of the individual scripts, the tester will record the actual results in the test scripts. Where results are not acceptable, an issue will be logged in the TAS System. A NMSOS Testing Lead will validate that each issue submission is valid and make an effort to reduce the number of duplicates prior to submitting it to PCC. Upon submission, PCC will make all possible efforts to provide adequate turnaround for review and resolution, based on priority and impact to subsequent testing steps.

If at any point it is determined that resolution will not occur in time to assure that adequate re-testing, or testing of subsequent scripts, can occur in the testing time allotted, notification will be provided to the NMSOS Executive Steering Committee. This communication will include a summary of the issue and what steps are being taken for remedy, and act as a basis for

PAGE | 94


determining if the testing period shall be modified under the provisions for Acceptance laid out under the Business Filing System contract.

Upon completion of the Acceptance Test Phase, a summary of the results and the current issues log will be provided to the NMSOS Executive Steering Committee for signoff.

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS

PAGE | 95


Review Type Quality Standard Tools Reviewer Reports

Requirements Microsoft Word and Adobe Acrobat Reader

1. Gap Notes2. Updated Data Model3. Data Dictionary4. Functional Requirements

Document5. Technical Design Document

Plans Microsoft Project and Microsoft Word

1. Revised Project Plan2. Training Plan3. Conversion Plan

Milestones 1. Project Kickoff Completed

2. Detailed Project Plan Completed and Accepted

3. Development Environment Installation/Configuration

4. Gap Analysis Sessions Completed and Accepted

5. Data Model and Database Design Completed and Accepted

6. Requirements Documents Completed and Accepted

7. Technical Design Completed and Accepted

8. QA Plan Completed and Accepted

9. Training Plan Completed and Accepted

10. Data Conversion Completed

11. Application Customization Completed for Segment 1

12. User Acceptance Testing Completed for Segment 1

13. Gap Analysis Completed for Segment 2

14. Training Completed for Segment 2

PAGE | 96


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 Status meetings Weekly

Quality of communications Status meetings Weekly

Manages project tasks Status meetings Weekly

Productive Meetings Status meetings Weekly

Executive Steering Committee Meetings

Status meetings Bi-weekly or Monthly

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESSHow 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.

The following sections detail the process for submission and review of Deliverables during the life of the project/Contract.

1. Generala. When submitting a Deliverable for review and acceptance, the Contractor shall

produce one (1) master (both soft and hard copy, where applicable) and two (2) additional hard copies, if requested and where applicable, to the Procuring Agency Project Manager as identified in the Contract.

b. Once a Deliverable is approved and accepted by the Procuring Agency, the Contractor shall provide a final updated and corrected electronic copy. The Procuring Agency may, at its discretion, waive this requirement for a particular Deliverable.

c. The electronic copy shall be provided in software currently utilized by the Procuring Agency or provided by the Contractor.

d. Deliverables will be evaluated by the Procuring Agency under Quality Assurance.

2. Deliverable Submission

a. Prior to development and submission of each Contract Deliverable, the Contractor will submit a Deliverables Expectation Document ( DED ) containing a

PAGE | 97


description of the format and content of each Deliverable will be delivered to the Procuring Agency Project Manager for review and approval. The DED shall contain, at a minimum, the following:1) Cover letter outlining the purpose of the Deliverable;2) A Table of Contents with a brief description of the content of each section;3) Anticipated number of pages; and4) Identification of anticipated appendices/exhibits.5) The DED shall contain an approval/rejection section that can be completed

by the Procuring Agency. The DED will be returned to the Contractor within a mutually agreed upon time frame.

b. Deliverables shall be developed by the Contractor according to the approved format and content of the DED for each specific Deliverable. The DED is not an amendment of the Agreement, but is a roadmap for production of the Deliverable.

c. At a mutually agreed to meeting, on or before the time of delivery to the Procuring Agency, the Contractor shall schedule and provide a walkthrough of each Deliverable to be presented.

d. Deliverables shall be submitted no later than 5:00 PM, per the approved Contract Deliverable schedule and shall be accompanied by a Deliverable sign-off form with the appropriate sections completed by the Contractor.

3. Deliverable Review

a. General1) The Procuring Agency’s review time begins on the next working day

following receipt of the Deliverable.2) The Procuring Agency’s review time will vary by Deliverable, and will be

defined in the table at the end of this section or by Article 4 of the Agreement if not included in the table.

3) The Procuring Agency has up to _5__ working days to determine if a Deliverable is complete and ready for review. Unless otherwise negotiated, this is part of the Procuring Agency’s review time.

4) Any subsequent Deliverable, whose requirements are directly dependent upon a prior Deliverable, will not be accepted for review until the previous Deliverable has been accepted.

5) After review of a Deliverable, the Procuring Agency will return to the Contractor the project Deliverable sign-off form (attached to the end of this Exhibit) with the Deliverable submission and review history section completed.

PAGE | 98


b. Accepted1) If the Deliverable is accepted, the original Deliverable sign-off form

signed by the appropriate Procuring Agency representatives will be returned to the Contractor.

2) Once the Contractor receives the original Deliverable sign-off form, the Procuring Agency can then be invoiced for the Deliverable per the procedures set out in the Agreement.

c. Rejected - Comments/Revisions Requested by the Procuring Agency

If the Procuring Agency has comments and/or revisions to a Deliverable, the following will be provided to the Contractor:1) The original Deliverable sign-off form with an updated entry to the Deliverable

submission and review history section.

Attached to the Deliverable sign-off form will be a detailed explanation of the revisions to be made and/or a marked up copy of the Deliverable.

2) The Procuring Agency’s first review and return with comments will be completed within the times specified in the Agreement.

3) The Contractor will have fifteen (15) days, unless otherwise mutually agreed to, for review, acceptance and/or rejection of the Procuring Agency’s comments, and resubmission of the Deliverable.

4) A meeting (called by the Contractor) to resolve outstanding issues shall be completed within five (5) working days after completion of the Contractor’s review or a mutually agreed upon time frame.

5) Agreements made during meetings to resolve issues shall be documented and attached to the Deliverable sign-off form. Any such Agreements are not Amendments to the Contract. Amendments to the Contract shall follow the procedures set out in Article 25 of this Agreement.

6) Once an agreement is reached regarding changes, the Contractor shall incorporate them into the Deliverable for resubmission to the Procuring Agency.

7) All changes shall be easily identifiable by the Procuring Agency.8) Resubmission of the Deliverable shall occur within fifteen (15) days or a

mutually agreed upon time frame of the resolution of any outstanding issues.9) The resubmitted Deliverable shall be accompanied by the original Deliverable

sign-off form.10) The Contractor will have the opportunity to resubmit a Deliverable to the Agency

a minimum of three times per Article 4(c) of the Agreement.11) During the re-review process, the Procuring Agency may only comment on the

original exceptions noted, unless changes to the Deliverable cause new issues to arise.

12) All other items not originally commented on are considered to be acceptable by the Procuring Agency, unless changes to the Deliverable cause new issues to arise.

13) Once all revisions have been accepted, the original Deliverable sign-off form signed by the appropriate Procuring Agency representatives will be returned to the Contractor.

14) The Contractor shall provide one (1) updated and complete master paper, if

PAGE | 99


applicable, and associated electronic copy of each Deliverable after approval and acceptance by the Procuring Agency.

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

The project team will develop Configuration Management Criteria during the planning phase. Criteria will be reviewed with the Executive Steering Committee and project teams in order to inform/train them on the process.

6.8.1 VERSION CONTROL

Project documents are named with the version number identified in the naming convention and the version control page is updated on all project documents. All versions are maintained in the project repository.

PCC utilizes industry standard source code control software such as Visual SVN (Sub Version) for keeping track of all modifications to project source code files. The source code control software allows the user to:

1. Check-in and check-out source files and directories

2. Maintain versions and view differences between versions of files.

3. Maintains a change log history

4. Commit changes made in the local copy to the source code repository.

The source code promotion process is as shown below:

PAGE | 100


DEVELOPMENT & INTEGRATION

1. Shared environment for developer unit testing.2. Ensure unit tested code is successfully integrated into a single system

and signed off by the development lead.3. Signoff signifies code promotion to TESTING.

QUALITY ASSURANCE TESTING

1. Document results of each test and report findings to the developers describing the problems discovered during testing.

2. Ensure the system, documentation, and training materials have passed all tests within acceptable margins and have been signed off.

3. Signoff signifies code promotion to STAGING.

USER ACCEPTANCE TESTING

1. This phase is used for User Acceptance testing. Any problems identified during User Acceptance testing will be corrected and unit tested in the development system, which will then be used to recreate the User Acceptance test system.

2. Environment for Functional and Technical sign-off from Project Managers and End Users on a successful deployment.

3. Successful regression testing indicates deployment to PRODUCTION.

PRODUCTION Go-Live

PAGE | 101

Development & Integration

Quality Assurance

Testing

User Acceptance Testing Production

Code Promotion

Continuous Integration Build Process

Automated Build Process Build Versioning

Source Control (Visual Subversion)

Source Code Control

Software Configuration Management

Code Promotion

Code Deployment


6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY) Provide to the Department all project management and product deliverables. Deliverables shall include but not limited to the project plan, project schedule, initial and periodic risk assessments, quality strategies and plan, periodic project reports, requirements and design documents for entire project. The lead agency must make available all deliverables in a repository with open access for the Department to review information.

An agency-owned “Project Repository” has been established and is currently managed by NM SOS personnel, on SOS agency computing equipment, in order to ensure that the Agency is in possession and control of all project artifacts

6.9 PROCUREMENT MANAGEMENT PLANProjects often have some element of procurement, i.e. the requirement to purchase goods and/or services from outside the organization. The procedures to be used to handle these procurements should be included here. Activities such as a make-or-buy analysis; writing requirements; solicitation planning, evaluation and selection; inspection and acceptance; contract closeout should all be included.

Standard State of New Mexico procurement guidelines will be followed for all professional service contracts and the RFP required for this project.

PAGE | 102


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

7.1 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

Items that required administrative close: All deliverables as specified in this document must be completed and accepted. SOS must accept Deliverables, in writing. Deliverable Acceptance Form – for every formal deliverable in the phase, deliverable

acceptance form, must be signed and filed in the Project Workbook. Baseline Verification – Project deliverables should be inventoried and the project

archives updated with the current artifacts. Lessons Learned – Lessons learned sessions should be conducted after the phase/ project

and incorporated into future project plans, procedure, and artifacts. Lessons Learned activities were completed for Phase 1 in February 2015.

PAGE | 103


7.2 CONTRACT CLOSE

Contract close is similar to administrative close in that it involves product and process verification for contract close.In addition to the Administrative Closure, the following actions should be taken to complete Contract Closure:

Procurement Audit – The Project Manager, SOS CIO and Project Sponsor should review the vendor Agreement Terms and Conditions to ensure all items met requirements agreed upon by both parties.

Contract File Creation – A contract file, archiving all project and contractual documentation should be baselined and archived, including invoices, costs, and project documentation.

Formal Acceptance and Close – A document that accepts the contract completion and closure should be submitted by the vendor, accepted by SOS and filed in the Contract File.

ATTACHMENTSAttachments are included for additional information, but are not formally considered part of the Project Plan for approvals and change management purposes. Examples

Acronyms, abbreviations and definitions

Project Dashboard - Work breakdown schedule, Issues Log, Communication Matrix

PAGE | 104


APPENDIX A — DEFINITIONS

PAGE | 105


ACRONYMS AND ABBREVIATIONS OCIO Office of the Chief Information OfficerIPP Integrated Project PlanPMI Project Management Institute.PMBOK Project Management Body of KnowledgePMC Program Management ConsultantPMO Program Management OfficePMP Project Management PlanQM Quality ManagementWBS Work Breakdown Structure

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

Agency or Procuring Agency

The New Mexico Office of Secretary of State.

Agricultural Liens

The registration of a security interest in farm products by filing an Effective Financing Statement (EFS).

Apostille

The certification of a document that is attached to a notarized original document or a certified recorded instrument.

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]

PAGE | 106


Business Rules Engine

A software component that executes business rules that have been externalized from application code as part of a business rules approach, allowing the business users to modify the rules, frequently without the need of IT staff intervention.

Business Corporation, Corporation or Domestic Corporation

A corporation for profit subject to the provisions of the Business Corporation Act, except a foreign corporation.

Business Services Division or BSD or SOS-BSD

The Business Services Division of the New Mexico SOS.

Commitment

A pact that is freely assumed, visible, and expected to be kept by all parties.

Commercial or Configurable Off-the-Shelf or COTS

Software that is composed of pre-existing, proven components.

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]

PAGE | 107


Configuration Management Library System

The tools and procedures 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

The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.

Contract

Any agreement for the procurement of items of tangible personal property, services or construction derived from an RFP.

Crashing

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

The 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 that are 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

PAGE | 108


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.

Facsimile SignatureA signature by stamp or other device for an authorized officer, after filing with the SOS his manual signature certified by him under oath.

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.

Foreign Corporation

A corporation for profit organized under laws other than the laws of this state for a purpose for which a corporation may be organized under the Business Corporation Act.

Foreign Limited Liability Company

An unincorporated association; organized under the laws of another state or foreign country; Organized under a statute pursuant to which an association may be formed that affords to each of its members limited liability with respect to the liabilities of the person; and Is not required to be registered or organized under the laws of New Mexico other than the Limited Liability Company Act.

PAGE | 109


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.

Framework

A collection of computer source code that with modifications defined by the Agency shall meet the system requirements and specifications set forth in the RFP.

Full Time Equivalent or FTE

The ratio of the total number of paid hours during a period (part time, full time, contracted) by the number of working hours in that period Mondays through Fridays. The ratio units are FTE units or equivalent employees working full-time. In other words, one FTE is equivalent to one employee working full-time.

General Partnership (GP)

A general partnership is a partnership with only general partners. Each general partner takes part in the management of the business, and also takes responsibility for the liabilities of the business. If one partner is sued, all partners are held liable.

Integrated Project Plan

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

International Association of Commercial Administrators (IACA)

The professional association for government administrators of business organization and secured transaction record systems at the state, provincial, territorial, and national level in any jurisdiction which has or anticipates development of such systems.

Interface

The transmission of data that will allow for efficient and logical interaction with other applicable systems.

ITD or SOS-ITD

The Information Technology Division (ITD) of the SOS, which is responsible for pre-installation testing and approval of software.

PAGE | 110


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.

Limited Liability Companies, LLC, Domestic Limited Liability Company (DLC)

An organization formed pursuant to the provisions of the Limited Liability Company Act [Chapter 53, Article 19 NMSA 1978].

Limited Partnership (LP)

A partnership that includes both general partners and limited partners. A limited partner does not participate in the day-to-day management of the partnership and his/her liability is limited. In many cases, the limited partners are investors.

Limited Liability Partnership (LLP)

All partners in an LLP have limited liability, from errors, omissions, negligence, incompetence, or malpractice committed by other partners or by employees. Only individual partners involved in wrongful or negligent acts are personally liable, but other partners are protected from liability for those acts.

Limited Liability Limited Partnership (LLLP)

A limited partnership and as such consists of one or more general partners and one or more limited partners. The general partners manage the LLLP, while typically the limited partners only have a financial interest.

Method

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.

PAGE | 111


Non-technical Requirements

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

Notary public and Notary

Any person commissioned by the Governor through the SOS to perform official acts. A Notary Public is empowered to perform notarial acts.

Partnerships

Means an association of two or more persons to carry on as co-owners a business for profit formed under NMSA 1978, § 54-1A-202, predecessor law, or comparable law of another jurisdiction, and includes a registered limited liability partnership. Partnerships are either domestic or foreign. Domestic partnerships are partnerships organized under the laws of New Mexico. A foreign partnership is one that was organized outside New Mexico and authorized to do business in New Mexico.

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

Refers to the Business Filing System project.

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.

PAGE | 112


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.

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

PAGE | 113


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

The collection of plans that describes the Risk Management activities to be performed on a project.

Risk Management

Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

Scope Change

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

Service Mark

Any word, name, symbol, device or any combination of these used by a person to identify and distinguish the services of one person, including a unique service, from the services of other persons and to indicate the source of the services, even if that source is unknown: provided, titles and character names used by a person and other distinctive features of radio or television programs may be registered as service marks notwithstanding that they or the programs may advertise the goods of the sponsor - (NMSA 1978, § 57-3B-3(G))..

Service of Process

The procedure employed to give legal notice to a person (such as a defendant) of a court or administrative body's exercise of its jurisdiction over that person so as to enable that person to respond to the proceeding before the court, body, or other tribunal. Notice is furnished by delivering a set of court documents (called "process") to the person to be served.

SHARE”

The State of New Mexico’s PeopleSoft enterprise resource planning (ERP) system. SHARE combines the state’s accounting, human resource, payroll, and purchasing functions into an integrated statewide system. The Agency uses Share for its accounting system.

PAGE | 114


PAGE | 115


Software Life Cycle

The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation, and checkout phase, operation and maintenance phase, and, sometimes, retirement phase.

Stakeholder

Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.

System Enhancements

Agency defined modifications to the application systems to address legislative, processing or management mandates.

Subject Matter Expert or SME

An Agency employee with expert knowledge of a portion of the functional, operational or technical requirements of the Business Filing System.

Trademark ™

Any word, name, symbol, device, or any combination of these used by a person to identify and distinguish the goods of the person, including a unique product, from those manufactured or sold by others, and to indicate the source of the goods, even if that source is unknown - NMSA 1978, § 57-3B-3(H))..

Uniform Commercial Code (UCC)

A uniform act that harmonizes the law of sales and other commercial transactions in all 50 states. A UCC is filed when a commercial transaction involves a debtor and a secured party. The secured party (lender) files a UCC Financing Statement to protect their interest.

Workflow

An automated generation of steps within a defined process that routes information to the appropriate personnel so that each step within the process gets addressed and routed correctly to complete a process.

Work Products

PAGE | 116


The documented results of the Scope of Work activities developed and reviewed per the requirements stated within a Purchase Order. One or more work products collectively form a deliverable. Work products may include but not be limited to presentation materials, training presentations and/or related training materials, programming, system testing materials, system operating instructions and any other directly related documents.

PAGE | 117


Standard

Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development

Statement of Work

A description of all the work required completing a project, which is provided by the customer.

System Requirements

A condition or capability that must be met or possessed by a system component to satisfy a condition or capability needed by a user to solve a problem. [IEEE-STD-610]

Subproject

A smaller portion of the overall project.

Task

A sequence of instructions treated as a basic unit of work. [IEEE-STD-610]

A well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post conditions). (see activity for contrast.)

Team

A collection of people, often drawn from diverse but related groups, assigned to perform a well-defined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities.

Technical Requirements

Those requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.

Traceability

The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. [IEEE-STD-610]

Work Breakdown Structure

A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.

PAGE | 118