Executive Sponsor(s) – Dianna J. Duran, Secretary of … - SOSKB... · Web viewDue to the constitutional amendment passed in the 2012 general election and the subsequent passing

SOS BSOS BUSINESSUSINESS S SERVICESERVICES S SOFTWAREOFTWARE RREPLACEMENTEPLACEMENT 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 OWNER – PATRICIA HERRERA, BUSINESS SERVICES DIRECTOR

PROJECT MANAGER – KARI FRESQUEZ, IT DIRECTOR

ORIGINAL PLAN DATE: MAY 7, 2013REVISION DATE:

REVISION: 1.0

PROJECT MANAGEMENT PLAN FOR SOS BUSINESS SERVICES SOFTWARE REPLACEMENT 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.6 INITIAL PROJECT RISKS IDENTIFIED...........................................................................................................................2

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

2.1 STAKEHOLDERS......................................................................................................................................................62.2 PROJECT GOVERNANCE STRUCTURE...........................................................................................................................7

2.2.1 Describe the organizational structure – Org Chart.....................................................................................7........................................................................................................................................................................... 72.2.2 Describe the role and members of the project steering committee...........................................................8

3.0 SCOPE........................................................................................................................................................... 9

3.1 PROJECT OBJECTIVES..............................................................................................................................................93.1.1 Business Objectives....................................................................................................................................93.1.2 Technical Objectives..................................................................................................................................9

3.2 PROJECT EXCLUSIONS............................................................................................................................................103.3 CRITICAL SUCCESS FACTORS...................................................................................................................................10

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................11

4.1 PROJECT MANAGEMENT LIFE CYCLE........................................................................................................................114.1.1 Project Management Deliverables...........................................................................................................124.1.2 Deliverable Approval Authority Designations..........................................................................................194.1.3 Deliverable Acceptance Procedure...........................................................................................................20

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................204.2.1 Technical Strategy...................................................................................................................................214.2.2 Product and Product Development Deliverables......................................................................................214.2.3 Deliverable Approval Authority Designations..........................................................................................254.2.4 Deliverable Acceptance Procedure...........................................................................................................26

5.0 PROJECT WORK........................................................................................................................................... 26

5.1 WORK BREAKDOWN STRUCTURE (WBS)..................................................................................................................265.2 SCHEDULE ALLOCATION -PROJECT TIMELINE..............................................................................................................275.3 PROJECT BUDGET.................................................................................................................................................285.4 PROJECT TEAM....................................................................................................................................................28

5.4.1 Project Team Organizational Structure....................................................................................................285.4.2 Project Team Roles and Responsibilities..................................................................................................29

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................33

6.1 RISK AND ISSUE MANAGEMENT..............................................................................................................................336.1.1 Risk Management Strategy......................................................................................................................336.1.2 Project Risk Identification........................................................................................................................336.1.3 Project Risk Mitigation Approach............................................................................................................336.1.4 Risk Reporting and Escalation Strategy...................................................................................................336.1.5 Project Risk Tracking Approach................................................................................................................33

REVISION: 2.0 i OF vi


6.1.6 ISSUE MANAGEMENT..............................................................................................................................346.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V...........................................................................................356.3 SCOPE MANAGEMENT PLAN..................................................................................................................................356.4 PROJECT BUDGET MANAGEMENT............................................................................................................................37

6.4.1 Budget Tracking.......................................................................................................................................376.5 COMMUNICATION PLAN........................................................................................................................................37

6.5.1 Communication Matrix............................................................................................................................376.5.2 Status Meetings.......................................................................................................................................386.5.3 Project Status Reports..............................................................................................................................38

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................396.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................39

6.7.1 quality Standards.....................................................................................................................................396.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................396.7.3 Agency/Customer Satisfaction.................................................................................................................406.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................40

6.8 CONFIGURATION MANAGEMENT...................................................................................................................416.8.1 Version Control........................................................................................................................................416.8.2 Project Repository (Project Library).........................................................................................................41

7. 0 PROJECT CLOSE........................................................................................................................................... 42

7.1 Administrative Close...................................................................................................................................427.2 Contract Close.............................................................................................................................................43

ATTACHMENTS................................................................................................................................................. 43

APPENDIX A — DEFINITIONS................................................................................................................................. 44

