crimevue integrated project plan web viewcv initial integratedprojplan_vfinalpage 1...

$: CRIMEvue Integrated Project Plan Web viewCV Initial IntegratedProjPlan_vFinalPage 1 Y:\Projects\CrimeVue\2_ProjMgmt\2.10 CV Signed Deliverables\Project Management\Initial Integrated$
EXHIBIT L – Initial Integrated Project Plan_vFinal_______________________________________________________________________

CRIMEvue Integrated Project Plan

CRIMEvue Project

Initial Version

December 23, 2014

document.docx Page 1

REVISION HISTORY

Date Version Description Author/Editor5/5/2014 V01 Prepare original draft. Linda Anderson

10/18/2014 V02 Updates generally Terri Barczak

10/26/2014 V03 Changes per team meeting review Linda Anderson

11/09/14 V04 Updates to Org chart, roles and Principal PM references Terri Barczak

11/22/14 Vo6 Updates to the Org Chart Terri Barczak

11/25/14 V07 Changes to scope, signatures and stakeholders Linda Anderson

12/23/14 Final Final Review and Change Acceptance Terri Barczak

EXECUTION/SIGNATURE BLOCKThe undersigned acknowledge they have reviewed and Approve the initial Integrated Project Management Plan for the CRIMEvue Project that covers the Initiation and Planning phase work. Updates will be made as the Project progresses. The Approval covers the standalone project control documents referenced herein. Changes to this Plan will be coordinated with and approved by the undersigned or their designated representatives.

APPROVALSDate Name Role

Major Mike Bloom

Signature:

Sponsor

Patricia Whitfield

Signature:

Business Owner

Captain Tom Worthy

Signature:

Steering Committee Member

David Alamein

Signature:

Steering Committee Member

Rebecca David

Signature:

Business Expert

Matt Oeder

Signature:

Business Lead

Terri Barczak

Signature:

Project Manager (Interim)


Table of Contents 1. Introduction....................................................................................................................5

1.1 Problem to Solve......................................................................................................................51.2 Project Purpose........................................................................................................................61.3 Reference to Other Applicable Documents..........................................................................6

2. Scope of Work................................................................................................................72.1 Overview...................................................................................................................................72.2 Project Management/Governance.........................................................................................8

2.2.1 Project Organization............................................................................................................92.2.2 Roles and Responsibilities...............................................................................................10

2.3 System Implementation........................................................................................................142.4 Organizational Transition......................................................................................................152.5 Deliverables............................................................................................................................152.6 Exclusions...............................................................................................................................182.7 Dependencies........................................................................................................................182.8 Assumptions...........................................................................................................................182.9 Benefits (updated after business case)..............................................................................192.10 Risk and Constraints.............................................................................................................19

3. Project Schedule..........................................................................................................203.1 High Level Schedule..................................................................................................................21

4. Project Management Plans.........................................................................................224.1 Resource Management.........................................................................................................224.2 Project Change Management..............................................................................................234.3 Issue and Decision Management........................................................................................23

4.3.1 Issue Management Process.............................................................................................244.3.2 Identifying the Outstanding Issue for Resolution...........................................................244.3.3 Documenting the Issue.....................................................................................................244.3.4 Resolving the Issue...........................................................................................................244.3.5 Recording the Resolution of the Issue............................................................................244.3.6 Decision Management......................................................................................................24

4.4 Communication Management – See sub-plan...................................................................254.5 Quality Management - See sub-plan...................................................................................254.6 Risk Management – see sub-plan.......................................................................................254.7 Procurement Management – see sub-plan........................................................................254.8 Requirements Management Plan........................................................................................25

4.8.1 Requirements Development.............................................................................................254.8.2 Requirements Development...............................................................................................04.8.3 Business Need and Project Objectives............................................................................04.8.4 Stakeholder Needs..............................................................................................................04.8.5 Identifying the Stakeholder.................................................................................................04.8.6 Collect and Document Needs............................................................................................04.8.7 Synthesize Stakeholder Needs..........................................................................................04.8.8 Requirements Definition.....................................................................................................14.8.9 Transform Needs into High-Level Requirements............................................................14.8.10 Evaluate High-Level Requirements...................................................................................24.8.11 Validate High-Level Requirements & Prioritize................................................................24.8.12 Requirements Analysis.......................................................................................................24.8.13 Assign High-Level Requirements to Requirement Types..............................................24.8.14 Determine Requirements Organization............................................................................34.8.15 Refine into Detailed Requirements...................................................................................3


4.8.16 Requirements Verification – Future Phase......................................................................34.8.17 Requirements Change Management – Future Phase....................................................44.8.18 Requirements Documentation Standards........................................................................44.8.19 Requirements Tools and Techniques...............................................................................4

4.9 Schedule Management...........................................................................................................44.10 Budget.......................................................................................................................................5

Appendix A – Project Organization Chart.......................................................................6Appendix B – Contact List.................................................................................................7Appendix C – Change Request.........................................................................................9Appendix D – RACI Template..........................................................................................11


1. IntroductionThe project management plan is a collection of plans which include scope, resources, schedule, change management, risk, communications, quality and process improvement, acceptance of deliverables, and budget, established to control the scope for the Oregon State Police CRIMEvue Project. This document is a foundation document for creating a common understanding and framework for project delivery among key stakeholders including the project team and project manager, the Legislative Fiscal Office (LFO) and the Department of Administrative Services (DAS), as well as State and Local Law Enforcement and regulatory stakeholders.

1.1 Problem to Solve The CRIMEvue database and LEDS message switch systems together are among the most mission critical systems operating 24 hours a day, seven days a week, 365 days a year, to ensure public safety under the stewardship of Oregon State Police (OSP). Every day, this critical system supports law enforcement and criminal justice entities in their performance of enforcement actions, aids prosecutors in the preparation and execution of criminal cases, guides court research of criminal history to arrive at appropriate sentencing outcomes, facilitates the recovery of missing persons, helps prevent unlawful firearm sales, and ties criminal justice systems together at the state and national levels through the exchange of data. Many Oregon non-criminal justice agencies utilize CRIMEvue data to perform applicant background checks for regulatory purposes such as employment, licensing or certification of personnel (either employed or volunteer) who work with children, seniors and other vulnerable persons. Other public safety regulatory uses include screening applicants for concealed handgun licensing and firearms purchase background checks.

The first component in this system, CRIMEvue, is a database repository with a set of application programs that maintain critical system-to-system interfaces and allows the processing of criminal and civil data collected by criminal justice and authorized non-criminal justice agencies in Oregon. This series of interfaces and databases serve as an electronic file cabinet for Oregon’s criminal justice information, providing up to the minute status of critical criminal justice record information. In some instances, it also serves as the means to provide county and statewide statistics for information such as concealed handgun licensing activity and specific arrest information tied to fingerprints. The CRIMEvue systems were procured and customized to fit the criminal justice system’s needs and was fully functional in 1996 (18 years ago). CRIMEvue provides data to the greater public safety community in Oregon, as well as, the FBI, the other 49 states, Canada, Mexico, Puerto Rico, Guam, and INTERPOL. Overall, CRIMEvue processes approximately 32 million transactions annually.