Acronyms and Abbreviations............................................................................................................................45Definitions........................................................................................................................................................45

REVISION: 2.0 ii OF vi


REVISION HISTORYREVISION HISTORY

REVISION NUMBER DATE COMMENT

1.0 May 7, 2013 Initial PMP by SOS CIO

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

1.2 FUNDING AND SOURCES

PAGE | 1


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

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

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

PAGE | 2


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

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 IDENTIFIED

PAGE | 3


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

Risk 1

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.

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.


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

Risk 4

Description -

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


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.

Risk 5

PAGE | 4


Description -

Failure to identify all user requirements

Probability: MEDIUM Impact: Missed Functionality in Software Replacement SOW

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 6

Description -

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

Probability: HIGH Impact: Inability to fully complete project

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.

Risk 7

Description -

Underfunding in base budget for recurring support costs

Probability: MEDIUM Impact: Inability for agency to maintain software support after product enters production

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.

Risk 8

Description -

Difficulty with data conversion

Probability: LOW TO MEDIUM Impact: Project delays

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

Probability: MEDIUM Impact: Delay in providing services to the public

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.

PAGE | 5


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

KEN ORTIZ PROJECT SPONSOR SECRETARY OF STATE’S OFFICE

CHIEF OF STAFF

KARI FRESQUEZ INTERNAL PROJECT MANAGER

IT DIVISION CIO

IT OPERATIONS STAFF

IT IMPLEMENTATION AND ONGOING SUPPORT

IT DIVISION IT OPERATIONS STAFF

PATRICIA HERRERA BUSINESS SPONSOR BUSINESS SERVICES DIVISION

DIVISION DIRECTOR

BUSINESS SERVICE STAFF

BUSINESS USERS & SUBJECT MATTER EXPERTS

BUSINESS SERVICES DIVISION

BUSINESS OPS SPECIALISTS

JOHN SALAZAR PROJECT MANAGER CSW ENTERPRISES

PROJECT MANAGER

TBD – IV&V VENDOR IV&V DELIVERABLES

TBD IV&V CONTRAC-TOR

PAGE | 6


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

PAGE | 7


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

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

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

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.

PAGE | 8

Dianna J. Duran, Secretary of StateExecutive Sponsor

Mary Quintana, Deputy Secretary of StateExecutive Sponsor

Ken Ortiz, Chief of StaffProject Sponsor

Patricia Herrera, Business Services

DirectorProject Stakeholder

Business Services Subject Matter Experts

Kari Fresquez, CIOInternal Project

Manager

John Salazar – Contract Project Manager IT Support Staff

IV&V Contractor - TBD


2.3 EXECUTIVE REPORTINGExecutive sponsor(s) are included in the weekly project status meetings and are included on 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 OBJECTIVE 1

Improve user efficiency - Provide staff with updated technology so they may better serve public demand for information and services.


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


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.

PAGE | 9


NUMBER DESCRIPTION


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.

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

PAGE | 10


NUMBER DESCRIPTION

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 TBD

IMPLEMENTATION PHASE: DEVELOP\ IMPLEMENT

Software and Implementation Contract – Vendor TBD

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

PAGE | 11


4.1.1 PROJECT MANAGEMENT DELIVERABLES

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

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 related planning to certify the initiation phase of the project.

Deliverable Acceptance Criteria

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

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


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

PAGE | 12


incorporated into the preparation of the project charter.



Quality Review



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



PAGE | 13


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 all projects subject to oversight to engage an independent verification and validation contractor unless waived by the Department.


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


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


PAGE | 14


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.



Quality Review


PAGE | 15


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.



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.

PAGE | 16


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.


MS Project or MS Excel Format.

Quality Review

Weekly review by Project Team and Project Sponsors.


PAGE | 17


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

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.

PAGE | 18


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.

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 On project close

PAGE | 19


DELIVERABLE NUMBER


DATE APPROVED

& Agency CIO

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.

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

PAGE | 20


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

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.

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

PAGE | 21


PRJ-1 Design Documents Software Design Document/Vendor Proposal

Database Entity Relationship Diagrams


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


As defined in contract scope of work

Quality Review

Weekly status meeting with project steering committee

PRJ-2 Systems Specifications SOSKB System Specification/Vendor Proposal

Software Licenses

Data conversion specifications

Map business requirements to functional design

Software customization specifications



PAGE | 22




Quality Review


PEJ-3 Systems Architecture IT Infrastructure Diagrams – technical, application, and security





Quality Review


PAGE | 23


PRJ-4 System and Acceptance Testing

Functional software test plan - UAT





Quality Review


PRJ-5 Operations requirements Training Manuals

Business Process Diagrams



PAGE | 24




Quality Review


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.

DELIVERABLE NUMBER


DATE APPROVED

PRJ-1 Design Documents Project Team, Business Owner, and Project Sponsor

PRJ-2 Systems Specifications Project Team, Business Owner, and Project Sponsor

PRJ-3 Systems Architecture Project Team, Business Owner, and Project Sponsor

PRJ-4 System and Acceptance Testing Project Team, Business Owner, and Project Sponsor

PRJ-5 Operations requirements Project Team, Business Owner, and Project Sponsor

PAGE | 25


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.

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.

PAGE | 26


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

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

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

PAGE | 27


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

Phase / Activity Associated Deliverables Estimated Budget

Umbrella Tasks

Initiation & Planning Phase

Project Management ContractProject planProject ScheduleIV&V contract

$215.0

Implementation Phase

Software costsImplementation costsTraining costs

$1,000.0

TOTALS $1,215,000

PAGE | 28


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.

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

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

Kari Fresquez, CIOInternal Project Manager

TBD - Software Implementation Vendor

John Salazar – Contract Project Manager IT Operations Staff

TBD - IV&V Vendor


ROLE RESPONSIBILITY NAME FUNCTIONAL

AREA

Business Services & Corporations

Subject Matter Experts

Define existing business processes; user acceptance testing

Patricia HerreraLaPriel DuranChristina EspinozaLea OrtegaJames PerezMarcella GallegosStacey Starr-GarciaMaya OteroLouis RoybalErica Chambers

Business Services & Corporations Division

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

Kari FresquezBlezoo VargheseLaurin BeckhusenVincent McKenney

IT Division

PRC IT Systems CIS systems expertise Nanda Kumar IT Division

Executive Steering Committee

Manage Project Tasks, Responsibilities and Deliverables

Mary QuintanaKen OrtizKari FresquezPatricia Herrera

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

TBD Vendor – TBD

IV&V IV&V project validation deliverables

TBD Vendor – TBD

5.5 STAFF PLANNING AND RESOURCE ACQUISITION

PAGE | 30


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

5.5.1 PROJECT STAFF

ResourceCost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Ken Ortiz .4 Management Project Direction

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

Vincent McKenney .1 IT IT Sub-project tasks

Laurin Beckhusen .1 IT IT sub-project tasks

John Salazar .7 Project Management & Implementa-tion Oversight

Project Management Deliverables

TBD – Software Vendor Software implementation project tasks

TBD – IV&V IV&V Deliverables

5.5.2 NON-PERSONNEL RESOURCES

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


Estimated units/hours Availability Source Work Product/Deliverable

TBD during RFP

PAGE | 31


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.

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

None identified at this time

PAGE | 32


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.

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.

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.

6.1.4 RISK REPORTING AND ESCALATION STRATEGY

Ongoing monitoring tasks will be deployed including a monthly Project Management review of all identified risks. In this monthly meeting, all risks will be updated to reflect new developments or mitigation actions as well as next steps.

6.1.5 PROJECT RISK TRACKING APPROACH

To better track and define risks, the following procedures will be used. Identify risks as direct or indirect:

Direct risk: a risk that the project has a large degree of control over

PAGE | 33


Indirect risk: a risk with little or no project control

Determine the attributes of a risk: Probability of occurrence Impact on the project (severity)

The two can often be combined in a single risk magnitude indicator: High, Significant, Moderate, Minor, and Low.

For each identified risk, the following information should be documented and tracked: Number of Risk Direct / Indirect Risk Description of risk Risk Owner Status of risk Reported by Date Reported Target Date for Mitigation Probability the risk will occur (1-5: 5 = highest) Severity of the risk on the project (1-5: 5 = highest) Ranking of the risk (Probability times Severity)

Low = 1-8, Moderate = 9 – 19, High = 20-25 Mitigation actions to avoid or reduce the risk and/or the probability of occurrence Contingency actions to be implemented to minimize the impacts of the risk