The second component of the system is the LEDS message switch, which acts as a message processor maintaining interfaces from Oregon’s criminal justice system, facilitating communications with the other states, territories and partner agencies such as The International Justice and Public Safety Network (Nlets), the FBI's Interstate Identification Index (III) and the National Crime Information Center


(NCIC). This component is the means by which Oregon criminal justice agencies communicate and share records with each other locally and nationally. Additionally, the message switch directs the traffic to CRIMEvue and to other law enforcement agencies throughout the state, country, nationally and globally. There are approximately 330 million messages that pass through the switch each year. The table below illustrates the files maintained within CRIMEvue that are also exchanged through the message switch.

Administrative Messages DMV Drivers Photos Restraining OrdersAgency Information Gun File Stolen PropertyArticle File Persons File Training HistoryBoat file Prisoner Transport Transaction LogsComputerized Criminal History

Prohibited Persons File (Mental Health) Vehicle File

Concealed Handgun License Protection Orders Wanted Persons

DMV Drivers Check Report Generators

1.2 Project Purpose

The purpose of the CRIMEvue Project is to replace legacy technology and make business process improvements that meet stakeholder needs and keep pace with technology.

1.3 Reference to Other Applicable Documents Business & Technical Complexity Assessment OSP Charter OSP CRIMEvue Requirements Matrix, Enterprise Strategy Alignment Agency Strategic Alignment Agency Business Plan ORS Alignment CJIS Security Policy 166-300-0015(11) Document Retention 257-015-0000 Purpose of Rules 257-015-0010 Authority 257-015-0020 Law Enforcement Data System (LEDS) Advisory Committee 257-015-0030 Definitions 257-015-0040 LEDS Responsibilities 257-015-0050 User Responsibilities 257-015-0060 Information Access and Dissemination


257-015-0070 System Security and Privacy 257-015-0080 Criteria for Terminal Access to LEDS 257-015-0090 Criteria for Revocation of Terminal and Informational Access

to LEDS 257-015-0100 Criteria for Computer Access to the LEDS Network 257-010-0010 Scope of System 257-010-0015 Definitions 257-010-0020 System Responsibilities 257-010-0025 Access to and Use of Criminal Offender Information 257-010-0030 Criminal Justice Research and Evaluation Projects 257-010-0035 Access by Individuals for Purpose of Review and/or

Challenge or Obtaining Fingerprints 257-010-0045 Violation of Rules 257-010-0050 Rights of Appeal 257-010-0055 Firearm Instant Check System 257-010-0060 Mental Health Information Reporting to NICS ORS 181.725 CJIS Advisory Board ORS 181. 036 National Crime Prevention and Privacy Compact FBI CJIS Security Policy FBI NCIC, III and NFF Qualifications and Requirements


2. Scope of Work2.1 Overview

The scope of technology and business improvements includes the following programs:

Business Programs TechnologyComputerized Criminal History Records Hosting may changeABIS Architecture improvementsStatewide CJIS Training Network SecurityLEDS Audit Unit Application serversCJIS Information Security CRIMEvue Application databaseUniform Crime Reporting (OUCR) FICUS ApplicationFirearms Unit (FICS) SOR DatabasesRegulatory Applicant Background Checks Sheriffs Transport databaseSex Offender Unit ORCACentral Records Unit Special reporting

OSP anticipates accomplishing the CRIMEvue Project with agency wide involvement and participation from approximately 36 internal and external staff resources, leveraging the expertise of key stakeholders such as the CJIS Advisory Board membership, utilization of the procurement avenues for both personal services contracts as well as software services and any hardware. It is anticipated that the use of 36 staff will be possible since the project will require small percentages of their time over the life of the project. The culmination of these methods will be coordinated through the use of strong project governance, contracted project management and business analyst services during the project. Business analyst services will be minimal, if required, during the operations and maintenance part of the project. OSP will ensure compliance and reduce risk during the entire lifecycle of the CRIMEvue Project by adherence to the stage gate process for IT Project Oversight requirements and the use of a Quality Assurance Contractor.

The work of the CRIMEvue project scope falls into three categories: 1. Project Management/Governance2. System Implementation 3. Organizational Transition

2.2 Project Management/GovernanceProject management and governance is the delivery structure around achieving the mission and goals of the project. The Project management approach for


CRIMEvue will be refined as the solution vendor is procured and may be traditional waterfall, agile or a hybrid of traditional and agile project delivery approaches.

To facilitate the management of the project, the CRIMEvue team will use multiple committees to ensure communication and decision making is effective, timely and efficient.

DAS Project Stage Gate – project risk and delivery approval Legislative Fiscal Office – project budgetary approval CJIS Advisory Committee – stakeholder identification and engagement,

training and buy in OSP Project Steering Committee – oversight of project management,

system delivery, procurement of COTS, and infrastructure hardware and implementation services, decision management

2.2.1 Project Organization

High Level


Steering Committee

2.2.2 Roles and Responsibilities

There are a number of governing bodies and roles needed for an effective and efficient decision making and delivery of a project. The Project will consist of a combination of State staff and contractors to achieve the project goals.

Role Project ResponsibilityProject Sponsor(Agency)

The Oregon State Police, Public Safety Service Bureau Major will act as the project sponsor for the Project. The Sponsor has the final approval of all deliverables and invoices that pertain to the Project.

Articulates the vision and provides overall direction and oversight to the project and ensures the project is in line with the program and department objectives.

Forms the project Steering Committee and chairs the Steering Committee, ensuring collaboration, seeking project commitment and guidance from committee members.

Reviews project progress, achievements, and issues.

Facilitates Steering Committee decisions and actions on issues that cannot be resolved by the Project Manager

Ensures that the managers of the organizational units most affected understand the project goals and benefits and are committed to the project.

Ensures that budget and resources are provided to the project to meet its goals and objectives.


Reviews and approves the Integrated Project Plan, including budget, and any adjustments, which delay milestone achievement.

Reviews and approves the project evaluation and lessons learned report.

Provide guidance and support to Project Manager(s) and Steering Committee on change management issues and their impact on the project

Steering Committee(Agency)

The Steering Committee is responsible for:

Oversight of progress on strategic goals and any strategy modifications relative to the project goals;

Review executive level project status updates including project issues and risks with Statewide impact;

Monitoring achievement of major Project milestones; Directing State resources to accomplish strategic goals. The Steering Committee meets monthly.

The Steering Committee Member must provide high-level project direction, receive project status updates, address and resolve issues, risks, or change requests. The authority of these members is high, should have delegated authority to spend funds for the division the member represents, must be able to make decisions that impact the member’s program and make recommendations for project sponsor decision making.

A key responsibility of the Steering Committee will be to participate in advising the Project Sponsor and in giving input to Project Change Requests. Change request will be presented to the Steering Committee via a Change Control Board (CCB) meeting. Formal requests to significantly alter the schedule, budget or scope shall be reviewed for potential adverse impact on the quality and timing of the Project. The CCB, led by the Sponsor, has the authority to approve or deny change requests after assessing the impact to the Project and organization. The authority of the CCB and decisions reached by the CCB are final and binding. The CCB is comprised of the Project Sponsor, OSP Chief Information Officer, Agency Project Manager, and Business Functional Manager. The PM Contractor will attend CCB meeting and act in an advisory (non‐voting) member of the CCB. The CCB meeting frequency will be determined as required during the Project.

CJIS Advisory Board(Multi-Agency)

The CJIS Advisory Board has many duties that are far beyond the scope of this project. With regard to this CRIMEvue project the CJIS Advisory Board shall:

1. Coordinate and communicate to and from the CRIMEvue Project team information among state criminal justice agencies.

2. Raise concerns, risks, issues, and provide an objective perspective for the CRIMEvue Project.

3. Ensure that in developing this project, data can be retrieved to support evaluation of criminal justice planning and programs,


including, but not limited to, the ability of the programs to reduce future criminal conduct.

4. Make recommendations to the Project which establish methods and standards for data interchange and information access between criminal justice information systems, in compliance with the technology standards and policies of the Oregon Department of State Police.

Principal Project Manager (Contractor)

The Principal Project Manager will provide strategic direction and maintain overall responsibility for all aspects of the Project and direct efforts relating to planning, management, communications, configuration management, change management, contract management, training, budget, and control of the Project.

The Principal Project Manager will manage and coordinate the efforts of the other members of the Project Team.

The Principal Project Manager will review and comment on all documents, reports, and deliverables in advance of submission to the Project boards for their review.

Other responsibilities of the Project Manager include:

Leading the development and delivery of foundational project management documents;

Preparing the deliverables of the Project Manager Contractor; Organizing, managing, and controlling all aspects of the

development and implementation effort; Presenting information as required to the Steering Committee; Coordinating formal communication with the Business

Transition Lead, Project Team and others as defined in the communication plan.

Facilitates the development of the project plan according to the project charter, i.e. plans for scope, staffing, communications, WBS, schedule, budget, change, issues, QA, and risk.

Project oversight includes quality review of COTS Project Manager and Business Analysis deliverables and ensuring that the agency needs are met per the intent of the scope of work.

Acquires staff and other resources through assignment negotiation, attaining and posting positions, or developing a plan to procure staff and other resources.

Sets standards for project management including timeline and budget, scope, change, issue and risk management

Serves as a point of escalation for issue resolution between vendors and business users

Oversees contract and project closeout activities, and archives project information

The Principal Project Manager will guide the flow of information to


and from Project stakeholders and as outlined in the Communications Plan, coordinate the development of outreach materials such as brochures, videos, posters, media packets, etc. with the Communications Manager, to provide information about the development and implementation of the modernized System as well as to preview its functional capabilities.

Solution Implementation Project Manager (Contractor)

The Solution Implementation (SI) Project Manager will assume primary day‐to‐day responsibility for implementation of the software. The Project Manager will also provide leadership to State and contract staff assigned to the Project, and in coordinating switch implementation and system interfaces with the agencies as well as other departments.

The SI Project Manager responsibilities include:

Maintaining a project schedule on the software tasks, activities, and deliverables;

Ensuring Project compliance with applicable regulations;

Development of the SI project plan according to the project charter, i.e. plans for scope, staffing, communications, WBS, schedule, budget, change, issues, QA, and risk.

Acquiring staff and other resources through assignment negotiation, attaining and posting positions, or developing a plan to procure staff and other resources.

Manage the technical implementation of COTS package

Business Lead The Business Lead provides leadership to the subject matter experts and possesses an in depth understanding of the daily operations of CRIMEvue and affected staff.

Provides daily decision making for business analysis related operational process questions, organizational and legal impact assessments.

Oversees accuracy and relevancy of system and operational requirements and participates in prioritizing requirements.

Strives to get collaboration from internal and external stakeholders in field and buy in to conduct organizational transition work.

Provides the leadership and vision around the end state fore the Business Transition work, including analysis of the impact on the OSP environment, staff operations, internal politics, staff job classifications, culture, and policies.

Validates the results of analysis of policies and operational procedures and in evaluating the impacts on policies of implementing the CRIMEvue system;

Manages business resources across units and stakeholder management activities, training activities, testing acceptance and


stakeholder communications.

Validates future business workflow assessment, ensuring that processes are standardized and ensures communications around the new standard processes are effectively communicated to staff and management involvement.

Provide advice and council to Project Manager(s) and Sponsor on organization transition issues and their impact on the project.

Organizational TransitionLead(Agency)

The Organization Transition Lead provides leadership and coordination to the business team related to organizational change activities as they transition the internal and external stakeholders to the new environment and system operations. Provides guidance and advice to the Business Lead and other subject matter experts.

Provides daily monitoring and guidance on approach and output on business transition activities related operational process questions, organizational and legal impact assessments.

Guides team in defining accuracy and relevancy of change activities.

Strives to get collaboration from internal and external stakeholders in field and buy in to conduct organizational impact and readiness assessments

Oversees Business Transition Planning, including analysis of the impact on the OSP environment, staff operations, internal politics, staff job classifications, culture, and policies.

Leads the review and analysis of policies and operational procedures and in evaluating the impacts on policies of implementing the CRIMEvue system;

Monitors activities of business resources across units and stakeholder management activities, training activities, testing acceptance and stakeholder communications.

Guides creation of future business workflow assessment, ensuring that processes are standardized and ensures communications around the new standard processes are effectively communicated to staff and management involvement.

Provide advice and council to Project Manager(s) and Sponsor on Business Lead on organization transition issues and their impact on the project.

Technical InfrastructureLead(Agency/Contractor)

The Technical Infrastructure Lead provides input to specifying modernized system hardware and software components and their integration into the OSP architecture plan. Assists in identifying requirements and constraints on the modernized switch hardware and software and their integration into the existing infrastructure and communications network. Assists in the resolution of technical design issues and the documentation of the requirements and preferences articulated by the technical design team.


The Technical Infrastructure Lead provides input during the technical design and development tasks including the initiation, design review, test plan review, unit testing results review, and maintenance of all technical design documents. Provides feedback in estimating the System load and specifying the necessary performance requirements for operational memory, computing power and data storage. Reviews the identification of needed hardware, software, and communications components for development testing, training and production operations and confirms the procurement steps to be taken to authorize and affect the purchase, delivery and installation of these System components as well as the associated maintenance arrangements.