6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution ProcessThis internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality. This process should be used for improving project processes as the project is executed and where the implementation of such improvements should not be postponed to Lessons Learned during Project Close.

Issues are tracked on project dashboard and discussed at weekly project status meetings.

6.1.6.2 External Issue Escalation and Resolution ProcessThe external process is provided for issues that involve project resources, processes, procedures, or methodology that cannot be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality.

Issues are tracked on project dashboard and discussed at weekly project status meetings.

PAGE | 34


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.

IV&V Contract will be developed to include oversight of deliverables relating primarily to requirements being met and user acceptance testing being completed. RFP seeks a customizable COTS solution that will operate on existing IT infrastructure reducing the need for IV&V in the areas of development or operating 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.

PAGE | 35


6.3.1 CHANGE CONTROL

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

6.3.1.2 Change Control Board (CCB)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.

The change control board authorized for approving changes to the project plan include the contract project manager, the SOS CIO, and the Project Sponsor.

PAGE | 36


6.4 PROJECT BUDGET MANAGEMENTCosts 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

Actual Cost

Project Management Activities $150.0

IV&V $65.0

Software $300.0

Implementation $650.0

Transition to Operations $50.0

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.

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.

PAGE | 37


6.5.2 STATUS MEETINGS

The project team will hold weekly meetings. The Executive Steering Committee will meet monthly for regular meetings and will be convened on a more frequent basis, as necessary.

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.

PAGE | 38


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 team will develop proposed metrics during the planning phase. Metrics will be reviewed with the Executive Steering Committee and ultimately passed to the Business Owners for management after system implementation.

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

6.7.1 QUALITY STANDARDS

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

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

The project team will develop quality standards during the planning phase. Standards will be reviewed with the Executive Steering Committee and ultimately passed to the Business Owners for management after system implementation.

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS

PAGE | 39


Review Type Quality Standard Tools Reviewer Reports

Requirements

Plans

Milestones

Testing

6.7.3 AGENCY/CUSTOMER SATISFACTION

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

Examples:

Areas of feedback When How Often

Agency awareness Status meetings Weekly

Quality of communications Status meetings Weekly

Manages project tasks Status meetings Weekly

Productive Meetings Status meetings Weekly

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 project manager will update this document to identify process of product delivery once the RFP process is complete and a contract has been awarded to the solution provider.

Deliverable Final Approval Process Customer Acceptance Criteria

PAGE | 40


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.

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” PROJECT OVERSIGHT PROCESS Memorandum.

A shared project repository is being maintained by the SOS CIO where all project documentation is stored.

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


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. Deliverables must be accepted by SOS, 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.

PAGE | 42


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


APPENDIX A — DEFINITIONS

PAGE | 44


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]

Assumptions

Planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here, or converted to formal risks.

Baseline

A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610]

Commitment

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

Configuration Management (CM)

A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE-STD-610]

PAGE | 45


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.

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

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.

PAGE | 46


End User

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

Effort

The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks.

Fast Tracking

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

Float

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

Formal Review

A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.

Integrated Project Plan

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

Lessons Learned

The learning gained from the process of performing the project. Lessons learned may be identified at any point during the execution of the project.

Method

A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.

Methodology

A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product.

Milestone

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

Non-technical Requirements

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

Performance Reporting

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

PAGE | 47


Procurement Planning

Determining what to procure and when.

Product Scope

The features and functions that characterize a product or service.

Project Leader (Technical)

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

Project Management

The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project Management is also responsible for the oversight of the development and delivery of the architecture and software project.

Program

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

Program Management Office

An organizational entity responsible for management and oversight of the organization’s projects. As a specific reference in this document, the Office of the Chief Information Officer.

Project Manager

The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project. The project manager is the individual ultimately responsible to the customer.

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.

PAGE | 48


Project Sponsor

The individual that provides the primary sponsorship for an approved project. This individual will play a key role in securing funding, negotiating for resources, facilitating resolution of critical organizational issues, and approving key project deliverables.

Quality

The degree to which a system, component, or process meets specified requirements.

The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610]

Quality Management

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

Risk

Possibility of suffering loss.

Risk Management

An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk Management includes risk identification, analysis, prioritization, and control.

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

Software Life Cycle

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

Stakeholder

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

PAGE | 49


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