Technical Integrations Lead(Agency/Contractor)

The Technical Integration Lead provides input and leadership in establishing interfaces to the existing organizational entities that use the CRIMEvue system.

Assists in the resolution of technical design issues and the documentation of the requirements and preferences articulated by the technical design team.

Provides feedback in estimating the dataflow constraints, data load specifications and specifying the necessary performance requirements for operational memory, computing power and data storage.

Reviews the identification of needed hardware, software, and communications components for development testing, training and production operations and confirms the procurement steps to be taken to authorize and affect the purchase, delivery and installation of these System components as well as the associated maintenance arrangements.

2.3 System ImplementationThe project has two key technology solution delivery phases: CRIMEvue system and Law Enforcement Message Switch (LEMS) and interface/integration. Initially, the decision was made to implement the CRIMEvue software changes, gain full acceptance and ensure a stable environment prior to making any LEMS changes. Planning for the LEMS can occur prior to the completion of CRIMEvue, however, due to the mission critical nature of the LEMS functions the two must not be executed in parallel.

CRIMEvue software will precede the LEMS for a successful implementation. In addition, the hosting of this project and the architecture design is still being determined in collaboration with DAS ETS. For planning purposes, a preliminary hosting budget has been quoted by DAS ETS, which will be redefined when a particular vendor solution is known.

Much in the same way as the project delivery approach, the CRIMEvue system implementation approach will be an agile / iterative development and structured


waterfall approach for the LEMS infrastructure implementation. The project is favoring the use of product owners and their artifacts of backlogs, release planning, sprint planning will enable the system delivery to be flexible and responsive to OSP business needs during an extended release cycle. A structured infrastructure implementation following well established industry standard practices will provide the OSP with a reliable, scalable, available system.

2.4 Organizational TransitionPURPOSE

OSP is initiating a highly visible and potentially significantly impactful project anticipating the involvement of a COTS Implementation and infrastructure replacement of a mission critical system. Preparing the organization to effectively use this new system requires that management also consider the operational impact on front line business staff internal to OSP as well as external Partners. Assessing, planning for and address operational impact is part of Organizational Transition. Organizational transition examines from the business perspective the external and internal organizational readiness of taking on a specific system implementation.

APPROACH

The approach to assess the organizational readiness involves defining a plan to explore the likely impacts on staff, management, communications, processes, workflow, culture, and other factors that a new computer based system would have on OSP and its external partners. A subset of the CRIMEvue project team will participate in this work. Team members assigned will need to be familiar with the operational processes of criminal history and hot file systems. Key Deliverables

1. Organizational Transition Plan, an approach, timing, resourcing and task plan

2. Entity Assessment Template, assessment tool to gain insight on impact on an organization

3. Assessment Report, where the impacted external and internal entities document their own assessment, noting findings, gaps and areas of improvement needed.

4. CRIMEvue team will work with those same entities to produce a Response plan. Key to success will be leveraging the COTS vendor expertise from previous implementations and lessons learned, as well as a gaps analysis of As Is and To Be process documentation, a Requirements analysis as well as feedback collected from surveys, in person interviews and information from a formal Assessment form. The survey materials and the Assessment template will address readiness impacts in these areas: Culture, Infrastructure, IT support, Leadership, Operations, Staff and Officers, Strategy, Workflow


2.5 DeliverablesProject phase & stage gate

Deliverable Responsible Accountable Consulted Informed

Initiation Business Technology Complexity Assessment

OSP OSP DAS DAS, LFO, OSP

Initiation Charter OSP OSP DAS, LFO DAS, LFO, OSP

Initiation Stakeholder Register OSP OSP DAS, LFO DAS, LFO, OSP

Planning Project Management Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Scope Management Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Scope Statement OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Communications Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Detailed Release Plan, (High Level Needs)Requirements Traceability Matrix

OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Requirements Management Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Project Organization – Staffing Plan in the Project Management Plan

OSP DAS, LFO, OSP

DAS, LFO, OSP

DAS, LFO, OSP

Planning Schedule Management Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Project Schedule OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Responsibility Matrix OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Organizational Transition Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Roles & Responsibilities OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Initiating/Planning

Cost Estimates and Budget baselines OSP DAS, LFO, OSP

DAS, LFO, OSP

DAS, LFO, OSP


Project phase & stage gate


Planning Change Management Plan – located within the Project Management Plan

OSP DAS, LFO, OSP

DAS, LFO, OSP

DAS, LFO, OSP

Planning Issue Management Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Quality Management Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Procurement Management Plan OSP OSP,DAS

DAS, LFO, OSP

DAS, LFO, OSP

Planning Risk Management Plan OSP OSP,DAS

DAS, LFO, OSP

DAS, LFO, OSP

Initiating/Planning

Business Case OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Work Breakdown Structure (WBS) OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning/Monitor/Control

Project Logs OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Monitor/Control

Status Reports OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning/ Executing

Architecture Diagrams OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Executing

Organizational Assessment Template and Surveys


DAS, LFO, OSP

Planning Executing

Systems Requirements Specifications OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning/ Executing

Procurement documents – RFP, Statements of Work, and deliverable acceptance forms. etc.

OSP OSPDAS

DAS, LFO, OSP

DAS, LFO, OSP

ExecutingMonitor/ Controlling

Organizational Assessment Response Plans


DAS, LFO, OSP

Planning/ ExecutingMonitor/ Controlling

Test Plan & Test Cases OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Implementation Plan OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Planning Training Plan OSP OSP DAS, LFO, DAS,


Project phase & stage gate


OSP LFO, OSP

Monitor & Control

Training Events and Materials OSP OSP DAS, LFO, OSP

DAS, LFO, OSP

Closeout Lessons Learned surveyProject Closure Report


DAS, LFO, OSP

2.6 Exclusions Excluded from the scope of the project

Overseeing implementation of organizational readiness response plan delivery of External Agency

Budget for implementation of organizational readiness response plan delivery of External Agency

Create or deliver external agency or entity specific training or onsite training. Facilitate defining and updating administrative rules or policy changes.

2.7 Dependencies Dependencies of the scope

Any OAR or ORS changes will need to be monitored and those changes will be incorporated into the business rules and workflow of this new system implementation.

Fiscal impact of bills or other funding changes may impact the project delivery and will need to be reviewed and a response defined.

Availability of vendor of the quality and level of expertise to deliver the mandatory requirements of the CRIMEvue system at an achievable price.

Availability of staff and environment of the State Data Center for a locally hosted system to meet the technical requirements.

DOJ, DAS and OSP Procurement staff availability to meet timelines of deliverables.

2.8 AssumptionsGeneral Project Assumptions

The priority of the project will remain a high priority for all project team members, advisory boards, key stakeholders, steering committee, and sponsor.

Project delivery progress assumes continued support and responsive participation, and cross agency collaboration between OSP and other public safety agencies, Department of Administrative Services Enterprise Technology Services and Office of the State CIO, DOJ, the Legislative Fiscal Office related to the timelines for review and incorporation of comments as well as necessary approvals.


Project delivery assumes internal, external and contract vendor resources being available to deliver the required business case analysis, alternatives, cost benefits and other supporting materials required for the business case

Project delivery assumes the continuous development of relationships with consultant/vendors.

It is assumed that there will be strong stakeholder buy-in and long-term support for this work/project.

It is assumed that many project stakeholders are working in parallel paths however they are not co-located or may not be aware that their work is related to this project. This can present communications problems and duplicate efforts.

It is assumed that due to the tight deadline this project will require focus and dedication to minimizing scope creep and meeting stated milestones.

Project delivery assumes the proposed solution is technically feasible and politically expedient.

Project Scope Assumptions

The scope of the CRIMEvue Project assumes the following to be true: By implementing CRIMEvue software in advance of the LEDS message switch

infrastructure replacement that connectivity and integration risk is minimized. Implementing an existing proven COTS package will minimize gaps in

functionality and reduce risk of defects and lack of interoperability with federal, international and national/state interfaces.

The COTS system will go live with key mandatory functionality that is currently in use in the legacy system.

OSP has primary decision making responsibility and authority related to determining which of the business functionality is mission critical for implementation and the timing of that implementation.

2.9 Benefits (updated after business case)The project anticipates that the following measurable benefits will result from implementing the CRIMEvue system.(below are examples)

Speed of information sourcing for organizational decision making will improve by reducing use of manual reporting by XX%.

Speed of information delivery out to field officers will improve by xx% Improvement of information warehousing and report archiving by … More intuitive and standardized system that reduces the training delivery time of

new staff by XX%.

2.10 Risk and ConstraintsThe CRIMEvue current understanding of the project risks and constraints are below. Ongoing risks and constraints can be found in the online GovSpace site.


Risk Category Risk Description

Business/ Organizational External and internal stakeholder buy in to the solution approach, timeline or priority may be low, resulting in the need for more OSP and CRIMEvue team resources and budget to address increased communication and education efforts.

Business/

Organizational

Lack of understanding or attention given to addressing environmental, operational, communication and political impacts on internal and external stakeholders from introducing the new system and possibly altering existing operational practices and decision making routines.

Business/Organizational

Going live with no less functionality than current system. Oregon has specific requirements that need to be addressed and not missed with any new application.

Project Loss of key project team member to higher priority work, personal issues, or other cause, impacting project delivery pace due to loss of key business or technical knowledge, information sharing, and product knowledge.

Project Selected COTS vendor or infrastructure vendor goes out of business or fails to perform, impacting project delivery pace due to loss of key technical knowledge, information sharing, and product knowledge.

Project Project loses budgetary approval or funding is shifted to higher priority projects, operations, etc. impacting project delivery pace and possibly causing termination.

Project Stakeholder support and communication could have a negative impact on the project if not managed.

Technical Catastrophic failure of the existing hardware, requiring a speedier replacement timeline and potentially larger budget for expedited services and materials.

Technical & Business/Organizational

Training will be a challenge for stakeholders.

Technical & Business/Organizational

Resistance or unwillingness to change to new system or upgrades.

Project The budget may be a risk to this project since it is not fully estimated.

Project The political landscape has to be approached with care regarding large, complex, and high risk IT projects as well as the political impact to stakeholders.

Project Staffing internally may be a risk due to current workload and competing priorities for IT Staff

Business/Organizational If the replacement of the UI is delivered by OSP this could be viewed as competitive with the vendor community.

Business/Organizational The development, delivery and understanding of what are the requirements for training - organizational change as well.

Technical OSP is not sure of the best deployment strategy, all at once, phased, on-off-switch.

Business/Organizational Subject Matter experts & Business staffing resource deficiencies. Potential


Risk Category Risk Description

for staff getting new assignments, leaving the agency, or other absences from the project.

Project Change to project managers presents a risk to the success of the project.

Project Timeframe to procure professional services may impact planned timelines.

3. Project ScheduleThe project schedule will be managed in SmartSheet and will be defined during the Planning phase. The high level timeline is depicted below.


3.1 High Level Schedule


4. Project Management Plans4.1 Resource ManagementThe resource management plan is the efficient and effective use of OSP and other key stakeholder resources when needed to successfully execute the project’s goals. The project expects to use resources and staff within OSP, ODE, DAS, LFO, and key external stakeholders. OSP, DAS, and LFO provide communications and strategic alignment at the executive level. All of the identified resources for this phase of work are identified in the team roles and responsibilities. Once the high level timeline and task list (work breakdown structure WBS) is finalized and the project is underway, the identified resources will be utilized as needed for key decisions, communications, risk mitigation and to aid in the execution of the project. The resource allocation will be an ongoing exercise over the duration of the project as priorities shift or changes in staff occur for the additional phases based upon approval of the business case and selected alternative and vendor.

At a minimum the Project team will create two RACI role and responsibility matrices. The first related to the overall executive governmental body decision making activities and the second related to the project delivery “hands on” activities that would include the OSP technical and business staff as well as law enforcement community and system implementation vendor staff. The project delivery matrix will also go through two phases one for the CRIMEvue application implementation and one for the LEDS switch infrastructure implementation. Due to the length of the expected project timeline, these RACI matrices will undergo evaluation and update every six months or as significant changes are made to the team. See Appendix D for the RACI Template.

It is recommended that time management for OSP resources be tracked as part of the estimated cost for this project. Time tracking will enable OSP, DAS and LFO stakeholders to gain insight into complexity and actual cost of the project. This is an additional workload for project leadership but having the ability to clearly communicate and report on time is a best practice for project delivery and is encouraged in all organizations. OSP resources may use a variety of time reporting tools but it is recommended that a standard form be employed to make the time management for this project more manageable. See Appendix D for example RACI Template.

4.2 Project Change ManagementProject change management is how this project will manage changes that will impact the scope, schedule, quality and budget of this project. The project team will perform analysis of the proposed change to determine the effect on meeting the project goals, and whether the change can be incorporated into the existing project quality, scope, budget and timelines. Most changes to scope that do not alter significant timelines or stage gates or do not impact the budget may be handled informally in the project status meeting with the analysis being via group discussion. Should the proposed change impact budget or significant timeline (release) dates or project delivery stage gates will be formally documented and presented for approval to the project steering committee.

Change control will include changes to the following: Project Charter


Integrated Project Plan and any associated sub-plans (also called the Statement of Work)

Project Schedule Project Budget Project Needs Assessment Requirements Traceability Matrix Systems Requirements Specification Other Project Management artifacts

Formal Changes will use the Change Request Format at the bottom of this section and will be submitted to the project manager via email for further review. Anytime there is a formal change request the change information will be filled out either by the project manager or the person making the change request. This formal change will be approved by a sponsor or project lead.

4.3 Issue and Decision ManagementThis section involves defining a plan that includes (1) a method to identify and analyze issues impacting project progress and (2) a means to achieve and document the planned resolution and decisions, and (3) a means to request any needed changes to the project, document and evaluate the change request, and document the decision.

An Issue and Decision Management log will be developed and used to appropriately identify, communicate and resolve and record issues, changes and decisions made during the course of the project. Below is a summary of the principal steps of issue management. A full issue management plan is found in attachment J.4.3.1 Issue Management ProcessThe objective of Issue Management is to provide a method to identify and resolve the issues that could impact the scope, schedule, cost or quality of the project.The following is a simple summary of the issue management process is:

Identifying the outstanding issue for resolution Documenting the issue Logging the issue for tracking Resolving the issue Recording the resolution of the Issue

4.3.2 Identifying the Outstanding Issue for ResolutionAny member of a project may identify a potential issue. Once an issue is identified, the Project Manager will make sure that it has not been addressed before and then decide the path to take for resolution. Some issues can be addressed and resolved without formal documentation, but many require a more formal approach for resolution. 4.3.3 Documenting the IssueAfter an issue has been identified, it becomes necessary to document it. The Issue log is filled out to document the outstanding issue. The Project Manager will enter the issue into an Issue Log for tracking. 4.3.4 Resolving the Issue


The Project Leadership Team (Sponsor, Project Manager, Business Lead) will prioritize the outstanding issues and assign a resource to resolve it. That resource will determine the measures necessary to reach a solution and provide a target resolution date. It may be necessary to involve other resources to implement the identified measures to resolve the issue. If the issue cannot be resolved, or if the impact is greater than originally determined, it may be necessary to bring it before the project steering committee for review before continuing.4.3.5 Recording the Resolution of the IssueOnce the issue has been resolved, it is then necessary to record the resolution and close it - this is the last step of the tracking process. The Project Manager will verify that the solution was approved, and if everything is satisfactory, will change the status to “completed”. (At this time the issue may be removed from the Outstanding Issue Log and placed in a similar log for completed issues. This would be helpful to the project manager in the first step of the process when checking to make sure an issue has not been addressed before.)

Issues that the Project Manager cannot resolve will go to the Steering Committee and ultimately the Sponsor for a final resolution or decision.4.3.6 Decision Management Any issue or change may generate a significant decision that affects the project direction or approach to resolving a problem or achieving the end goal. Decisions will be logged to maintain a documented history of why an approach or task was performed. The project manager will document decision in the Issue and Decision Log.

4.4 Communication Management – See sub-plan Approval of the Communication plan is covered by the approvals/signatures of the master Integrated Project Plan.

4.5 Quality Management - See sub-plan.Approval of the Quality Management plan is covered by the approvals/signatures of the master Integrated Project Plan.

4.6 Risk Management – see sub-plan.Approval of the Risk Management plan is covered by the approvals/signatures of the master Integrated Project Plan.

4.7 Procurement Management – see sub-plan.Approval of the Procurement Management plan is covered by the approvals/signatures of the master Integrated Project Plan.

4.8 Requirements Management PlanThe objective of performing Requirements Management is to be able to control the scope of the project’s product deliverables. The requirement management plan documents the specific business needs expressed as functional and usability requirements. These requirements will be further expressed as design specifications that will be coded and tested in test scripts. 4.8.1 Requirements Development


The purpose of the Requirements Management Plan is to establish and maintain an agreement with the customer, vendors and the project team on the meaning and priority of the requirements, which represent the product scope that will be addressed by the project. The Project will use a Requirements Traceability Matrix to track mandatory vs desirable requirements. The Project will also use, as applicable, the Agile concept of a Product Backlog to track delivery and release scheduling for the approved customization requirements related to system implementation. The RTM and Product Backlog will be kept in synch.

This plan addresses how the CRIMEvue project will manage requirement development and change to ensure that the initial business needs and project objectives are allocated into the technical and non-technical requirements needed to deliver the solution. It details the process, assigns responsibilities, identifies the techniques to be used, associated tools, and documentation needs.

It is the responsibility of the CRIMEvue Project Manager to ensure that the project team is aware of and follows this plan; its process and associated responsibilities.


The following diagram illustrates the various levels of requirements on the project and how they will be progressively detailed and regularly verified to ensure the work products meet their specified requirements.


4.8.2 Requirements Development

Defining CRIMEvue project requirements began when the business need was defined. This process will progress through detailing of requirements to define a capability, physical characteristic, or quality factor of a product or an enabling product needing created. The requirements development strategy will be primarily text based. The data requirements will be collected through use cases, interviews and through JAD sessions and documented in templates using MS Word, MS Excel and/or MS Visio.

4.8.3 Business Need and Project Objectives

The CRIMEvue Project Plan defines project objectives. The business needs will be transformed into project objectives to enable the project to plan and track progress against measurable criteria. The project objectives are the basis for further requirements development.

Business needs or project objectives may change as more information is uncovered during the progressive detailing, or verifying of requirements. As requirements evolve, the project team will use the project change management process. The process will determine if the change is of value and should be incorporated into the project, and adjust the original business needs and project objectives documents.

4.8.4 Stakeholder Needs

The project will identify stakeholders and gather, validate, prioritize, and document stakeholder needs and constraints. The project communication plan will document how information will be shared with stakeholders.

4.8.5 Identifying the Stakeholder

Stakeholders - A person or group who have a specific interest in, or are affected by decisions or changes to the product will be identified in the requirements traceability matrix.

CRIMEvue stakeholders include end users, business partners, customers, regulatory groups, suppliers, technology support, policy developers, technical developers, producers, testers, and maintainers. The stakeholder may be an internal or external party.

4.8.6 Collect and Document Needs

Stakeholder needs, including expectations, priorities, and constraints will be collected by use of JAD Sessions, and / or personal interviews. The information will be documented in the requirements traceability matrix tool and further managed for Release delivery via a Product Backlog.

The needs information collected from the stakeholders will contain the following:

Stakeholder name, group or ID expressing need Unique identifier for each need Requirement ID (to be input later – after requirements are defined. This column could have

multiple requirements listed per one stakeholder need.) A description of each need expressed by stakeholder group. Stakeholder need priority Need constrained by, i.e. policy, law, standard, etc.

4.8.7 Synthesize Stakeholder Needs

/tt/file_convert/5f8bf33a219d807e22790191/document.docx Page 0

Conflicting stakeholder needs will be identified and resolved by meeting with the stakeholders whose needs are conflicting and negotiating. In the event the conflict cannot be negotiated the project’s issue resolution process will be performed to seek decision by the sponsor. Duplicated stakeholder needs will be modified to use the same need ID.

Based on resolutions, the stakeholders needs information will be updated and reviewed with the stakeholders to ensure that the documented needs are complete and correct.

Approval of the final stakeholder needs will be obtained from the sponsor. The approved version will become the baseline for stakeholder needs. Changes to stakeholder needs will be made through the project’s change management process.

4.8.8 Requirements Definition

The project will transform needs into high-level requirements, evaluate and correct deficiencies, validate findings with stakeholders, and update the requirements traceability matrix.

4.8.9 Transform Needs into High-Level Requirements

Each stakeholder need will be evaluated to determine the high-level requirements. The high-level requirement will be written to support a capability, physical characteristic, or quality factor. Each need may have one to many requirements to fully define the need. The requirement will be defined to be measured/evaluated and support a potential solution.

Examples of a need and associated high-level requirements:

Need –“ I need to track the office inventory.”

H.L. 1 – The system shall provide online capability to add a new office inventory item.

H.L. 2 – The system shall provide the capability to perform an online search for office inventory item information.

The High-Level Requirements information will be added to the requirements traceability matrix and will contain the following:

Unique identifier for high-level requirement Stakeholder need ID Subsystem (optional – many times the changes are being made to an existing system where the

subsystems are already know – in this case the requirements can be traced to the subsystem). High-level requirement(s) derived from need Requirement Type (see requirements analysis section) Requirement Priority (note this is not the same as the stakeholder priority – this is the priority set

by the steering committee) Relative Effort – to implement the requirement. They should be recorded as “H or M or L”

indicating a high, medium, or low level of effort to implement the requirement. Verified – to show if a requirement has been verified. They could be recorded as yes “Y”, no “N” or

by date. Release (and planned Sprint) Use Case ( record the use cases associated with the requirement) Test Case (record the test cases associated with the requirement).

If new of additional stakeholder needs are discovered during the transformation the appropriate stakeholder(s) must approve the new stakeholder need before adding to the requirements traceability


matrix or product backlog. Once approved, these needs will be added to the original baseline and become the new baseline representing the stakeholder needs.

4.8.10 Evaluate High-Level Requirements

Each high-level requirement will be evaluated to ensure that the requirement is supportable for product development. The requirements will be evaluated against the following criteria and any deficiencies found will be corrected, restated, and re-recorded in the <requirements traceability matrix or database or other tool>.

Evaluation Criteria1. Correct - Each requirement is one that the system or a component product shall meet. No requirement disagrees with another requirement.

2. Necessary - Each requirement is an essential capability, physical characteristic or quality factor. Deletion of the requirement would cause an unacceptable deficiency in the product.

3. Clear - Stated so that the requirement is unambiguous. That is, each requirement can have one and only one interpretation.

4. Attainable - Feasible within the current environment and achievable at a cost that meets the existing budget, schedule and other project plan constraints.

5. Traceable - The origin of each requirement is clear and can be traced forward to other products.

6. Verifiable - Stated in measurable terms and quantified in a manner that can be determined by inspection, analysis, demonstration, or testing.

4.8.11 Validate High-Level Requirements & Prioritize

The following stakeholders will validate the high-level requirements: Business lead Technical lead Sponsor System Architect Unit Managers

The validation approach will be group meetings and/or individual review.

The approach for prioritization of high-level requirements will be to mark the individual items as Mandatory, Desirable and Nice to Have.

The approved priority for each requirement will be recorded in the requirements traceability matrix tool.

4.8.12 Requirements Analysis

The project will assign and categorize the high-level requirements to requirement types, refine the high-level requirements to obtain greater precision and detail, and validate that these detailed requirements align with the high-level requirements.

4.8.13 Assign High-Level Requirements to Requirement Types

Each high-level category will be assigned to a requirement type. High-level requirements that can be assigned to more than one requirement type should be reworded or split into two or more


requirements. The following are the high-level requirement types for this project: Note see the “Requirements Specification Template for a definition of the types.

Functional Data Use

Performance Operational Security

Legal Standards Future

4.8.14 Determine Requirements Organization

The requirements will be organized and documented in the requirements traceability matrix that produces a written requirement.

4.8.15 Refine into Detailed Requirements

Each requirement will be refined into a more precise, well-defined detailed requirement(s). The level of detail is expected to vary, but will be sufficient to support subsequent product design, use cases, construction, test cases and updating the project plan.

The detailed requirement will be documented in the appropriate section of the requirements traceability spreadsheet.

Example of high-level requirement refined into detailed requirements:H.L. 1 – The system shall provide online capability to add a new office inventory item.

D.R. 1.1 The add-item program will require entry of the item number, item description and base inventory level to add a new office inventory item.D.R. 1.2 The add-item program will initialize the total in stock field to zeros when adding a new office inventory item.

H.L. 2 – The system shall provide the capability to perform an online search for office inventory item information.

D.R. 2.1 The item-search program will require an item number or item description as its search criteria.D.R. 2.2 The item-search program will provide a field to select items currently in stock (item order records with a date disbursed of zeros).DR 2.3 The item-search program will provide fields to select a date or date range search on the date ordered, date received or date disbursed fields. DR 2.4 The item-search program will display the item number, item description, total in stock and base inventory level information.DR 2.5 The item-search program display will contain one line of data (vendor, date ordered, date received, cost per item, date disbursed) per order selected using the above criteria.

4.8.16 Requirements Verification – Future Phase

In a future System Implementation phase, the team will verify through each phase of the project that the end product or deliverable meets the requirements, i.e. the code and configuration meets the design specification and or use case.

Planned verifications of requirements will occur at minimum as follows:


Project Objectives Verification – the project objectives will be verified to ensure that they meet the original business need.

Stakeholder Needs Verification – the stakeholder needs will be verified to ensure that they are in line with and bound by the project objectives.

Requirements Verification – the high-level requirements will be verified to ensure that they represent the various stakeholders needs.

Design Verification – the Design Requirements will be verified to ensure that they meet the high-level requirements.

Code Verification – The Code will be tested to ensure that it meets the Design Requirements.

All products failing verification will be fixed before proceeding to the next phase. Waivers or approved deviations will be rare.

4.8.17 Requirements Change Management – Future Phase

The project’s change management process will be used to manage: deletions, modifications and additions to the RTM and product backlog, only allowing in scope those features that are in line with the original objectives or to formally modify these objectives, and the supporting schedule and resourcing.

4.8.18 Requirements Documentation Standards

The CRIMEvue project will use a requirements traceability matrix to manage and track requirements.

4.8.19 Requirements Tools and Techniques

The below is a list the selected Tools and Techniques that the project will use to perform the various requirements activities.

Document Templates and Spreadsheets – requirements are commonly recorded and tracked using simple document templates and spreadsheet tools.

Joint Application Development (JAD) – JAD is a structured, facilitated process for gathering and negotiating requirements and prototyping the user interface. It involves bringing together key players to focus on requirements and obtain stakeholder buy-in.

Interviews - An interview is a conversation with stakeholders to elicit or validate needs and requirements. An interview may include one or more stakeholders. The interview may also involve a question and answer session used to discover other potential stakeholders and any discrepancies between needs; the high-level requirements derived from those needs; and the resulting detailed requirements. Interviews facilitate obtaining approval from stakeholders on their needs, requirements, and any changes to them.

4.9 Schedule ManagementSchedule management is the plan to control the schedule of tasks, when they are updated, who decides the acceptable completeness of tasks and how tasks get added to the schedule for tracking.

The schedule will be tracked using SmartSheet software is the choice for tracking will shared via access through a webpage for general use. The schedule is organized into phases according to the short term scope and the long term scope (which is currently unknown). The project schedule will be updated on a biweekly basis and will contain tasks within each phase as well as an assigned resource. Additions to the project schedule are suggested by the stakeholders, project team members, project manager and the project sponsor. If tasks added impact the schedule or the ability /tt/file_convert/5f8bf33a219d807e22790191/document.docx Page 4

to deliver on time, further discussion and approval may be required. The Project Manager implements all approved schedule changes.

4.10 BudgetPreliminary biennial estimates from DAS-ETS for CRIMEvue were $180,624 and $78,536 for the LEDS Message Switch. The current spending plan, based upon the project approach is, CRIMEvue software planning, purchase, and implementation in 2015-17 with a total project cost of $11,660,000. OSP has $1,000,000 in existing Other Funds limitation which reduces the Policy Option Package request to $10.66 million All Funds ($5 million in Other Funds and $5.66 million in General Fund).

OSP anticipates that this Policy Option Package, if approved, would be approved in stages. The Department would not request to spend any General Fund until all of the available Other Funds had been expended for CRIMEvue.

The spending plan for the LEDS Message Switch would be to purchase and install the switch during the 2017-2019 biennium. The installation of the switch would be paid for with $3,903,400 in General Fund.

Maintenance for CRIMEvue would begin in the 2017-2019 biennium and would be funded through Other Funds revenues of $2,200,000. Maintenance would begin for the LEDS Message Switch and continue for CRIMEvue in the 2019-21 biennium. Beginning in 2019-21 the agency would assume that maintenance for both would be funded through $3,233,840 in General Fund. Utilizing current Other Funds revenues and cash balances for CRIMEvue may create the need to reevaluate fee levels in the 2019-2021 biennium.

.


Appendix A – Project Organization Chart


Appendix B – Contact List

Name Role Cell Desk Phone

Email Comments

Mike Bloom Sponsor, Major for OSP Public Safety Bureau

503-991-7112

503-934-0440

[email protected]

Pat Ashmore Steering Committee Member, Deputy Superintendent for OSP

Andrew Heider Steering Committee Member, Major, Police Services Bureau

Jennifer Bjerke Strategic Technology Officer

971-701-1070

[email protected]

Tom Worthy Domain Expert, CAS & OSP Technology Officer

503-983-0776

503-934-0266

[email protected] Text preferred

Becki David Domain Expert – OSP Central Records

503-507-0743

503-934-0189

[email protected]

Tricia Whitfield Domain Expert, OSP CJIS

503-569-1861

503-934-2305

[email protected]

Mathew Oeder Domain Expert, OSP CJIS

971-600-7907

503-934-2328

[email protected]

Jerry Martin Domain Expert, OSP IT 503-931-2879

503-378-8750

[email protected]

David Alamein Domain Expert, CIO, Information Technology

503-602-0982

[email protected] Use cell

Kevin Silbernagel

Domain Expert, Information Technology

971-209-9982

503-378-3055 ext. 55007

[email protected]

Angela Kasprzak

OSP Executive Support, Project Administration/Scribe

971-301-1269

503-934-2304

[email protected]

Linda Anderson OSP Project Manager 971-600-4778

[email protected]

Jeff Burhans Systems Expert [email protected] Tobey Systems Expert [email protected] Hathaway

Systems Expert [email protected]

Terri Barczak Interim PM 503-881-9346

[email protected] Temporary status

Julie Neburka LFO Advisor [email protected] McSpaden

LFO IT Advisor 503-986-1835

[email protected]


mailto:[email protected]















Alex Pettit State CIO503-378-2128 [email protected]

Art Ayre DAS, CFO Analyst

Ed ArabasDAS Office of CIO Analyst

503-378-6111 [email protected]

CJIS Advisory Board Members

Jennifer Bjerke Facilitator, Department of Administrative Services


Bettina Davis Department of Corrections


Craig Daniels Department of Transportation


Linsay Hale Dept. of Public Safety Standards & Training


Tanner Wark OR Association of Community Corrections Directors


Christine Bell (Alternate)

OR Association of Community Corrections Directors


Janie Schutz Oregon Association Chiefs of Police


Michael Schmidt

Oregon Criminal Justice Commission


Kelly Officer Oregon Criminal Justice Commission

Diana Vitolins Oregon District Attorneys Association


Dan Krein Oregon Juvenile Department Director's Association


Teresa Parker Oregon Liquor Control Commission


Jim Conlin State Courts 503-986-5125 [email protected]

Brian Wallace Oregon State Sheriffs' Association


Philip Cox Oregon Youth Authority 503-373-7531 [email protected]

Kristin Winges-Yanez

State Board of Parole 503-945-0900 [email protected]

Curt Melcher State Fish & Wildlife 503-947-6044 [email protected]

Mike Bloom State Police 503-934-0440 [email protected]

Tom Worthy State Police 503-934-0266 [email protected]

Patricia Whitfield

State Police 503-934-2305 [email protected]

Heidi Moawad Governor's Office 503-986-6550 [email protected]


Appendix C – Change Request

Change Control Request # _____

Project Name Date

Office

Project Manager Phone Email

Change Request Definition

Description – Describe the proposed change.

Justification – Justify why the proposed changes should be implemented.

Impact of Not Implementing – Explain the impact if the proposed change is not implemented.

Alternatives – Provide at least three alternatives that could be implemented instead of the proposed change.

Change Request Analysis

Check each that apply

Project Schedule Configuration Item Contract Amendment/Change Order

Project Costs Project Scope Major Deliverables/Outcomes

Technology Roles/Responsibilities

Note: An approved Change Control Request MUST accompany the Contract Amendment and Change Order Approval if applicable.

Impact Description – Describe the impact for each of the items checked.


Change Request Initial Review

Review Date Reviewer’s Name Reviewer’s Project Role Recommendation

Approve Reject Defer Until: [DATE]

Change Request Final Management Approval

Final Approval Date Name Title Recommendation

Approve Reject

Special Instructions – Provide any additional information regarding the final recommendation.


Appendix D – RACI Template
