DOC

EDS AGREEMENT NUMBER [XXXX]CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABIL ITATION (CDCR) EXHIBIT IMANAGEMENT REQUIREMENTS RESPONSE

EXHIBIT I: MANAGEMENT REQUIREMENTS RESPONSE

VIII.D.1.c. Section 6 – Management Requirements Response

This section must contain the QBP’s response to the requirements identified in Section VI.D – Management Requirements. The bidder’s response to Section VI.D – Management Requirements must contain the following item:

Management Requirements Response: Tabular response that clearly identifies the proposal’s closeness of fit to each of the CDCR management related requirements as described in Section VI.D – Management Requirements.

Methodologies Contributing to Competent Project Management

Team EDS leverages our vast corporate body of knowledge and proven methodologies throughout the Strategic Offender Management System (SOMS) project. This strategy has consistently delivered project success and continuous improvements to our global clients. Our approach balances companywide consistency with flexibility to address each of CDCR’s unique needs. Our focus on repeatable processes, tools, and methods, and an overall quality management system built around the EDS culture and long record of success, differentiates EDS from our competitors. EDS has invested more than $100 million to develop and deploy high quality processes, methods, and tools that adhere to international standards. Our Global Applications Delivery Quality Management System (GAD QMS) will provide a framework for project activities, and we employ our Global Program Management Architecture (GPMA™) as our overarching methodology for managing the SOMS endeavor.

GAD QMS provides a single, end-to-end integrated system for application delivery-specific processes, and integrates business process assets, as well as software engineering process assets. CDCR will receive best-in-class service with the lowest possible risk because GAD QMS enables the team to leverage consistent, repeatable processes. GAD QMS is based on corporate tools, methods, and best practices, and complies with recognized industry standards, including the Project Management Institute’s (PMI’s®) Project Management Body of Knowledge (PMBOK®) and the Software Engineering Institute’s (SEI’s®) Capability Maturity Model Integration® (CMMI®). GAD QMS also complies with the

EDS SOMS STATEMENT OF WORK EXHIBIT I -1

Methodologies, Tools and Technology to hit the ground running!

Time-tested and repeatable methodologies

Consistent adherence to industry standards

High quality processes built around proven success

Reliable use of proven tools


Information Technology Infrastructure Library (ITIL®), integrating both engineering and project management methodologies.

While GAD QMS provides the processes, tools, roles, responsibilities, and rigor to support and deliver high-quality applications, it is flexible enough to be tailored to specific needs and allows scalability to provide “what makes sense” from a methodology perspective for CDCR’s organization. Team EDS can customize and modify GAD QMS methodologies to integrate with CDCR’s or the State of California’s standards and methodologies and still satisfy the intent of the original procedure, standard, or template.

The many methodologies of the GAD QMS framework, depicted in Figure 6.0-1, GAD QMS Framework, and described in more detail below, will provide the robust processes, procedures, and work products to support the delivery of the SOMS project.

Systems Life Cycle Version 3

(SLC3)

Requirements Determination Process (RDP)

Enterprise Testing

Methodology

Business Process Reengineering

(BPR) Methodology

Business Continuity Planning

Methodology

ITIL Methodology

Software Performance

Engineering for Legacy Systems

(SPELS)

Estimating Methodology

Production Support

Methodology

Object and Component Engineering

(OCE)

Project Management Version 2.3

(PM2)

Global Application

Delivery Quality Management

System

Figure 6.0-1, GAD Quality Management System Framework

The following briefly describes each of the EDS methodologies integrated within the GAD QMS environment.

Project Management, Version 2.3 (PM 2®) – EDS’ preferred methodology for project management, PM 2, is based on PMI’s PMBOK. Section 6.1, Project Management, describes our PM 2 methodology.

Systems Life Cycle, Version 3 (SLC 3) – EDS’ preferred methodology for application development and configuration of commercial off-the-shelf (COTS) applications. This methodology applies technology to create solutions that

EXHIBIT I -2 EDS SOMS STATEMENT OF WORK


meet the client's rapidly changing business needs. SLC 3 is described in our response to management requirement number M-33, Section 6.4, System Design and Development.

Object and Component Engineering (OCE) – EDS’ preferred methodology for object and component application development and configuration management.

Requirements Determination Process (RDP) – Provides a framework for communicating with clients and those who will receive and use requirements documentation to build a product or service.

Production Support Methodology – Provides an integrated approach to help EDS deliver better software maintenance and other production support services to clients. It offers greater productivity and quality for production support teams and greater recognition of the importance of production support to EDS business.

Enterprise Testing Methodology – EDS’ preferred methodology for enabling comprehensive testing. This methodology promotes productivity, quality, and comprehensiveness in our testing practices, providing better deliverables for our clients with reduced risk of solution failure.

Estimating Methodology – EDS’ corporate estimating method is synchronized with the SLC 3 and the Production Support Methodology to facilitate estimating metrics.

Business Process Reengineering (BPR) Methodology – This framework encompasses a collection of methods, tools, techniques, and lessons learned that helps project teams transform organizations from their current state to a future state.

Software Performance Engineering for Legacy Systems (SPELS) – EDS’ approach for assessing existing systems and recommending options to:

– Identify dependencies and extraction of process rules

– Prepare for technology modernization. Business Continuity Planning Methodology – EDS' method used to provide

iterative business continuity services that encompass: business continuity planning, crisis management, disaster recovery planning, and business resumption planning.

ITIL Methodology – This defines the ITIL service management methodology and processes designed to enhance service delivery.

Throughout the remainder of Section 6.0, we describe how each of these methodologies will allow Team EDS to “hit the ground running” and then to continually contribute to efficient, deliberate, and risk-mitigating management of the SOMS project.

Section 6.0 of Team EDS’ Initial Final Proposal responds to the CDCR’s specific Management requirements. Tabular responses for these requirements numbered



M-1 through M-122, as summarized in Table 6.0-1 below, are contained in proposal Sections 6.1 through 6-10. For purposes of navigating our proposal, we have provided both the section number and page number within the completed table that follows. If supporting information is provided for a management requirement that references another section, we provide that section number. If the supporting information exists within the section, we have simply referenced the requirement number.

Team EDS’ response to each of the requirements noted in Table 6.0-1, presents a distinct facet of our approach and how we comply with CDCR’s specific management requirements. The common theme across all of the requirements is Team EDS’ consistent adherence to time-tested and repeatable methodologies, industry standards, and use of proven tools. Our team will carry out the activities described in each requirement by applying EDS’ corporate methodologies to promote effective project management and quality-driven processes.

Table 6.0-1, Management Requirements Numbered M-1 Through M-122.

Req. Num.

Requirement Response / Reference

M-1 The Contractor must employ, maintain, and execute a project management methodology that complies with the Institute of IEEE Standards for Project Management Plans (IEEE Standard 1058-1998 and 1490-2003).

Section 6.1,

Page 6.1-1

M-2 The Contractor must describe the project management approach and methodology to be used for all SOMS Project lifecycles.

The Bidder must submit a narrative describing their approach to project management with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.1,

Page 6.1-2

M-3 The Contractor shall develop a Project Management Plan (PMP) conforming to IEEE Std. 1058-1998 Standard for Software Project Management Plans or IEEE Std. 1490-2003, IEEE Guide – Adoption of PMI Standard – A Guide to the Project Management Body of Knowledge. The scope of the PMP shall also incorporate the following component processes:

Project Schedule, Staff Management, Communications Management, Issue Management, Risk Management, Quality Management, Scope Change Management, Requirements Traceability Management, and Configuration Management.

CDCR acknowledges that some portions of the PMP may require a standalone plan.

The Bidder must submit a draft PMP with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.1,

Page 6.1-33

M-4 The Contractor must provide project management documents (e.g., Project Management Plan, Project Schedule, Work Breakdown Structure, etc.) using Microsoft software products. The software version must be no less than a version still available on

Section 6.1,

Page 6.1-35



Req. Num.


the common market and that is still supported by the manufacturer. CDCR will work with the vendor in approving specific versions to assure that the application is synchronized with CDCR’s plans.

M-5 The Contractor shall advise CDCR and Contractor management of progress in meeting goals and schedules contained in the work plans. This shall be initiated one week after contract effective date and applied weekly thereafter, and shall consist of the following:

Weekly progress meetings attended by the Contractor and CDCR. These may include walkthroughs of selected deliverables as requested by CDCR staff.

Weekly written progress reports, provided by the Contractor to CDCR one working day before each weekly meeting, and containing items to be discussed at the meeting, including:

Progress of each task/activity.

Updated project schedule.

Action items and decisions from the previous meeting.

Problems encountered, proposed resolutions, and projected completion dates for problem resolution

Planned activities for the next two reporting periods.

Status of contractually defined deliverables, milestones, and walkthroughs scheduled in the project schedule.

Other information as needed (per Contractor or CDCR).

Monthly Status Report. This report shall include deliverables, milestones, walkthroughs, CDCR approvals, and lessons learned and shall be used by the Contractor and CDCR in measuring the Contractor’s progress and performance. The report shall also contain:

Issues, problems, and corrective actions, steps, and assignments.

Risks and Mitigations.

Cost Variance reporting

Lessons Learned.

Section 6.1,

Page 6.1-35

M-6 The Contractor must provide contract close-out plans and manage project close-out activities in accordance with the plan.

Section 6.1,

Page 6.1-36

M-7 The Contractor shall submit to CDCR as part of their proposal, specifications for all necessary hardware, software and tools for the five (5) SOMS system environments.

Section 6.1,

Page 6.1-36

M-7b The Contractor must procure all hardware, software, and automated tools necessary for the development environment to be housed at CDCR EIS, and the four environments to be housed at

Section 6.1,

Page 6.1-37



Req. Num.


either DTS COEMS or vendor site.

The Contractor should leverage to the greatest extent possible, the State’s purchasing vehicles, so long as they afford CDCR the lowest cost.

M-8 The Contractor shall develop a technical infrastructure document which describes all of the hardware, system software and tools necessary for each of the five (5) SOMS system environments.

Section 6.1,

.1-37

M-9 The Contractor shall develop an environment configuration manual that describes the environment installation and configuration necessary for each of the five (5) SOMS system environments.

Section 6.1,

Page 6.1-38

M-10 The Contractor is responsible for installing and configuring all hardware, software and tools purchased under this Contract until Systems Acceptance for the development and test environments.

Section 6.1,

Page 6.1-38

M-11 The Contractor is responsible for maintaining all hardware, software and tools purchased under this Contract until Systems Acceptance for the development and test environments.

Section 6.1,

Page 6.1-38

M-12 Source Code – The selected Contractor shall furnish the readable source code and object (executable) code and documentation for all software developed by the Contractor, under this contract, ownership of which shall be assigned to the State of California. The selected Contractor shall provide source code and documentation for COTS software licensed for use by the State of California under this contract.

Section 6.1,

Page 6.1-38

M-13 The State envisions significant process change during the development and implementation of SOMS. The SOMS project involves the implementation and integration of COTS components. The State anticipates improvements to its business processes and the need to manage changes to its organization. The Contractor is required to provide the following in the area of BPM:

A written BPM Plan outlining the tasks necessary to implement process changes / improvements.

A change readiness assessment of CDCR’s organization to use and support SOMS and new processes.

A gap analysis, including the recommendations for organizational change required to use and support SOMS. This analysis should specify the benefit of making the change.

Tasks, timeline, and resources, including number and classification of program staff to accomplish the recommended changes.

The Bidder must submit a sample BPM plan with their proposal response as identified in Section VIII – Proposal and

Section 6.2,

Page 6.2-1



Req. Num.


Bid Format.

M-14 The Contractor shall describe the knowledge transfer and training approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the knowledge transfer and training approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.3,

Page 6.3-1

M-15 The Contractor shall develop (in cooperation with CDCR) a Knowledge Transfer and Training Plan to describe the approach for bringing managers, end users, and technical personnel to a familiar level of understanding with how the new system works and how it differs from the system being replaced. The Plan shall address the following topics:

Training goals/objectives and the specific plan for training technical personnel and end users.

Strategy for providing training as early as possible in the project to allow the training goals to be implemented throughout the project life cycle.

Tasks, deliverables, and resources necessary to complete the training effort and identify tools and documentation that shall be necessary to support proposed effort.

The different types of training, the specific courses and course materials, the training approach for both technical personnel and end users, and how training effectiveness shall be measured and addressed.

A description of deliverables to support initial and ongoing training including user manuals, system manuals, and on-line help and training materials for technical/non-technical personnel.

Knowledge Transfer to enable State personnel to operate, maintain, configure and modify the new systems, including operation of the testing tools, supporting infrastructure, and security.

Metrics for tracking progress in achieving training and knowledge transfer objectives.

Report progress of training activities. Approved recommendations for both training and knowledge

transfer resulting from the organizational change readiness assessment.

The Bidder must submit a sample knowledge transfer and training plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.3,

Page 6.3-35

M-16 The Contractor shall provide CDCR a training course outline for review and acceptance at least thirty (30) calendar days prior to

Section 6.3,

Page 6.3-42



Req. Num.


the scheduled training.

M-17 The Contractor shall submit all training packages to CDCR for review and acceptance at least twenty-one (21) calendar days prior to the scheduled training.

Section 6.3,

Page 6.3-42

M-18 The Contractor shall provide training manuals for all classroom training they provide.

Section 6.3,

Page 6.3-43

M-19 The Contractor shall provide all training materials developed for the SOMS system to CDCR. Those materials shall become the property of CDCR and may be modified and duplicated by CDCR.

Section 6.3,

Page 6.3-43

M-20 The Contractor shall provide electronic copies of all training materials (end-user, technical, trainee and instructor) in a format that can be updated and printed by CDCR staff using software for which CDCR owns licenses.

Section 6.3,

Page 6.3-43

M-21 The Contractor shall provide updated training documentation as necessary to incorporate new processes or functionality due to system releases, upgrades, or changes throughout the contract term.

Section 6.3,

Page 6.3-43

M-22 The Contractor shall schedule all training during regular work hours as approved by the State, unless the Contractor receives advance approval from CDCR for specific training at other times.

Section 6.3,

Page 6.3-44

M-23 The Contractor shall provide instructions to the State on Contractor tools and procedures used to support the Project.

Section 6.3,

Page 6.3-44

M-24 The Contractor shall provide all training within the State of California.

Section 6.3,

Page 6.3-44

M-25 The Contractor shall ensure that Contractor staff members are not assigned to train State staff and work on critical path development tasks concurrently.

Section 6.3,

Page 6.3-44

M-26 The Contractor shall provide end-user training documentation in written manuals, on compact disc, and online, as part of a help facility for the system.

Section 6.3,

Page 6.3-45

M-27 The Contractor shall schedule CDCR Adult institution and Parole staff, and DJJ facility and parole staff training in a manner that is least disruptive to the normal business operations.

Section 6.3,

Page 6.3-45

M-28 The Contractor shall assist CDCR in developing end-user training on the SOMS business application and system functionality. The Contractor shall provide end-user training for CDCR field team trainers, who have typically been pulled from operational staff, who will, in turn, train non-technical CDCR field staff on SOMS

Section 6.3,

Page 6.3-46



Req. Num.


system functionality and business processes.

M-29 The Contractor shall develop train-the-trainer training for CDCR Staff. The training shall be hands-on, in-person, and shall include, at a minimum, the following topics:

Administrator Functions – Training developed specifically for CDCR authorized administrative staff.

Functional – Training developed for CDCR staff performing the following functions:

Intake, Classification, Programs, Sentence Calculation, Movements, Transportation, Discipline, Appeals / Grievances, Holds, Wants and Detainers (HWD), Scheduling, Gang Management, Property, Visitation, Pre-Parole and Release, Parole, Administrative Processes

Other Agency Users – Specific training and materials developed for the “outside CDCR user”, such as BICE and contracted program providers.

Section 6.3,

Page 6.3-46

M-30 The Contractor shall identify the number of staff necessary for maintenance and operations (M&O) of the solution as well as the skill sets necessary.

Section 6.3,

Page 6.3-48

M-31 The Contractor shall develop and provide training for SOMS Technical Support Staff to include, as a minimum, the following types of staff (number to be identified by the Contractor):

State technical staff that shall be participating in the development and implementation of the SOMS system.

State technical staff that will be supporting the SOMS system. State Help Desk staff that will assist internal end users with

technical support for the SOMS system. State technical staff on the support and administration of the

business rules technology. The training shall include, at minimum, the following topics: System design. System usage. System Interfaces. Database design and maintenance. System procedures. Application and tools development. Report generation. System administration and maintenance. The setup, configuration, and administration of all computing

environments developed by the Contractor.

Section 6.3,

Page 6.3-49



Req. Num.


M-32 For the duration of the contract, the Contractor shall continue to provide training to the State technical staff if system upgrades have been installed and there is a change in system functionality.

Section 6.3,

Page 6.3-56

M-33 CDCR utilizes a structured SDLC that is consistent with industry-standard best practices as well as State requirements for information technology projects. The Contractor must use a structured SDLC process, including an iterative software development methodology and incremental deployment of functionality to the production environment.

This approach allows both the Contractor and CDCR more frequent feedback as to the progress of the Project with more opportunities to make corrections in interpretation and will result in a better understanding of the challenges of the Project at an earlier date.

Section 6.4,

Page 6.4-1

M-34 The Contractor shall describe the design and development approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the design and development approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.4,

Page 6.4-4

M-35 The Contractor must utilize the change request process and tools described below, and garner the approval of CDCR:

All change requests cost estimates must include the use of a Cost Analysis tool, such as Cost Expert and reference to the rates in the Unanticipated Tasks cost worksheet in Section VII - Cost

Section 6.4,

Page 6.4-55

M-36 The Contractor shall incorporate the design and development approach into a comprehensive Design and Development Plan (Software Development Plan) complying with IEEE 12207.2, section 5.3.3 - system architectural design.

The Bidder must submit a sample Design and Development Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.4,

Page 6.4-61

M-37 The Contractor shall follow industry standards for all development work, including database naming and usage.

Section 6.4,

Page 6.4-63

M-38 The Contractor shall provide CDCR access to the software components and documentation.

Section 6.4,

Page 6.4-67

M-39 The Contractor may not use CDCR production system resources (data or source files), or data derived from the production system resources, off-site without authorization from CDCR.

Section 6.4,

Page 6.4-67

M-40 The Contractor shall be responsible for leading and coordinating Section 6.4,



Req. Num.


the review of legacy software and the extraction of business rules. Page 6.4-67

M-41 All extracted business rules will be subject to the review and approval of CDCR.

Section 6.4,

Page 6.4-70

M-42 The following constraints are placed on the modifications made to legacy software:

All modifications to CDCR legacy code will be developed, tested, and deployed by the State.

The staging of legacy code changes resulting from the State will be managed by the State.

The impact of migration of SOMS business logic to the new technology on CDCR legacy applications will be determined by the State.

The State will work with the Contractor to coordinate the testing of modified CDCR legacy code.

Model/dictionary/and or format of CDCR legacy data, including field length, type, description, and relationships to other data will be provided by the State.

Section 6.4,

Page 6.4-70

M-43 The Contractor shall describe the overall testing approach and methodology used for the SOMS Project

The Bidder must submit a narrative describing the testing approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.5,

Page 6.5-1

M-44 The Contractor shall incorporate the testing approach into a comprehensive Test Plan complying with CDCR testing practices and IEEE Std. 829-1998 Standard for Software Test Documentation. The Test Plan shall include the procedures for documenting the completion of each test phase, test scripts, test conditions, test cases, and test reports. Detailed Test Plans shall be created for the following:

Unit Testing Functional Testing Integration Testing System Testing Security Testing Regression Testing Stress/Load Testing Performance Testing Acceptance/Usability Testing

The Bidder must submit a sample Test Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.5,

Page 6.5-13

M-45 Testing and Development shall have their own environments, Section 6.5,



Req. Num.


separate from Production. Testing or development shall not be performed in the production environment.

Page 6.5-17

M-46 The Contractor shall use an automated testing tool for, at a minimum, stress/load and regression testing. The tool shall create the test scripts, perform the test execution, and generate the test reports.

Section 6.5,

Page 6.5-19

M-47 The Contractor shall repeat the test lifecycle when a failure occurs at any stage of testing (e.g., a failure in Acceptance Testing that necessitates a code change will require the component to go back through Unit Testing, Integration Testing, and so forth).

Section 6.5,

Page 6.5-21

M-48 The Contractor shall perform Full Lifecycle Testing throughout the duration of the project. This includes Unit, Integration/String, System, Operational (Stress/Load, Performance), and Regression Testing.

Section 6.5,

Page 6.5-22

M-49 The Contractor shall be responsible for building test plans, executing test plans, and creating reports. CDCR will evaluate the Contractor test plans, and Contractor test results, as well as validate the testing done by augmenting it with their own testing.

Section 6.5,

Page 6.5-36

M-50 The Contractor shall provide staff to CDCR to answer questions and address any problems that may arise during testing conducted by CDCR.

Section 6.5,

Page 6.5-38

M-51 The Contractor shall refine the test documents, procedures, and scripts throughout development and through full system acceptance to reflect the as-built design and current requirements.

Section 6.5,

Page 6.5-39

M-52 The Contractor shall allow DTS/CDCR to run validation and testing software against externally facing Internet applications to help identify potential security issues, and must agree to repair any deficiencies found during this testing. DTS currently uses Web Inspect to test Internet applications for security and vulnerability issues.

Section 6.5,

Page 6.5-40

M-53 As Offender Case Management programs contain date and time-sensitive elements, the testing infrastructure must provide a method of altering and synchronizing the system date throughout each test phase. This requires the ability to change the system date and time in some scenarios. The system date may actually reside in multiple systems in a distributed environment and may be difficult to change if other applications also reside on any of those servers.

Section 6.5,

Page 6.5-41

M-54 The Contractor must develop a comprehensive Problem Resolution Management Plan that describes the approach to be taken in managing all problems discovered during any testing

Section 6.5,

Page 6.5-41



Req. Num.


phase and in production.

M-55 The Contractor shall install and test a single Problem Resolution Tracking System that the Contractor and CDCR shall use collaboratively for the tracking of system defects, security, and system issues. The Problem Resolution Tracking System must, at a minimum, include:

All defects in the solution identified during any testing phase or in production must be recorded, prioritized, tracked, and resolved in a timely manner. Each must be assigned a “Defect Level” based on the following definitions:

Critical - Results in a complete system outage and/or is detrimental to the majority of the development and/or testing efforts. There is no workaround.

Serious - System functionality is degraded with severe adverse impact to the user and there is not an effective workaround.

Moderate -System functionality is degraded with a moderate adverse impact to the user but there is an effective workaround.

Minor - No immediate adverse impact to the user.

The Contractor shall allow CDCR full access to the Problem Resolution Tracking System.

The Problem Resolution Tracking System shall be designed in a manner to allow for the transfer of ownership to the State following contract completion.

The processes and management of the Problem Resolution Tracking system shall be addressed as part of the Contractor Quality Management Plan.

The Contractor shall comply with the “Defect Level” approach as described above, including the requirement that SOMS Project Management shall designate the level of severity to all defects. Critical and serious defects (incidents) shall require remediation and retesting before the system enters production. Moderate and Minor defects shall be fixed and tested to CDCR’s satisfaction prior to system acceptance.

The Problem Resolution Tracking System shall provide a classification and tracking method for system or application errors that describes the severity of the defect. CDCR will determine whether that error shall be corrected and re-tested prior to the system entering production.

Section 6.5,

Page 6.5-45

M-56 The Contractor shall describe the implementation approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the implementation approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.6,

Page 6.6-1



Req. Num.


M-57 The Contractor shall incorporate the implementation approach into a comprehensive Implementation Plan. CDCR requires incremental deliveries of functionality to the production environment. CDCR anticipates considerable collaboration with the Contractor in the plan’s construction, with particular attention to high complexity components of the existing Offender Management Systems as well as the proposed solution. The Implementation Plan shall:

Deliver solutions that include a significant portion of the technical infrastructure early in the schedule, without compromising the quality or inherent security of the solution. This should also validate the design and architecture.

Expose technically challenging areas of the project as soon as possible. New external interfaces, data conversion, and complex existing Offender Management code being impacted by the new solution, should, where possible, be deployed early in the Project.

Deliver customized functionality to CDCR in incremental pieces that are in logical business application sequence.

Include a deployment schedule developed in cooperation with CDCR that ensures continuous, uninterrupted Offender Management support throughout the project.

The Bidder must submit a sample Implementation Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.6,

Page 6.6-7

M-58 The Contractor shall develop a Capacity Plan (in coordination with the existing DTS Capacity Plan) to include, at minimum, the following areas:

A description of how system capacity and capacity requirements were calculated, including all formulas and calculations used in capacity planning for SOMS.

A description of how SOMS capacity requirements will be met. How capacity issues will be managed for all components of

the SOMS project. Descriptions of how capacity utilization will be monitored and

capacity thresholds will be established. A description of corrective and escalation processes that will

be used in the event any capacity thresholds are reached.

Section 6.6,

Page 6.6-8

M-59 Disaster recovery requirements relative to the physical systems and planning for recovery from operational failures are not the responsibility of the Contractor. However, the Contractor’s knowledge of the system solution will be helpful in CDCR’s business continuity and disaster recovery planning. The Contractor shall develop an Operational Recovery Plan that addresses the following:

Section 6.6,

Page 6.6-10



Req. Num.


The SOMS solution will ensure 99.99% availability. Areas of the SOMS system most susceptible to failure or

disaster that would result in downtime. Recommendations for system recovery processes, or steps to

take in the event of a downtime event. Recommendations for CDCR on how to comprehensively and

effectively mitigate the risk of a downtime event. Recommendations for securing the system during a period of

emergency operation.

M-60 The Contractor shall describe the interface management approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the interface management approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.6,

Page 6.6-13

M-61 The Contractor shall incorporate the interface management approach into a comprehensive Interface Management Plan. The Interface Management Plan will be used by CDCR to document the plan for integrating the SOMS System with all systems internal and external to SOMS. The Interface Management Plan shall, at a minimum, address the following areas:

The approach to developing and managing internal and external system interfaces.

Technical tools that will be used for data transformation, transport and error recovery.

Tasks, deliverables and resources necessary to complete interface development and implementation.

Description of how the SOMS development and test systems will work with the external interfaces.

References to applicable sections in the relevant design documents that describe how the SOMS system will be synchronized with the specific internal and external interfaces.

References to applicable sections in the detailed design that describe the mappings between internal and external system data and the SOMS system data.

Descriptions of the process for managing changes to the interfaces, both in the production and non-production environments

Interface(s) needed for maintaining data synchronization between an interim production solution and the final production implementation.

The Bidder must submit a sample Interface Management Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.6,

Page 6.6-19



Req. Num.


M-62 The Contractor will identify any legacy modifications required for the new SOMS System and external systems to exchange data, and CDCR will be responsible for implementing requested legacy software changes.

Section 6.6,

Page 6.6-22

M-63 The Contractor shall describe the data conversion approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the data conversion approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.6,

Page 6.6-23

M-64 The Contractor shall incorporate the data conversion approach into a comprehensive Data Conversion Plan that will describe how the Contractor will manage the process of converting (as required) data from the legacy systems for use in the system, and back into the legacy environment. The Data Conversion Plan shall address, at a minimum:

A description of all data sources and data targets. A description of field mappings, tools, data validation and

cleansing methods/algorithms, and any other software programs that will be used or will need to be written to support data conversion. A description of how converted data will be validated to be correct before use.

A description of the approach to converting legacy data to required formats.

A description of the approach to synchronizing the data between the new system and legacy systems that will rely on updates provided by the new system.

A description of how data anomalies and errors will be handled.

A schedule of deliverables and resources needed to complete the conversion effort.

Detailed descriptions of how the data conversion tools provided by the contractor will be operated for each phase of the SOMS solution delivered to the Pre-production environment.

How converted data will be delivered as required to support each phase of the SOMS solution delivered to the pre-production and production environments.

The processes for delivery of the software and hardware configuration information used in creating the converted data, at the time the data is delivered to the pre-production and production environments.

Description of how the data reconciliation process will work.

The Bidder must submit a sample Data Conversion Plan with their proposal response as identified in Section VIII –

Section 6.6,

Page 6.6-31



Req. Num.


Proposal and Bid Format.

M-65 The Contractor shall incorporate the paper documentation conversion approach into the comprehensive Data Conversion Plan that will describe how the Contractor will manage the process of converting (as required) data from CDCR’s paper documentation for use in the system. The Data Conversion Plan shall address, at a minimum, the following areas:

A description of all data sources (CDCR forms and data fields) and data targets.

A description of field mappings, tools, data validation and any other software programs that will be used or will need to be written to support data conversion. A description of how converted data will be validated to be correct before use in the new production system.

A description of the approach to converting paper documentation to required formats.This approach must take into consideration that there is no space for contractor staff within the facilities to perform the backfire conversion.This approach must also take into consideration that the retention of the paper documentation after conversion will be CDCR’s responsibility.

A description of how data anomalies and errors will be handled.

A schedule of deliverables and resources needed to complete the conversion effort.

Detailed descriptions of how the data conversion tools provided by the contractor will be used to convert the paper documentation.

How converted data will be delivered as required to support each phase of the SOMS solution delivered to the pre-production and production environments.

A description of how the data reconciliation process will work.

The Bidder must submit a sample Data Conversion Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.6,

Page 6.6-34

M-66 The Contractor shall configure all required data conversion tools, software and hardware.

Section 6.6,

Page 6.6-37

M-67 The Contractor will be responsible for converting all data required from the legacy environment to the new SOMS system. While the Contractor will provide the tools and methodology for converting the legacy data, CDCR will provide dedicated resources to assist the Contractor in understanding the legacy data, assistance in data extracts and data loads, and assisting the Contractor in

Section 6.6,

Page 6.6-38



Req. Num.


resolving problems related to the data conversion efforts.

M-68 The Contractor shall be responsible for converting data from the legacy database(s) as required to support the new SOMS system.

Section 6.6,

Page 6.6-38

M-69 With each Pre-Production Release that requires use of data converted from the legacy environment, the Contractor shall provide an updated Data Conversion Release document. This document must include the following:

A description of the field mappings, tools, and programs used to support data conversion.

A description of data that was validated and tested. A description of how data anomalies and errors were

addressed. A description of the resources and tools used to create the

converted data. The configuration information for the tools and scripts used to

produce the converted data. A description of any data conversion issues that may impact

the production environment.

Section 6.6,

Page 6.6-39

M-70 The Contractor shall provide a software configuration management system to store, control, and track instances (baselines during the construction lifecycle) of all software configuration items that shall be developed for the State.

Section 6.6,

Page 6.6-39

M-71 The server(s) that house the Contractor’s software configuration management systems shall reside at the State, and the software configuration management system shall be accessible by State personnel.

Section 6.6,

Page 6.6-40

M-72 The Contractor must use an industry standard software configuration management tool; CDCR has used SAP’s configuration management tool and Microsoft Visual SourceSafe.

Section 6.6,

Page 6.6-40

M-73 The Contractor shall describe the requirements management approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the requirements management approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.6,

Page 6.6-41

M-74 The Contractor shall incorporate the requirements management approach into a comprehensive Requirements Management Plan. The Requirements Management Plan will be used by the project to assure that requirements are met. The Requirements Management Plan shall, at a minimum, address the following areas:

Section 6.6,

Page 6.6-48



Req. Num.


Establishment of a baseline for existing requirements. Management of versions of requirements. Establish and maintain CDCR’s requirements traceability

matrix that will be used for requirements management, and will map where in the software a given requirement is implemented.

A requirements change control process. A methodology for managing requirements in an iterative

development lifecycle. Procurement, installation, and administration of requirements

management tools. A description of the relationship between the requirements

management role and the other roles (i.e. test management, quality assurance management) on the project.

Publishing of standard reports related to requirements management.

The Bidder must submit a sample Requirements Management Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

M-75 When functionality is ready to be delivered to CDCR for User Acceptance Testing (UAT), it shall be delivered in the form of a Pre-Production Release. Since CDCR will perform UAT and approve all releases into production, a pre-production release is equivalent to a production release and requires the rigor associated with a production release. Upon successful completion of UAT, CDCR will schedule a release to be moved to the Production environment. Each Pre-Production Release shall include the following:

Release-specific Hardware and Software solution components.

An updated Data Conversion Release document. Release Description including Architecture or Design updates,

new functionality introduced, defects fixed, modifications to interfaces with other systems, other changes to existing code, and any software and hardware configuration changes.

Release Contents including a description of the release structure and contents and instructions for assembling and/or configuring the components of the release.

Test Plan and test execution results. Detailed hardware and software configuration information

including any software and hardware dependencies and instructions at a level of detail that will enable DTS system administration staff to rebuild and configure the hardware environment without outside assistance.

Database documentation conforming to industry standards.

Section 6.6,

Page 6.6-49



Req. Num.


Detailed configuration information for any 3rd party hardware and software.

The Contractor shall provide updated documentation when system upgrades to software or equipment occurs through the life of the contract.

M-76 Implementation is expected to be iterative from both a business process and applied technology perspective. CDCR will accept the products into the production environment through application of the acceptance criteria testing plans. For releases that include either servers at DTS, or that impact the data network provided by DTS, representatives of DTS must have been trained, and their own internal checklists must have been met, prior to a production release date being scheduled.

Section 6.6,

Page 6.6-50

M-77 The Contractor shall deliver to CDCR, a Requirements Traceability Matrix for all delivered functionality, showing all testing activities tracing to delivered functionality, and all delivered functionality tracing to requirements in the requirements repository.

Section 6.6,

Page 6.6-51

M-78 The Contractor shall validate that each interface to an external system is working correctly. The Contractor will repair all interface-related problems caused by contractor-developed interfaces.

Section 6.6,

Page 6.6-51

M-79 The Contractor shall assist CDCR with testing and release preparation in the pre-production environment.

Section 6.6,

Page 6.6-52

M-80 The Contractor must produce and execute an On-Site Implementation Support Plan.

Section 6.6,

Page 6.6-53

M-81 The Contractor must provide staff at the proposed number of staff, ratios and duration for on-site support.

Section 6.6,

Page 6.6-53

M-82 The Contractor must assess the pre-implementation readiness of each part of the organization and shall document the status in a Pre-Implementation Readiness Assessment.

The Contractor shall conduct an implementation readiness review ten days prior to cutover at each part of the organization.

Section 6.6,

Page 6.6-54

M-83 Upon successful completion of the Pre-Production testing, the Contractor shall, in coordination with CDCR, create a Production Release Plan that shall consist of an updated Pre-Production Release notification to assist CDCR in successfully releasing and maintaining the system in the Production environment. It must include, but not be limited to, the following components:

Updated Configuration Information required satisfying the CDCR production configuration management requirements.

Section 6.6,

Page 6.6-54



Req. Num.


Updated System Architecture. Updated Detailed Design, including detailed system, technical,

and user documentation. An updated Data Conversion Release document. Deployment schedule.

M-84 The Contractor shall describe the security approach used for the SOMS project.

The Bidder must submit a narrative describing the security approach with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.7,

Page 6.7-1

M-85 The Contractor shall provide a System Security Plan that describes the security approach for the system. In the area of security, CDCR operates under federal and state laws and policies. In addition, because of the expected interactivity with other entities (i.e., Attorney General, DOJ, Courts, law enforcement agencies, etc.), a comprehensive plan must explain how SOMS will respect and coordinate when necessary with the security constraints of other entities. The System Security Plan, an official document, shall address, at a minimum, the following areas:

General Information about System Environment, Interconnections/Information Sharing, Applicable Laws or Regulations, Information Sensitivity, Responsible Parties, General System Description

Security Controls pertaining to Risk Assessment and Management, User Rules or Behavior, Implementation Phase, Operation and Maintenance Phase

Operational Controls pertaining to Personnel Security, Physical and Environmental Protection, Input/Output Controls, Contingency Plans, Maintenance, Integrity, Documentation, Training, Incident Response

Technical Controls pertaining to User Identification and Authentication, Logical Access Controls, Audit Trails

Section 6.7,

Page 6.7-5

M-86 The Contractor shall describe the quality management approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the quality management approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.8,

Page 6.8-1

M-87 The Contractor shall develop a Quality Management Plan to describe the approach they will use to ensure the quality of the work as it pertains, at a minimum, to the following items:

CDCR’s management of the requirements. This includes the identification of inconsistencies between the requirements,

Section 6.8,

Page 6.8-7



Req. Num.


and the project's plans and work products. CDCR’s requirements traceability matrix that will be used for

requirements management, and will map where in the software a given requirement is implemented.

CDCR’s configuration management activities that include: baseline control, and monitoring the software library. Approved changes to baseline software and/or documentation should be made properly and consistently in all products, and no unauthorized changes are to be made.

The practices and procedures that will be followed for reporting, tracking, and resolving problems or issues identified in software development, system transition, and system maintenance.

The practices and procedures that will be followed for data and paper conversion.

The business process changes resulting from SOMS. A change readiness assessment of CDCR’s organization. This

may include a gap analysis and recommendations for organization change required to support SOMS.

The quality of work products developed and delivered by Contractor’s sub-contractors/partners, if applicable.

M-88 The Contractor shall also describe in the Quality Management Plan how they will go about implementing the following in order to facilitate the Quality Management Process:

A metrics process that describes how measurements will be identified, collected, and analyzed to ensure that quality goals, including management and system goals, are being met. It should also describe the types of project metrics used.

The Contractor’s organizational structure, and the roles and responsibilities of Contractor staff as they relate to quality management.

Description of the processes and management of the Defect and Issue Tracking system for resolution of items and, if applicable, how corrective action plans will be developed to address more significant issues.

The Bidder must submit a sample Quality Management Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.8,

Page 6.8-9

M-89 The Contractor shall describe the production support and transition approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the production support and transition approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.9,

Page 6.9-1



Req. Num.


M-90 The Contractor shall incorporate the production support and transition approach into a comprehensive Production Support and Transition Plan (Software Transition Plan) complying with IEEE 12207.2, section 5.3.3 - system architectural design, that will describe how the Contractor intends to support the System and transition that support over to the responsible State entities. Additionally, the Production Support and Transition Plan must address how the Contractor will provide support of the State’s Post Implementation Evaluation Report (PIER) process in accordance with the Department of Finance (DOF) Statewide Information Management Manual (SIMM) including an Identification of Lessons Learned.

The Bidder must submit a sample Production Support and Transition plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.9,

Page 6.9-46

M-91 The Contractor shall, at a minimum, provide routine system upgrades and fixes to Contractor software at no additional cost. In addition, the Contractor shall provide at no additional charge, routine system upgrades and fixes to COTS software and field/technical services bulletins periodically as they become available within 24 hours after they receive them from COTS licensors, subcontractors, manufacturers, and other third parties.

Section 6.9,

Page 6.9-47

M-92 The Contractor shall provide CDCR with a list of personnel, contact information, and their area of expertise of who shall be performing system production support.

Section 6.9,

Page 6.9-47

M-93 The Contractor shall repair any corrupted data that is associated with a system problem.

Section 6.9,

Page 6.9-49

M-94 With concurrence from CDCR, the routine planned maintenance activities shall be scheduled without disrupting the 24x7 operational hours. Contractor shall provide CDCR with a copy of the schedule at least 30 days in advance of the scheduled maintenance date for approval.

Section 6.9,

Page 6.9-49

M-95 The testing tools and test configurations shall be provided to the State as the systems are transitioned into support.

Section 6.9,

Page 6.9-50

M-96 The Contractor shall provide instructions and training for CDCR support staff that may need to access and support the system remotely.

Section 6.9,

Page 6.9-50

M-97 The Contractor shall develop an automated process for purging production system files when necessary.

Section 6.9,

Page 6.9-50

M-98 The Contractor shall establish an automated maintenance routine that shall backup the user IDs and password data. The Contractor

Section 6.9,

Page 6.9-51



Req. Num.


shall also, as a regular maintenance routine, delete or move expired IDs and related data.

M-99 Upon completion of any maintenance call, the Contractor shall furnish a maintenance activity report to CDCR within 24 hours, which shall include, at minimum, the following:

Date and time notified. Date and time of arrival. If hardware, type and serial number(s) of machine(s). If software, the module or component name of the affected

software code. Time spent for repair. List of parts replaced and/or actions taken. Description of malfunction or defect.

Section 6.9,

Page 6.9-51

M-100 The Contractor must produce a System Operation Manual, which includes System Administration procedures.

Section 6.9,

Page 6.9-52

M-101 The Contractor must produce and execute a Help Desk Plan. The State will provide information (including processes, procedures, description of physical infrastructure, and access to a limited number of help desk staff) to the Contractor to facilitate development of the Help Desk Plan.

Section 6.9,

Page 6.9-52

M-102 The Contractor must use a Help Desk tracking tool that employs access control mechanisms.

Section 6.9,

Page 6.9-52

M-103 During the maintenance period, the maximum time to restore the functionality of applications and resolve incidents shall be within the timeframes listed below, based on the Error: Reference source not found.

Severity Level One incidents shall not exceed one (1) clock hours between the opening of an incident and final closure, unless a time extension is approved by CDCR.

Severity Level Two incidents shall not exceed six (6) clock hours between the opening of an incident and final closure, unless a time extension is approved by CDCR.

Severity Level Three incidents shall not exceed 24 business hours between the opening of an incident and final closure, unless a time extension is approved by CDCR.

Severity Level Four incidents shall not exceed 40 business hours between the opening of an incident and final closure, unless an extension of time is approved by CDCR.

Section 6.9,

Page 6.9-53

M-104 The Contractor will work with CDCR technical and program staff to fix problems, optimize the system, and implement changes to the internal SOMS system, external SOMS web system, that supports

Section 6.9,

Page 6.9-54



Req. Num.


SOMS functionality, Business Intelligence system supporting SOMS, and Web Content Management system. This will include making changes, testing changes, and providing documentation for changes and test results.

M-105 The Contractor will respond to critical service requests with a response time not to exceed 2 hours. A critical service request involves failure or degraded operation of a hardware or software component that prevents or seriously impedes CDCR in performing work, and there is no viable or sufficient workaround, redundancy, or backup capability that permits unimpeded operation.

Section 6.9,

Page 6.9-55

M-106 The Contractor will respond to non-critical service requests with a response time not to exceed 4 hours. A non-critical service request involves failure or degraded operation of a hardware or software component where there is a viable workaround, redundancy, or backup capability that permits continued satisfactory operation.

Section 6.9,

Page 6.9-55

M-107 There shall be one System Acceptance event for the full Offender Case Management System. This System Acceptance event will mark the end of successful Production and Support and the beginning of Maintenance and Operations.

Section 6.9,

Page 6.9-56

M-108 Conditions for System Acceptance shall include:

Infrastructure must be hosted by the State. Change configuration and release management must be

provided by the State. The State must be able to provide application maintenance,

development and testing immediately after acceptance of the SOMS system without the Contractor’s intervention.

All ownership of licenses and maintenance contracts must be

transitioned from the Contractor to the State. The State (DTS) will provide software vulnerability risk

assessment for all third party software include in vendor’s solution.

The resolution of all documented Contractor-responsible deficiencies as stipulated through the approved defect and issue tracking process.

The SOMS System successfully performs in the production environment for a period of thirty (30) consecutive business days without any level 1 or level 2 deficiencies.

Section 6.9,

Page 6.9-57



Req. Num.


Knowledge transfer and training for end users has been provided.

The successful completion of all other work breakdown structure elements, tasks, and deliverables as specified in the Contractor project schedule as approved by the State.

M-109 Once all System Acceptance conditions have been met, the Contractor shall provide to the State for approval, a System Acceptance document that shall include a final Requirements Traceability Matrix identifying all SOMS system requirements allocated to current, in-production system components. Sign-off of this document by CDCR will constitute System Acceptance and trigger the beginning of Maintenance and Operations.

Section 6.9,

Page 6.9-58

M-109b The Contractor must include a system warranty of six (6) months beginning in conjunction with the Six (6) month post implementation maintenance and support period. The Contrator must describe, in response to this paragraph, the provisions of their warranty(s) including responsibilities for invocation, response, equipment and software failures, etc.

Section 6.9,

Page 6.9-59

M-110 Upon System Acceptance, the SOMS System will be turned over to CDCR and DTS for Maintenance and Operations (M&O). To prepare CDCR and DTS for this transition, the Contractor, CDCR, and DTS will partner in order to develop and assimilate the CDCR/DTS M&O operations team with an CDCR/DTS M&O Plan. The Contractor shall develop a formal methodology to be used by CDCR and DTS to manage and operate the new system during CDCR/DTS M&O that is documented in the CDCR/DTS M&O Plan. The Contractor shall replace all other SOMS and Contractor project management plans with the CDCR/DTS M&O Plan at the conclusion of Production Support. The M&O Plan shall incorporate methodologies and practices which will assist CDCR and DTS in successfully managing the SOMS system's M&O lifecycle and shall address the following areas:

Support Model. Triage Procedures. Tools. Identification of Roles and Responsibilities of support

personnel. Release Management. Upgrades. Maintenance. On-going Operations. Customer Support. Specific support procedures for production. Deliverables.

Section 6.9,

Page 6.9-61



Req. Num.


Resource Requirements (staff loading). Business Services Migration. Capacity Management. Technology Refresh. System Security. Backup and Recovery. Disaster Recovery. Defect/Issue management.

M-111 The Contractor must describe the staffing approach and methodology used for the SOMS Project, which shall include:

Estimated number of vendor’s resources needed per each phase of the project.

The number of staff resources within the following categories: Management, Business, and Technical.

A description of the methodology used to releasing and adding staff to the project.

Providing a project organization chart, with as many of thepersonnel identified (named) as are known, including theKey Personnel accepted during the Pre-QualificationPhase of the procurement.

The Bidder must submit a narrative describing the Bidder’s staffing management for the SOMS Project with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.10,

Page 6.10-1

M-111b The Contractor must not reassign contractor key personnel if such reassignment will conflict with the work the individual is to perform on this contract. CDCR recognizes that resignation or other events may cause a contractor team member to no longer be available to the contractor. If this should occur, the contractor should be aware that the CDCR contract administrator or designee must approve any changes to contractor proposed key personnel assigned by the contractor to the contract prior to contractor staff beginning work on the contract. This also includes substitutions made between submittal of the final proposal and actual start of the contract, as well as staffing changes that may be made during the course of the contract. Any replacement personnel proposed during the life of the contract must meet or exceed the skill level that the contractor propsed and was scored on. CDCR will not compensate the contractor for any of the contractor’s time or effort to educate or otherwise make the new staff ready to begin work on the contract.

Section 6.10,

Page 6.10-14

M-111c The Contractor must not perform any work offshore; all work must be performed within the continental U.S., specifically within the Sacramento region, or at a minimum, a location approved by

Section 6.10,

Page 6.10-15



Req. Num.


CDCR.

M-112 The Contractor shall only be allowed to access the SOMS network while on-site. No remote access hardwired/wireless to the State network shall be allowed without special arrangements being made with CDCR; the Information Security Office will hold approval.

Section 6.10,

Page 6.10-15

M-113 Information placed on removable media must conform to the policies laid out in Department of Finance (DOF) Budget Letter BL05-32 (11/05) and State Administrative Manual chapter 4841.2 Information Integrity and Security.

Section 6.10,

Page 6.10-15

M-114 The Contractor must notify the State data owners and the CDCR Information Security Office (ISO) within two (2) hours of a suspected or real security incident involving any information asset, including, but not limited to: responding to availability outages; equipment failures, system or data integrity; or losses, misuse, or improper access to or dissemination of information.

Section 6.10,

Page 6.10-16

M-115 The Contractor shall work with CDCR and DTS to configure the interfaces between the new SOMS environment and the existing CDCR legacy environment.

Section 6.10,

Page 6.10-16

M-116 The Contractor agrees that all materials and documents that are developed as part of the SOMS project shall become the property of the State. Materials and documents copyrighted prior to the date of contract signature are exempted from this provision.

Section 6.10,

Page 6.10-16

M-117 The Contractor shall store all work products and deliverables on the State’s local area network (LAN) at all times. The most current version of all work products and deliverables must be continuously available for State review at all times.

Section 6.10,

Page 6.10-16

M-118 The Contractor shall comply with all applicable CDCR policies and procedures and shall return all State property including security badges prior to termination of the Contract.

Section 6.10,

Page 6.10-17

M-119 CDCR will designate a “State Project Director” to whom all project communications may be addressed and who has the authority to act on all aspects of the Contract. CDCR will also designate a “State Project Manager” to oversee the day-to-day State activities.

Section 6.10,

Page 6.10-17

M-120 CDCR shall provide all naming convention, IP addresses and managed access to the existing development, test, and pre-production systems.

Section 6.10,

Page 6.10-17

M-121 CDCR will provide information as required by the Contractor to perform its responsibilities under this Contract and timely review and approval of the Contractor’s information and documentation.

Section 6.10,

Page 6.10-17



Req. Num.


M-122 CDCR shall provide the following items to the Contractor to support this effort: office space for the duration of the Contract including: desk, chair, telephone, personal computer, printer access, Internet connection, Microsoft Office, Microsoft Project and technical support for adding Contractor-owned software required for completion of this Contract.

Section 6.10,

Page 6.10-18

6.1 PROJECT MANAGEMENT

Subsection 6.1: Project Management

This subsection must include a narrative describing the QBP’s approach to project management including methodology to be used and a sample Project Management Plan as described in Section VI.D.3 – Project Management.

6.1.A Project Management

VI.D.3. Project Management

Req.

Num.Requirement Response / Reference

M-1 The Contractor must employ, maintain, and execute a project management methodology that complies with the Institute of IEEE Standards for Project Management Plans (IEEE Standard 1058-1998 and 1490-2003).

Section 6.0

Bidder Response Detail:

Team EDS complies with Management requirement number M-1 and we will employ a suite of standards-based methodologies and tools to partner with the California Department of Corrections and Rehabilitation (CDCR) in executing and managing the Strategic Offender Management System (SOMS). As outlined in our response to project management requirement number M-2, our project management approach defines the SOMS initiative as a project with nine distinct, interrelated subprojects. To manage and integrate the SOMS project, EDS uses our proven Global Program Management Architecture (GPMA™) and the Global Applications Delivery Quality Management System (GAD QMS) framework. As described in Section 6.0, Management Requirements Response, EDS’ program management methodology supports the Software Engineering Institute (SEI®) Capability Maturity Model Integration (CMMI®) approach to process improvement. EDS’ GPMA and GAD QMS framework are extensible in design and enable the use of a range of standards-based project management and life-cycle management tools. For the SOMS project, our team uses EDS’ preferred and widely deployed Project Management, Version 2 (PM 2®) methodology.



Just as our GPMA is standards-based, PM 2® conforms to internationally recognized project management standards. PM 2® is based on the Project Management Institute’s (PMI’s®) Project Management Body of Knowledge (PMBOK®) guidelines and CMMI tools, techniques, and processes; hence, it is complaint with IEEE Standard 1490-2003. Furthermore, PM 2® addresses the same topics as a software project management plan (PMP) that is compliant with IEEE Standard 1058-1998.

M-2 The Contractor must describe the project management approach and methodology to be used for all SOMS Project lifecycles.

The Bidder must submit a narrative describing their approach to project management with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 4.2.I,

Section 4.2.D,

Section 6.8,

Section 6.0,

Section 6.6,

Section 6.10


Approach to Project Management

Various aspects of our overall approach to project management are described in the following subsections:

EDS’ Philosophy for Establishing a Successful Partnership

Designing the SOMS Project to Facilitate Success

Applying Industry Best Practices and PMI Principles

Planning and Executing Project Management Processes

EDS’ Proven Organizational Structure and Delivery Techniques

EDS’ Philosophy for Establishing a Successful Partnership

EDS has a long history of successfully completing large-scale projects by focusing on client needs through strong project governance and project management. As described in Section 4.2.I, Partnering, we work closely with CDCR staff to establish a governance structure and a cohesive partnership focused on common project goals and objectives. Because the project management environment is crucial to establishing a successful partnership, our top priorities at the onset of the project are to apply project management processes to:

Establish lines of communication with CDCR to initiate the project

Establish the Project Management Office (PMO) and governance structure and induct the project managers

Integrate and align PMBOK®-based project management practices with CDCR’s project management methodologies throughout phases of the project from project initiation through project closing

Finalize the project plans, including work breakdown structures and schedules, through coordinated planning sessions between the CDCR and Team EDS.



With CDCR’s needs in mind, EDS has gathered a talented team to deliver premium project management services. Every day, we focus on the use of proven industry-standard processes and best practices for project-level activities, aligning the SOMS project plan with PMBOK® guidelines for management of project scope, schedule, cost, quality, staffing, communications, risk, integration, and procurement management. Our close collaboration with CDCR, subject matter experts (SMEs), and other project stakeholders in every aspect of the project is absolutely essential to project success.

Team EDS’ experienced leaders know that time invested on project planning activities forms the foundation for successful project management. During startup, we refine the project work plan, developed during the proposal process, to manage and control our execution of the project. Our leadership team uses and maintains the project plan as the basis for tracking project progress. With consensus from CDCR, Team EDS establishes procedures for updating the PMP and for assessing the impact that the corresponding modification(s) could have on the project and the organization.

Designing the SOMS Project to Facilitate Success

As described in Section 4.2.D, Phasing, our project plan is designed to reduce project risks while delivering “quick wins” to CDCR through concurrent development and configuration of software releases. Team EDS proposes to design the SOMS project to facilitate management of the following distinct work streams:

Project Administration – This includes activities related to startup, operation, and closing of the PMO

Offender Management Software Phase I (subdivided into Release 1A, 1B, and 1C)

Offender Management Software Phase II

Offender Management Software Phase III

Electronic Records Management System (ERMS) – This involves the project to convert existing paper documents contained in C-Files, P-Files, and Juvenile-Files into electronic images, and to institute procedures for day forward processing of paper documents

Infrastructure/Hosting Delivery – This involves assessing and deploying enterprise system architecture and related infrastructure needed for delivery of the comprehensive SOMS solution, including hardware, software, and tools for hosting the five system environments

Maintenance and Operations – On-going support of the solution and activities to prepare CDCR to take over operations at contract’s end.

Each of these work streams are treated as a subproject with detailed work tasks for each subproject defined in our draft PMP. Our response to Management requirement number M-3 outlines our draft PMP, while Appendix A provides the actual draft PMP, with a detailed description of each work stream’s deliverables, tasks, activities, and schedules.



Applying Industry Best Practices and PMI Principles

Team EDS’ Project Management Version 2 (PM 2®) methodology is designed to support industry best practices and the Project Management Institute’s (PMI’s®) project management principles. Figure 6.1-1, EDS’ Project Management Methodology, illustrates how EDS’ PM 2® methodology incorporates PMI’s® PMBOK® knowledge areas and Carnegie Mellon University’s SEI® CMMI “best practices” approach to process improvement.

PMI Body of Knowledge Management Functions

• I ntegration

• Scope

• Time

• Cost

• Quality

• Human Resource

• Communications

• Risk

• Procurement

Carnegie Mellon University Software Engineering Institute

Capability Maturity Model

L1 – Initial

L2 – Repeatable

L3 – Defined

L4 – Managed

L5 – Optimized

EDS Management Experience

EDS Project Management Methodology

Figure 6.1-1, EDS’ Project Management Methodology

In addition to PMBOK® and CMMI industry standards, PM 2® has been designed with a focus on usability and scalability. Appropriate work elements (process steps or actions) and work products (process inputs and outputs) offer conditional scenarios to enable the project manager to tailor the PM 2® methodology to CDCR’s specific requirements. Providing the ability to tailor processes, inputs and outputs within all nine PMBOK® knowledge areas helps project managers achieve the objectives defined for the project while faced with budget, time, resource, and technology constraints.

Figure 6.1-2, EDS’ Project Management Capabilities, illustrates each of the project management knowledge areas for which PM 2® supplies practical tips, proven techniques, and suggested work products to help project managers make decisions that lead to successful delivery of the project.



Cost

Time

Scope

Integration

Human Resources

Communications

Risk

Procurement

Quality

EDS’ Project Management Capabilities

• Consistent, repeatable processes• Responsiveness to program changes

• Effective use of skills and time

• Structured environment for success• Enhanced communication among stakeholders

• I nsight into the project• I ncreased quality

• Earlier corrective action and risk avoidance

• Better monitoring and control of cost• On-time and high quality delivery

Figure 6.1-2, EDS’ Project Management Capabilities

PM 2® is also designed to support integration and interaction of work activities and processes contained in the five PMI-defined Project Management Process Groups:

Initiating Process Group

Planning Process Group

Executing Process Group

Monitoring and Controlling Process Group

Closing Process Group

PM 2® guides our project managers iteratively through the “plan-do-check-act” cycles and the inter-related project activities defined by the five PMBOK® Process Groups. EDS’s PM 2® methodology fosters client involvement and enforces rigorous processes to facilitate effective initiation, planning, execution, monitoring and control, and project closing to achieve a successful SOMS project.

Figure 6.1-3, EDS’ Approach to Managing Projects, illustrates how EDS focuses critical project management processes on CDCR’s requirements, and how we carry out management processes concurrently across all five of the PMI-defined Process Groups (initiation, planning, project execution, monitoring and control and project closing) as described below.



Figure 6.1–3, EDS’ Approach to Managing Projects

1. Initiate Project – EDS’ carries out Project Initiation processes to confirm and document the project scope and objectives, to define project standards and procedures, and to establish the project team. Project initiation also includes establishing the local project facilities, planning and implementing the project infrastructure, and organizing the project team. A formal kickoff meeting between EDS and CDCR is a key initiating process for the project.

2. Plan Tasks – Planning processes entail defining the baseline work plan by defining tasks, time and resources required, and work assumptions and constraints. The work plan evolves as the project moves through its various stages and is updated through the change control process.

Planning processes involve a high degree of interaction between EDS and CDCR. We review with CDCR work to be performed through scope planning and definition. We gain the participation of those best qualified to do the work, and collaborate with CDCR to confirm the appropriate schedule and quality objectives. In our experience, the initial startup activities are of utmost importance to the ultimate success of the project. We have found that quickly establishing the governance structure and implementing effective project management plans and procedures set the tone for the entire project. Thus, our initial planning processes focus on the following objectives:

– Establish PMO, project roles, responsibilities, and staffing



– Develop the project plan

– Prepare and manage the work plan

– Activate progress and status reporting

– Establish quality management provisions

– Establish risk management procedures

– Establish change control procedures

– Establish configuration management procedures

– Finalize the communication management plan.

Shortly after contract award, project manager Brian Hodgson will delineate specific responsibilities and schedules to the EDS SOMS project team. Core members of Team EDS’ SOMS project team—including the project manager, senior architect (technical lead), deputy project manager for implementation, business architect, electronic Offender Management Information System (eOMIS) software development manager, and data conversion lead—have been involved in the proposal phase of the SOMS initiative. As a result, our team will “hit the ground running,” rapidly ramping up our PMO and assigning roles and responsibilities.

3. Execute Plan – Project execution processes provide a framework to guide project activities in an effective and efficient way so that measurements against project plans, specifications, and the original project concept continue to be collected, analyzed, and acted on throughout the project. Our project execution process provides the project team with an efficient method to control, track, and report progress.

During the project execution activities, EDS’ project manager, working in concert with the track managers, supports and monitors the execution of critical project plans, such as the Software Development Plan, the Implementation Plan, the Quality Management Plan, and the Reporting and Communications Plan. Team EDS works with CDCR project teams to complete tasks and activities and to manage variances from the work plan, identify changes, and distribute information about the project.

4. Monitor Progress – Project monitoring and controlling processes include those activities and tasks that provide visibility into the status and progress of the project to make sure that it is proceeding according to plan and that it achieves the stated goals. This visibility permits appropriate actions to be taken when the project’s performance metrics indicate potential or actual deviations from the project plan and schedule. These activities include the regular review of metrics and reporting of status in order to identify variances from the planned project baseline. The variances are determined by comparing the actual performance metrics collected in Project Execution activities against the baseline metrics assigned during the Planning phase. If significant variances are observed (that is, variances that jeopardize the completion of the project objectives), adjustments to the plan are made by repeating and adjusting the appropriate project planning processes.



EDS’ governance model includes a dedicated PMO that facilitates the execution of these activities. We monitor and control the project using measurement and analysis to identify variances from the plan, and report these results to CDCR. The implementation manager and software development manager, with support from the project managers, direct, monitor, adjust, document, and control changes to the scheduled activities to support compliance.

5. Close Project – Project closing processes involve formalizing acceptance of project outcome, verifying contract closeout, and bringing the project to a smooth ending. Specifically, closing the project includes post-project review, preparation of project experience summary, archiving project records, project inventory disposal, and disbanding the project team.

Key activities in project closeout include the following:

Closeout of any financial issues such as labor charge codes and contract closure

Completing, collecting, and archiving project records

Documenting the successes and issues of the project

Conducting a lessons learned session.

Team EDS closes the SOMS project in an orderly, controlled manner by conducting administrative closure, verification of project results, and formal acceptance of project outcomes. Administrative closure is the process of preparing closure documentation for the deliverables presented to the State, as well as taking other administrative actions to confirm that the project and its assets are redistributed. Delivering closure documentation does not simply mean obtaining an approval or acceptance signature on the deliverable, but involves a series of steps to confirm that the product meets or exceeds CDCR’s expectations and conforms to the system requirements and specifications.

Planning and Executing Project Management Processes

Consistent with our adherence to PMI principles, Team EDS exercises methodical project management over the length of the SOMS project using the PM 2® methodology. Our project management plan organizes and assigns project management activities in accordance with the nine PMBOK® Knowledge Areas, as shown in Figure 6.1-4, Project Management Activities.



I ntegration Management Scope Management Time Management

• Project Plan Development• Project Plan Execution• Overall Change Control• Project Management Plan

• Initiation• Planning• Definition• Verification• Change Control• Scope Management

• Activity Definition• Activity Sequencing• Activity Duration• Estimating• Schedule Development• Schedule Control• Project Schedule

Cost Management Quality Management Resource Management

• Resource Planning• Estimating• Budgeting• Control

• Quality Assurance Plan• Software Development Plan• Configuration Management Plan

• Organizational Planning• Staff Acquisition• Team Development

Communications Management Risk Management Procurement Management

• Planning• Information Distribution• Performance Reporting• Administrative Closure• Communications Plan• Documentation Plan• I ssues and Incidents Plan

• Identification• Quantification• Response Development• Response Control• Risk Management Plan

• Planning• Solicitation Planning• Source Selection• Contract Administration• Contract Close-out

Project Management Activities

Figure 6.1-4, Project Management Activities

These processes provide project managers with a consistent and disciplined approach to controlling the progress of the project, and the quality of the deliverables and outcomes. The project plans developed during the initial project planning stage lead the PMO to continually monitor these knowledge areas as described in the following sections.

Integration Management

Integration management includes the processes and activities involved in coordinating and integrating with the project management processes for the CDCR system. The PMO team prioritizes among competing project objectives and alternatives to meet project goals and stakeholder expectations. The EDS PMO team works with the CDCR to make sure that project activities are synchronized and geared toward the success of the new CDCR system.

Project integration management includes the following:

Knowing where to concentrate resources and effort each day

Anticipating potential issues and dealing with them before they become critical

Coordinating work to meet the overall project objectives.



Developing the SOMS Project Plan

The EDS SOMS project delivery team continues to refine our draft project plans from the date we are notified of award to the contract start date. Through these efforts, shortly after contract award, Team EDS reviews a more detailed second draft of project plans with CDCR’s team. The purpose of reviewing a second draft of the PMP in the early days of the project is to make sure that the PMP products delivered within 30 days of award are aligned with CDCR’s expectations.

Our team also aims to promptly “lock down” components of the PMP that serve as inputs to other parts of the plan. For example, shortly after contract award, our team finalizes the project charter, the roles and organizational structure of EDS’ project management team, and the project scope statement. In so doing, our team works with CDCR staff to document the structure and roles of CDCR’s project team and to define key project stakeholders and CDCR subject matter experts.

From the onset of contract award, Team EDS performs stakeholder analysis to document a thorough understanding of stakeholder needs and expectations. Like most project management activities, we take an iterative approach to defining stakeholders and their requirements. Throughout the project, we continually seek clarity with stakeholders on their expectations, which provides essential input into other parts of the PMP. For instance, stakeholder relationships and stakeholder requirements provide critical input for communications and risk management.

Project scope is another example of an essential deliverable that must be finalized as soon as possible after contract award. The PMP defines project scope and how we integrate changes to the scope. The scope management plan describes procedures for identifying and evaluating requested scope changes, and for determining the impact that scope changes could have on project schedule, cost, and risk. A best practice that Team EDS employs is to engage a Change Control Board (CCB) to review requests for changes in project scope or requirements.

An important activity within the context of defining scope is to provide deliverable expectation documents (DEDs). Concise, comprehensive DEDs are critical to facilitating a common understanding between EDS and CDCR on what constitutes an acceptable deliverable. Likewise, the earlier that DEDs are established, the sooner our team can facilitate compliance with specific requirements.

Appendix B contains a draft work plan for the SOMS project. The draft work plan, developed in Microsoft Project, describes work activities, dependencies, and durations with a focus on Team EDS’ responsibilities. Shortly after contract award, Team EDS reviews the draft work plan with appropriate CDCR team members to refine the plan and to integrate specific activities with CDCR staff. Project and phase managers update the work plan frequently throughout the length of the project to document completed tasks and to update task schedules.



Integration Management Responsibilities

For SOMS, the systems integration project manager, deputy project manager for implementation, senior architect, phase managers, the software development manager, and members of the CDCR project management team provide oversight and guidance to verify that components of the solution and business functions come together as designed in accordance with planned schedules. A key activity includes integrating the impact of issues and defects on project risks, scope, time, quality, and schedule. This team re-executes planning exercises as required to manage interdependencies and to control changes across projects.

Scope Management

Through careful attention to project scope, Team EDS focuses on achieving the SOMS project objectives and moving SOMS toward achieving success. EDS understands that the project scope is not static and may evolve, and recognizes the importance of proper scope control. Project scope management is conducted in the context of program-level integrated planning and dependency management, allowing alignment between individual stages of the project and other concurrent efforts to produce the desired project results. To be successful, scope management is undertaken in the form of a partnership between Team EDS and CDCR’s management team.

Our scope management process delivers a solid framework as follows:

Maintaining contractual compliance and overseeing orderly revisions to the contract, if necessary, throughout project execution

Tracking contractual commitments and deliverables and monitoring progress toward completing them against contractual requirements and due dates

Identifying potential changes to project requirements, assessing the effect of each change relative to achieving the project’s final outcome within the stated time line, and revising the project plan accordingly.

Scope management ties solution delivery to program objectives to deliver quality in a timely fashion. The scope management process defines project baselines regarding objectives, deliverables, expectations, and the overall effort at the onset of the project. Scope management is necessary to maintain and establish user expectations while also creating the schedule and key deliverables designated to meet project objectives.

Team EDS brings a proven process used on many other successful public sector projects. Our team participates in meetings with the CDCR project team to build a mutual understanding of the scope management process for the project. Project resources receive formal training on the resulting process and adhere to the process throughout the duration of the project. Team EDS works with the SOMS project team to form a cohesive team approach to scope management. Our approach to scope management is illustrated in Figure 6.1-5, Scope Management.



Project Management Plan

Change Control Board Schedule Work

EstimatesResource

RequirementsUpdate

Project Plan

SOMS Project Scope

Management

SOMS Project Charter

SOMS Project Work Plan

Configuration Mgt. Pool Baseline Re-Baseline

Scope Planning

• Prior experience

• Collated requirements/RFP scope of work

• Functional completeness assessment

• Work plan

Scope Definition

• Product design/ blueprint

• Constraints

• Initiation phase input

• Cost/benefit

Scope Verification

• Validation of requirements matrix

• Detailed project planning

SOMS Project Stakeholders Involvement and Approval

Figure 6.1–5, Scope Management

It is critical for the project team to establish a consensus on scope among key stakeholders and to institute a collective scope management process. This process includes:

Identify, control, handle, and trace throughout the project life cycle the clarification to the baseline scope

Formalize the cost / benefit analysis of each requested clarification

Produce and iteratively update the Requirements Traceability Matrix (RTM)

Produce a scope management chapter of the PMP to track, manage, and document project scope clarification.

Scope Planning

During the review and validation process, Team EDS confirms and validates the scope statement with the CDCR. This effort includes updating the draft project schedule with dates for key activities, milestones, and deliverables to address the scope of the project based on the project scope statement. The schedule and plan then be augmented by assigning and controlling distinct work units leading to deliverables. It is updated based on the scope management plan and becomes the Work Breakdown Structure (WBS) and baseline for controlling scope. Any clarifications made to the scope statement are tracked in the project scope statement and results in an update to the WBS.

Scope Verification

As part of our ongoing efforts, Team EDS documents scope clarifications, schedule, work products, technical environment, and cost benefit analysis using



the approved scope control and integrated control processes. This is a standard practice on our engagements. Verification of scope results in clarification requests and recommended corrective actions.

Scope Change Control

Scope change control is critical to maintaining schedule, achieving the desired outcomes on time, deploying on time, and delivering to the expected level of quality. We use the scope control process to keep scope clearly documented and current. Our experience is that scope control is an important element of any project success, and results in clear and unambiguous directions and expectations. Team EDS uses the scope clarification process to verify that CDCR accepts, defers, or rejects each request for scope clarification. In general, our scope control approach addresses the following:

A formal clarification request process

Reports to a decision-making body of key executive sponsors and stakeholders

Approval given to research clarification

Impact and cost / benefit analysis

Checkpoint before approval

Approval process.

We apply components of scope management to develop, document, and manage a complete Requirements Traceability Matrix (RTM); thus providing a solid foundation for the project. Integral to scope management is a process for identifying and managing changes to the RTM, the change control process.

The following are key components of EDS’ Change Control Request (CCR) process:

Change control request form

Change control request tracking tools (such as, spreadsheet or database)

Change control approval process.

The CCR form must be designed to capture three critical pieces of information:

What is the requested change?

What is the impact of the change on the project?

Is it approved, denied, or deferred?

Our change control process is depicted in Figure 6.1-6, Change Control Process, and is described step-by-step in the paragraphs that follow the graphic.



Initiate Initiate Review Assign & Prioritize

Reject

Implement Final ReviewImpact Analysis and Proposed

Workplan

Submitted

RejectedApproved for Impact Analysis

Impact Analysis Complete

Approved – Implement Approved – Defer

Approved – New Project

Completed

Figure 6.1-6, Change Control Process

Initiate – Once the need for a change has been identified, the originator must complete a CCR form. The project team finalizes the form at the beginning of the project. The originator must describe the current issue and document specific details as necessary. The originator may optionally assign an initial priority to the request in order to communicate the urgency of the request. Once an issue has been raised, it should be forwarded to the EDS project manager.

Any member of the project team who perceives a need to change a process or product may submit a change request, including the following:

Project Management

Steering Committee Member

User Group Member

Team Member.

Initial Review – The next step is to determine whether the change warrants further investigation and whether, in fact, it is in the scope of the project. If further investigation deems that the change is not in the scope and is not needed, the CCR is closed with details on potential for a future release. If the change is deemed as required by the project – whether it is in scope or out of scope – the impact of making the change needs to be evaluated.

Assign and Prioritize – If the CCR is deemed to warrant evaluation, the project manager assigns it to a team member for evaluation. The team member and project manager reviews the CCR to determine whether an impact analysis should be carried out. The project manager, with assistance from the project team, determines whether the request is an actual change by comparing it with



the relevant original requirement. The change may also be elevated to the Steering Committee for consideration if it is deemed necessary.

Impact Analysis and Proposed Work Plan – Once the request and an impact analysis have been deemed necessary, the impact analysis is performed. The analysis details the impact and cost of making the change. Examples include:

Impact on the system (such as, programs, database, files, and so on)

Resource allocation impact

Phase or project delivery time frame impact

Impact on other areas of the project

Specific tasks or deliverables requiring rework and time estimates for each.

Final Review – Once the impact of the change has been analyzed, a decision is made on whether to implement the change. The CCR may be:

Approved and implemented into the project

Approved but deferred (or not implemented) in the current project

Rejected

Cancelled.

If the change is rejected or cancelled, the CCR is closed. If the change is approved, it needs to be signed off before any further action may be taken. The EDS project manager, oversight contractor, and CDCR project manager is responsible for approving or rejecting the CCR. A signature from each is required on all CCR documentation, whether rejected or approved. If necessary, the Project Steering Committee gives approval as well.

Implement – If the CCR is approved, the change may be implemented in a number of ways. If the change is to be implemented as part of the existing project, deliverables affected by this change must be updated accordingly. The project plan must be updated (if affected) to include the change itself (including effort required to analyze the change) and any rework of other products or deliverables. Reworked deliverables are reissued, and interested parties are informed that the change has been completed. The team member assigned to the CR makes the change. The project manager updates the project work plan and any other relevant documentation.

Rejected – The CCR may be closed or rejected at any point in the process. Closed CCRs are reviewed in the project status meeting. Any team member may request or recommend closure of a change request.

By using this process, EDS has confirmed that both our staff and our clients have a common understanding of what it is that we are producing, what the criteria are for acceptance of our product, and when and how much we be paid.



Scope Management Responsibilities

Together with CDCR, Team EDS PMO staff confirms Request for Proposal (RFP) requirements, plan turnover of deliverables, and establish agreement about content and level of detail. A clearly defined scope provides the foundation for evaluating the impact of potential scope changes on schedule, budget, and performance requirements. Each project has a defined baseline for the deliverables according to the work plan. Changes to this defined scope require approval through the proposed CCB.

Time Management

Ongoing project management activities include time management and the processes required to facilitate timely completion of the project tasks and deliverables. The processes include activity definition/sequencing, duration estimating, schedule development, and schedule control.

Time Management Responsibilities

The deputy project manager for implementation, senior architect, and eOMIS software development manager, in coordination with CDCR, works with the phase managers and track leads to create the project schedule based on the project’s scope and to identify the deliverables and required resources. Jointly, we evaluate the viability of the schedule, verify that work is accomplished, validate that resources are expended as planned, and update the schedule as the project progresses.

Cost Management

Project cost management is a process that enables Team EDS to control the cost of the project. It involves three key components that the PMO team implements:

Cost Estimating – Developing an approximation of the costs of the resources needed to complete project activities

Cost Budgeting/Baseline – Aggregating the estimated costs of individual activities or work packages to establish a cost baseline

Cost Control - Influencing the factors that create cost variances and controlling changes in the project budget.

Team EDS initially performs the cost estimating activity as part of the proposal process. The RFP requirements evaluated against EDS’ prior experience with similar projects to produce the cost proposal. These costs are reviewed and validated as part of the contract negotiation process to establish the baseline project cost budget.

The cost baseline sets the fixed price for the SOMS project. Any change that affects the total cost baseline is handled through the change control process. In addition, the cost baseline forms the basis for the budget status reporting also described in this section.



Cost control includes monitoring cost performance to detect and understand variances from the cost baseline and recording appropriate changes against the baseline.

Cost Management Responsibilities

Team EDS leaders, working with our financial analyst, establishes the financial infrastructure to support the project’s estimating, forecasting, budgeting, and tracking activities. Effective cost management for the SOMS implementation and subsequent projects encompass the activities required to plan, estimate, budget, and control costs.

Quality Management

Quality management, including configuration management, is described completely in Section 6.8, Quality Management.

The EDS SOMS project team finalizes our quality management plan early in the SOMS project to facilitate common understanding of quality standards, quality metrics, and acceptance procedures. Then, during project execution, we perform planned and systematic testing and quality assurance activities according to the quality management plan.

Our GAD QMS framework, described in Section 6.0, Management Requirements Response, provides a methodology and a library of work products to foster the utmost quality for SOMS implementation. As described in Section 6.8, Quality Management, deploying the quality management plan is the most critical aspect of implementing quality processes throughout our product and service delivery to CDCR.

Configuration management focuses on the rigorous administration of technical aspects of the delivered work products and the five processing environments. Team EDS establishes a configuration management plan in the early stages of projects by defining standards and requirements to be applied and by involving CDCR and Department of Technology Services (DTS) staff as necessary. Activities that support configuration management include:

Identifying the configuration of selected work products that compose the baseline at given points in time

Controlling changes to configuration items

Building or providing specifications to build work products from the configuration management system

Maintaining the integrity of baselines

Providing accurate status and current configuration data to developers, users, and customers.

Our response to management requirements M-70 through M-72, Section 6.6, Implementation, describe specific configuration management procedures and tools employed.



Quality Management Responsibilities

The designated quality manager within the PMO works with CDCR representatives, the software development manager, and the deputy project manager for implementation to define performance requirements and to establish a plan to achieve the requirements. The quality manager analyzes performance against the project’s requirements and evaluates progress at appropriate points to check compliance with the CDCR and Team EDS expectations. Quality is an ongoing commitment engrained in each employee. The quality of our work is demonstrated in our record of success.

Resource Management

Team EDS understands the need for appropriate resource management to facilitate project success. In order to properly manage project resources, Team EDS has identified specific processes to properly and adequately staff the project throughout its life cycle. Resource management includes those processes that the EDS management team, in collaboration with state management, use to make the most effective use of the staff assigned to the project. The key elements of resource management are outlined below:

Organizational Planning – Organizational planning involves defining, documenting, and assigning project roles and responsibilities as well as establishing reporting relationships. For this project, as well as the many other projects EDS has delivered, the majority of the organizational planning is completed early in the project and is reviewed periodically thereafter to confirm continued applicability.

Staff Acquisition – EDS will be staffing the SOMS project with the best resources based on the role requirements. Staffing plans formalized in the planning phase of the project defines what skills are required from various individuals and teams and the time frames when those skills are needed.

Team Performance – EDS recognizes that project success can be achieved only if the team is qualified to perform the activities of the project. EDS conducts frequent performance evaluations of our resources to make sure the team continues to meet the requirements of the project. EDS works with the CDCR management team to perform continuous evaluation of project staff assigned to make sure the project is successfully implemented.

Project team members are assigned to a supervisor for the purposes of administration. The team member reports to this supervisor for time and leave reporting. The supervisor is responsible for completing performance evaluations, which is based on interactions with and observations of the employee, the employee’s performance of assigned tasks, the quality of work performed, contractual requirements, and input from other team members as appropriate.

Section 6.10, Staff Management, describes our approach to acquiring and releasing staff, interaction between Team EDS and CDCR teams, and our approach to governance.



Resource Management Responsibilities

EDS team leaders creates the strategy and determine the procedures for timely, cost-effective acquisition and uses reallocate human resources to provide quality products and service to CDCR projects. Team EDS leaders and designated training staff coach, motivate, direct, and train team members so that they can successfully perform their tasks and activities for the benefit of CDCR.

Communications Management

Project management is successful only if a strong commitment is made to establishing and maintaining an open communication channel between the stakeholders and the EDS’ project team. EDS addresses communication in the SOMS project by implementing a comprehensive communication plan that provides multiple channels of information flow between the State and EDS. A robust communication plan keeps all stakeholders and constituencies duly informed and consulted on matters related to the project. EDS communicates openly and in a timely manner with CDCR to maintain consistency with our strategic partnership and shared approach. Additionally, open channels of communication is established between the project teams and the end users so that the users input is instrumental in crafting the way the modernized system will look and feel, as well as how it functions. The iterative flow of our communication approach is depicted in Figure 6.1-7, Communication Flow.

Figure 6.1-7, Communication Flow

Understanding that effective communication is paramount to the ultimate success of the SOMS project, the EDS communication plan provides transparency into every facet of the project, and make visible to CDCR management the status of each activity and key tasks within them. With project stakeholders located across the State, communications occur through a variety of channels including the Internet, email, and paper-based to keep stakeholders informed. Communication includes regularly scheduled status reports, and meaningful reports on project metrics that clearly indicate the success of the project, as well as less formal communication among the project management team. The key benefits of this approach is that needs are understood and expectations are



being met, and it proactively identifies and mitigates risks and project issues that develop before they impact the project.

Using the draft communication plan as a framework, Team EDS will work with CDCR staff in the early stages of the project to finalize the communication management plan, defining project stakeholders, communication mediums, and approval protocol for transmitting messages.

Communications Management Responsibilities

The CDCR and EDS SOMS project team determine communications protocol, audience, and timing to make sure messages are understood. The SOMS project management team assists in the management of appropriate communications to the right stakeholders, at the right time, with appropriate content. EDS phase managers and track leads, with support from the project managers and the business process or change management manager, monitor communication to verify that the process remains effective.

Status Reporting

Effective communication, written and verbal, formal and informal, is a basic foundation of our project management approach. Keeping project stakeholders fully informed of project status is the best way to achieve consensus and clarity. Working with the CDCR stakeholders during the development of the communication plan, communication needs are identified and a mutually agreed upon approach for meeting the needs are determined. EDS uses formal and informal communications at all organizational levels to foster teamwork and to facilitate success. We employ multiple methods of communication throughout all activities.

As described in response to management requirement number M-5, Team EDS works with CDCR to establish progress and status report formats to provide CDCR real-time visibility into the status of project deliverables. We propose to use a Red-Yellow-Green dashboard approach for issue and risk management and offer exception-based status reporting, but adjust reporting processes and collaterals to meet CDCR’s requirements. Members of Team EDS submits a status report to the CDCR SOMS project manager for review in advance of the SOMS weekly status meeting, thereby allowing for timely and accurate feedback. Team EDS provides CDCR with information monthly for Steering Committee Reports, which includes a detailed status of ongoing and planned activities. Appropriate Team EDS members will attend the weekly and monthly status meetings.

Project Newsletter/Website

A key to project success is the cooperation of user groups and stakeholder communities. Frequent and consistent communication is required in order to inform educate and interest these groups. Team EDS will maintain a project Website and/ or publish periodic newsletters to provide a forum for information and collaboration.



Risk Management

To reduce the risk and complexity of our project engagements, EDS institutes a proactive risk management process that uses a structured framework for the identification, escalation, and resolution of project-related risks. The EDS Continuous Risk Management (CRM) process is adopted from the Software Engineering Institute’s (SEI®’s) Team Risk Management paradigm, and it provides a team-oriented approach to managing project risk. Using this approach, project participants enjoy open communication and are encouraged to expose potential issues that could cause the project to go off track. Additionally, the project team improves their prospects for a successful project by jointly arriving at resolutions affecting the project. EDS employs the principles of CRM to facilitate this process as shown in Figure 6.1-8, Continuous Risk Management Activities.

Continuous Risk I dentification

Risk I tem Evaluation

Risk Mitigation Strategy

Risk Monitor/ Report

• Identify Risk Management Lead

• Identify Risk Management Group

• Institute Process of Continuous Risk Management

• Update Risk Watch List

• Perform Assessment of Potential Threat of Risk

• Categorize and Prioritize Risk and Action I tem

• Identify Risk Mitigation Strategy

• Analyze Project Impact

• Document Risk and Mitigation Plan

• Generate Risk Matrix for Joint Review with ESC Project Management Group

• Generate Feedback to Evaluation Step

Continuous Risk Management Activities

Feedback/Metrics

Figure 6.1-8, Continuous Risk Management Activities

The following CRM principles are integrated into the EDS approach:

Enabling Open Communication. Recognizing that project risks can exist at multiple levels of the project, EDS’ risk management approach provides mechanisms that encourage project staff to participate in and provide feedback on potential issues and risks that may affect the project. We do this by enabling formal, informal, and impromptu communication within the project organization.

Focusing on Outcomes. At EDS, we are cognizant that to be able to adequately manage risk the project leadership must look ahead, identifying uncertainties, anticipating potential issues, and proactively managing project resources and activities in anticipation of these uncertainties.

Providing a Shared Vision. In order for the project team to identify potential risks there must be a mutual vision of the project based on common purpose,



shared ownership, and collective commitment to the project outcomes. To this end, the project manager provides a vision based on the requirements of the project, so that the project resources can identify potential risks to meeting the intended goals.

Maintaining a Global Perspective. To make sure that project risks are identified, it is critical for the project team to understand the vision of the project. Risk identification and management is performed within the context of project goals and the objective leveraging of best practices to mitigate risks to the project from external influences.

Adopting Continuous Process Management. By implementing a process of continuous improvement, EDS is able to maintain constant vigilance while identifying and managing risks routinely throughout phases of the project life cycle.

Figure 6.1-9, Communication-driven Risk Management, depicts how the above principles are interrelated and depend upon open communications.

Forw

ard

-Lookin

g V

iew

OpenCommunication

Continuous Process

I ntegrated Management

Teamwork

Figure 6.1-9, Communication-driven Risk Management

The risk management plan is created as an initial step during the project planning phase, and is continually reviewed and updated by the project manager. Risk status is communicated regularly to the CDCR project management team as part of the project management process. The risk management plan contains a task-based approach that includes the following tasks:

Identify – Recognizes and documents risks



Analyze – Assesses the severity, impact, and likelihood of each risk

Plan – Constructs a risk mitigation plan for serious risks and assigns actions

Track – Evaluates and documents the status of the risk on an ongoing basis

Control – Identifies actions as necessary to control the risk. Probability is updated and determinations are made as to whether contingency plans are invoked.

Communicate – Publishes risks that are then reviewed with team members.

This ongoing process mitigates risks by providing a structure by which project and functional risks are constantly identified and controlled. The risk management plan is used in conjunction with detailed project planning activities and is updated to make sure that risks are identified and mitigated.

Task: Identify Risks

As we initiate each stage of the project, the project manager identifies specific risks associated with that stage. The project team leads reviews these risks and identify additional, more specific risks during the detail work planning process. A continuous process is established to confirm that project risks at each level of the project structure are correlated and integrated. The consequences should be described as tangible or quantifiable impacts.

Risk items change during the course of a project. As the project team identifies new risks as the project progresses, and existing risks are successfully mitigated, it is the project managers’ responsibility to make sure the risk plan is current and the progress on the mitigation activities are on course.

Task: Analyze Risks

The second step of the risk management process is to analyze the information that is gathered during the risk identification step. The purpose of risk analysis is to determine relative project risk exposures in terms of time and cost.

During the analysis step, the project manager performs the following activities:

Quantify the impact of the risk should the risk occur

Estimate the probability that the risk occur

Prioritize the risk based on the project objectives, scope, constraints, and severity of the risk

Determine relative exposure of the project to this risk.

Figure 6.1-10, Approach to Risk Identification and Assessment, depicts the process used to analyze the information gathered during the risk identification step.



Figure 6.1-10, Approach to Risk Identification and Assessment

Once an assessment of risk impact has been performed, the relative exposure of the project should be analyzed. Exposures are generally considered in terms of time (schedule delays) and cost (additional project expense). If possible, concrete values should be assigned to potential impacts to determine the true exposure. The results of the risk impact analysis will be documented in a risk profile.

Risk Classification Techniques

An integral part of a successful risk management, analysis, and mitigation strategy is a sound and consistent means of classifying and prioritizing risks. Risk classification requires that certain risk criteria be negotiated between project management and stakeholder and user groups. These criteria establish the limits that qualify the risk categories. Table 6.1-1, Sample No. 1 – Project Risk and Classification, and Table 6.1-2, Sample No. 2 – Project Risk and Classification, present sample projects. The risks in each table have been assigned a probability of occurrence to help determine the appropriate mitigation strategy.

Table 6.1-1, Sample No. 1 – Project Risk and Classification

Classification Consequence Description – Schedule Slippage

High Schedule Slippage – Slippage in the schedule of a key deliverable or milestone that is greater than or equal to two months.

Cost Overruns – Cost overruns for the change that are equal to or exceed 10% of the agreed upon fixed cost for the named tasks.

Significant Schedule Slippage – Slippage in the schedule of a key deliverable or milestone that is greater that one month but is less than two months.

Cost Overruns – Cost overruns that are greater than 5% of the agreed upon fixed cost for the named tasks but are less than 10%.



Classification Consequence Description – Schedule Slippage

Low Schedule Slippage – Slippage in the schedule of a key deliverable or milestone that is greater than one week but is less than one month.

Cost Overruns – Cost overruns that are greater than 2% of the agreed upon fixed cost for the named tasks but are less than 5%.

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

Table 6.1-2, Sample No. 2 – Project Risk and Classification

Classification Consequence Description – Risk of Occurrence

High (> 70%)

Occurrence of this risk is very likely and may not be controlled by following existing processes or procedure. In such cases, exceptions are made and mitigating actions are expedited through the system.

Significant (40% to 70%)

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

Low (20% to 39%)

Occurrence is unlikely. Mitigating actions are devised and are ready to be implemented if required.

Negligible (< 20%)

Occurrence is very unlikely. It is likely that mitigating actions or replanning will avoid realization of this risk.

Task: Control Risks

To control risk is to mitigate risks. As mentioned above, the key to successfully mitigating the probability of risks from impacting the project is to continually assess the risk landscape and putting in place actions that limits the impact on the outcome of the project. The objective of risk mitigation is to identify cost-effective risk management activities to reduce, contain, and otherwise control project risk. There are two types of corrective risk actions:

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

Contingency – Provides a buffer to address unanticipated events. The project manager develops contingency plans for risk areas where preventive action is either unavailable or the cost of prevention is prohibitive. The project manager must determine that a contingency plan is realistic. The cost required to implement the identified actions should then be estimated.

Task: Communicate Risks

The process of identifying, monitoring, and reporting on the status of risks is a project-wide responsibility. The EDS project manager works with the client project manager to implement mediums for formal, informal, and impromptu



communication within the project organization. Additionally, EDS’ project manager is responsible for presenting the risk matrix and a current risk management plan at status meetings with the State.

Risk Management Responsibilities

Phase managers, the senior architect, and the business process or change management manager will work together with CDCR to identify specific risk items and to systematically assess risk factors. EDS will manage risk by taking action to avoid, transfer, or mitigate the risks. We will work jointly with CDCR to create contingency plans to reduce uncertainties and consequences related to identified risks. Team EDS will monitor risk triggers to verify that plans are invoked if a trigger is activated.

Procurement Management

In general, this involves procurement of the hardware and software necessary to support the execution of the project, as well as each key area of the solution implementation. EDS Technical Services assists the project team by collaboratively defining a procurement plan that includes procurement cost schedules and timelines, which is executed through the infrastructure track.

Procurement Management Responsibilities

Team EDS leaders works to verify that our business partners adhere to legally binding requirements to reduce legal exposure. The deputy project manager for implementation and the SOMS account manager establish commitments with our partners for work to be performed, and coordinates activities, tracks and review their performance and results.

Issue Management

The EDS approach to issue management provides a mechanism for issues to be identified, assessed, documented, resolved, and communicated back to the team using an issue management system. Issues are really problems and to solve problems the issue management process or system must provide the ability to create one or more action items. An action item requires that someone do something by a due date. Usually that someone is a person other than the person who identified the issue. In most cases the person who identifies an issue does so because he or she cannot solve the problem and needs someone with expertise or authority to address and solve the issue. These action items are logged into the system in a common format and assigned to individuals. Using a consistent source and format allows the project manager to focus on what is due or outstanding.

The goals of the issue management process are as follows:

Reach consensus on issues between EDS and CDCR

Limit the effects of unforeseen events on the project



Provide standard documentation of project issues

Ensure that every issue has a resolution path and is logged and tracked

Reduce risks to the project (when an issue becomes a risk, it is moved to the risk management tracking system).

The following are benefits of the issue management process:

Allow issues to be tracked and viewed in one place

Provide easy to see information about issues, because information is stored in a single consistent format

Limit responsibility for each issue and action item to one person, thereby avoiding the "...I thought he was doing it..." situation

Define each issue clearly as well as the action being performed to address an issue

Inform project team members about what is being done to address an issue and provide the status of an issue or associated action item

Allow CDCR to understand how issues are being addressed

Identify issues that are really risks.

Figure 6.1-11, EDS Issue Resolution Process, depicts EDS’ approach to managing issues. This is a simple process that allows the team to handle the majority of project issues as they arise and establishes guidelines for the management, resolution, and escalation of problems and issues.



Figure 6.1-11, EDS Issue Resolution Process

Issue identification and resolution occurs at various levels within the project structure. The issue resolution process allows problems to be resolved as close to the point of origin as possible. Through this approach, the team with the knowledge and skills required for resolving the problem is assigned ownership of the issue and exhausts resolution options prior to the issue being escalated.

The first step of the issue resolution process is to identify whether the proposed issue is, in fact an issue, and if it is, whether it has been previously documented. Once it has been determined by the senior project manager that the issue should be logged, it is recorded into the issue tracking system. EDS uses Service Desk software from Computer Associates (CA-Service Desk) to manage issues. The title and description of the issue, the creation date, who submitted it; the type of request, the owner of the issue, the due date, and other project-related information are all recorded in CA-Service Desk. The issue is managed through its life cycle and stored for historical viewing.



Issue Identification

Members of the team are encouraged to log issues as soon as they arise (often this occurs first in the course of informal discussions). The sooner an issue is logged and addressed the more likely it is resolved without having a major impact on the project. The originator of an issue must record the issue into the issue tracking system. The issue originator records the title and description of the issue, the creation date, who submitted it; the type of issue, the due date, impact to the project, the complexity of the issue, and other project-related information. The person reporting the issue also has to assign an owner for the issue. If the owner of the issue is unknown, the issue owner should be defaulted to the project member reporting the issue.

Any member of the project team who identifies an issue may submit an issue.

Issue originator

Team member

Team leader

Project manager

Project Management Office (PMO).

Prioritization and Issue Assignment

The concept of an issue having an owner is crucial to effective issue management. The owner is someone within the project team who is responsible for ensuring the issue is resolved. Generally ownership should be at the lowest level at which the issue could possibly be resolved. In order to facilitate the issue management process, issues may be assigned an issue owner by any member of the project team. Open issues are also reviewed during the weekly project status meetings and are assigned to a project team member and also assigned a due date. Issues with an unidentified owner can also be recorded and the issue owner should default to the project member recording the issue.

At any point, an issue can be reassigned; action plans and due dates can also be changed. Project staff assigned an issue may determine that the issue should be reassigned. If the issue owner is on a team, he should discuss the ownership of an issue with the team leader. Upon approval of the reassignment, the issue owner may reassign the issue. If the issue owner is a project manager or the PMO, the issue can be reassigned to another staff member. If ownership is still in question; then the issue should be openly discussed at the weekly project status meetings where ownership either remains with the issue owner or be reassigned.

Issue Investigation

The next step is to investigate and resolve the issue. The owner of the issue is responsible for investigating the issue. Issues originating from within the specific functional project teams will be identified and reported to the team leader. This communication occurs between the issue originator and the team leader. If the



Issue is unassigned, the team leader assigns an issue owner based on the type and priority of the issue.

If the issue owner is a member of the project team, issue resolution and escalation is conducted internal to the project. The issue owner is responsible for documenting any information relevant to the resolution of the issue, and for following-up with the issue originator and other interested parties on the team.

The owner of the issue is responsible for investigating the issue.

Issue Escalation and Escalation Path

In the event that a solution cannot be found by the initial owner, the escalation procedures are followed.

If issues go unresolved at a particular level, they are elevated to the next level of the management structure. As the issue is elevated to higher levels of management, the issue priority, due date, and assigned owner are constantly re-evaluated.

Issue Owner – If the issue owner is unable to resolve the issue or requires additional resources or Information, the issue owner escalates the issue to the team leader.

Team Leader – If the team leader is unable to resolve the issue or requires additional resources or information, the team leader escalates the issue to the team leader’s project manager.

Project Manager – If the project manager is unable to resolve the issue, the project manager escalates the issue to be discussed at the status meetings.

Project Executive – Any issues that cannot be resolved at the project manager level are escalated up to the project executive for action. It is the project executive’s responsibility to bring EDS’ resources to focus on developing a strategy to solve the problem underlying the issue.

Issue Resolution

Issue resolution techniques and alternative analysis also play key roles in keeping projects on track. Team leaders and project managers need to manage project issues on a proactive basis. These levels of management use their experience and resources to assist in impact analysis, evaluation of alternatives, and formulation of an appropriate course of action.

During the course of investigation, the issue may be identified as a duplicate. If this occurs, the resolution should document the duplicate issue number. Sometimes an item is not an issue. It is, instead, a risk and should be tracked and acted upon if necessary in the risk management process. In other instances, the resolution requires the contractor to accept work that was previously unanticipated through the change management system.

Issue Owner – The issue owner investigates and resolve the issue by the issue resolution due date. The resolution should be clearly documented in the



recommendation section of the issue in the database. Comments may also be entered at this time.

Team Leader – The team leader assists the issue owner with investigating the issue and monitoring the issue so that it is resolved by the issue due date. The team leader also determines if the issue should be escalated so that the issue is addressed and resolved prior to the issue due date.

Project Manager – The project manager assist the team leader with determining an appropriate course of action and monitoring the issue so that it is resolved by the issue due date. The project manager also determines if the issue should be escalated to the senior project manager who discusses it with the executive manager to determine the necessary resources to bring to bear. This may trigger an action in the change control process. While an issue is pending in the change control process, the project manager is responsible for highlighting any impacts that result from not having the issue resolved.

Project Status Meeting – The weekly project status meeting addresses open issues that have been escalated internally. When the meeting is convened, the issue will be discussed and an attempt will be made to negotiate a solution. If the solution is not evident, the issue will be assigned to an owner to further analyze the problem and to make a recommendation to the group at a later date.

Issue Closure

Issues that require action in the change management process are typically put into a pending status. This means that the issue will be resolved if a pending change to the scope is approved. Until that action is taken, pending issues cannot be considered closed. However, once a change order has been authorized, the issue status can be changed to resolved. The resolved issue is then reviewed by the appropriate level (for example, the weekly review meeting, team leader, project manager) and from there the responsible party confirms that the appropriate resolution has been made and documented.

The following project team members have responsibility for issue closure:

Originator and Assignee (need to agree that the issue can be closed)

Team Leader

Project Manager.

Issue Reporting

The team leaders and project managers will include in their weekly status reports a report of open issues and also any issues resolved within the past week. Open issues will be discussed at the weekly project status meeting. This weekly status meeting serves as a forum where team leaders and project managers can give status, raise and discuss issues, and determine appropriate resolution actions. A list of open and recently resolved issues will be distributed at the status meeting and documented in the weekly status report.



EDS’ Proven Organizational Structure and Delivery Techniques

Our proposed project managers have years of experience in managing large-scale systems integration and implementation projects. In addition, our team has experience in managing implementations of offender management systems in other state corrections departments, as well as in implementing an offender management solution for Her Majesty’s Prison Service in the United Kingdom. In addition to this experience, our project managers will apply tools and techniques that have a proven record of success for delivering state technology modernizations.

One of our most successful methods for managing and delivering complex government technology modernizations is our Tracks-Based Approach, which we introduced in Section 4.2.I, Partnering. The Tracks-Based Approach is a practical delivery approach that enhances our ability to better manage and control complex projects to focus on the most risk-prone components of any project. It is not itself a methodology, but rather complements project management and system development methodologies. Employing the Tracks-Based Approach on the SOMS project will provide the team structure for a combination of PMBOK®-based management, subject matter expertise, and technical proficiency.

At the core of the Tracks-Based Approach is project management. Primarily focusing on the three iterative process areas of Planning, Executing, and Controlling, the Tracks-Based Approach organizes project activities into six parallel tracks, or streams of activities, that support execution and delivery of the solution. While the project manager remains the overall authority to drive the project schedule and correct timing of activities, each of the solution execution tracks is dealt with as if it were an independent project, incorporating project management best practices based on the PMBOK® principles and guidelines. Track leads manage the various activities of each track to timely delivery of the various work products and deliverables produced within the track. Each track manager possesses the interpersonal skills, management skills, understanding of the overall project environment, and most importantly, the expertise and experience in the disciplines or specialty of their assigned track. The track managers are fully empowered to manage the various activities of each track to timely delivery of the various work products and deliverables produced within the track. These tracks receive individual attention regarding communications, staffing, schedule and costs monitoring, quality control, and risk mitigation. This approach greatly minimizes the risk by allowing a higher degree of control over the countless project activities and tasks, and enables better coordination of time and resources between the various project tasks.

Although each track may work independently in their area of expertise, the project administration track manager remains responsible for oversight of the various track activities and coordinates these activities through frequent status meetings with the other track managers. The delegation of authority to perform the necessary project administrative tasks to the project administration track manager frees the project manager from the enormous task of documenting and maintaining the needed project plans, schedules, and status, while still allowing them excellent visibility into the overall health of the project.



We have found that the tracks-based project organization enhances the ability of our project managers to remain focused on the overall goals and progress of the project while maintaining the project’s momentum and building strong client relationships. The constant communication between the track managers, the project administration track manager, and the project manager allows us to better coordinate and roll-up track-specific concerns to identify high-level concerns that may jeopardize the success of the project. In the end, a tracks-based project organization maximizes skills, enhances ownership, and improves the project manager’s focus.

Another technique we have found to complement the Tracks-Based Approach and PMBOK®-based project management, is establishing an on-site Project Management Office (PMO), which houses the Project Administration Track. The PMO executes management disciplines throughout a program’s life cycle to achieve stated business objectives. The PMO makes certain that a governance structure is in place to provide proper oversight, the white space between projects and other programs is managed, and visibility is provided as needed. The PMO also facilitates effective, efficient communication of project and program performance to stakeholders.

An Enterprise Program Office toolkit helps the PMO to implement program management practices faster by providing initial operational processes, procedures, and templates to speed startup and planning. The PMO uses GAD QMS process libraries (introduced in the introduction to Section 6.0, Management Requirements Response) and our Enterprise Program Office toolkit for the SOMs project to foster the following:

Common Structure – EDS methodologies and tools are used to enable a standard approach to implementing a PMO, by establishing a common structure and defining operational standards for program practices. This structure reduces the design and implementation expenses of starting a PMO, freeing the implementation team to concentrate on defining how to implement, not what to implement.

Lessons Learned – Lessons learned by PMOs during previous projects result in the development of processes that are successful in meeting expectations. We share and reuse these lessons.

Program Reporting and Tracking – Our PMO team works with CDCR leaders to clearly define which program management practices to employ.

Governance – Our PMO establishes clear roles, responsibilities, and accountabilities for overseeing organizational constituents, including executive leaders and program managers or enterprise managers.

Knowledge Management – By harnessing knowledge management, we provide a structured way to create, capture, organize, access, use, and assess information and expertise.

Program Management – Our program management processes are used to effectively administer a group of interdependent projects.

In addition to the GAD QMS process libraries of standard work products and templates, our project managers leverage a corporate repository of project



management best practices and lessons learned, and have access to EDS’ State & Local Government Program Office. The mission of the State & Local Government Program Office is to maintain a highly capable staff of project management professionals and SMEs in metrics, analysis, and project and quality management experts to support state and local government clients. CDCR benefit from EDS’ association with the global project management community, groups of project management professionals who meet regularly to share lessons learned, best practices, tools, and techniques. This community of more than 5,000 professionals supports continual development of members, ongoing initiatives and projects, and access to specific interest groups, all of which strengthens project management capability for the SOMS project.

A final technique that has proven to be highly successful is establishing a Change Control Board (CCB). We recommend that CDCR and Team EDS collaborate to establish a CCB that comprises various hierarchies, each with a defined level of responsibility. The CCB will be responsible for verifying that changes to SOMS are allowed only after the CCB has reviewed, estimated, and approved those changes. This approach has proven successful in our implementations in CalWIN, for which we jointly established CCBs at the beginning of the project.

M-3 The Contractor shall develop a Project Management Plan (PMP) conforming to IEEE Std. 1058-1998 Standard for Software Project Management Plans or IEEE Std. 1490-2003, IEEE Guide – Adoption of PMI Standard – A Guide to the Project Management Body of Knowledge. The scope of the PMP shall also incorporate the following component processes:

Project Schedule, Staff Management, Communications Management, Issue Management, Risk Management, Quality Management, Scope Change Management, Requirements Traceability Management, and Configuration Management.

CDCR acknowledges that some portions of the PMP may require a standalone plan.

The Bidder must submit a draft PMP with their proposal response as identified in Section VIII – Proposal and Bid Format.

Vol – 1 Appendices

Appendix A

Appendix B


Team EDS complies with Management requirement number M-3 and has developed a draft project management plan (PMP) that conforms to applicable IEEE standards. An outline of our draft PMP is provided below. A full version of the draft PMP is provided in Appendix A along with our MS Project-based Project Schedule which is included as Appendix B.

Outline of EDS' draft Project Management Plan for the SOMS project:

1.0 Overview

1.1 Project Summary



1.1.1 Purpose, Scope, and Objectives

1.1.2 Assumptions and Constraints

1.1.3 Project Deliverables

1.1.4 Schedule and Budget Summary

1.2 Evolution of the Plan

2.0 References3.0 Definitions4.0 Project Organization

4.1 External Interfaces

4.2 Internal Structure

4.3 Roles and Responsibilities

5.0 Managerial Process Plans

5.1 Project Start-up Plan

5.1.1 Estimation Plan

5.1.2 Staffing Plan

5.1.3 Resource Acquisition Plan

5.1.4 Project Staff Training Plan

5.2 Work Plan

5.2.1 Work Activities

5.2.2 Schedule Allocation

5.2.3 Resource Allocation

5.2.4 Budget Allocation

5.3 Control Plan

5.3.1 Requirements Control Plan

5.3.2 Schedule Control Plan

5.3.3 Budget Control Plan (includes Cost Management)

5.3.4 Quality Control Plan

5.3.5 Reporting Plan (includes Communications Management)

5.3.6 Metrics Collection Plan

5.4 Risk Management Plan

5.5 Project Closeout Plan

6.0 Technical Process Plans

6.1 Process Model

6.2 Methods, Tools, and Techniques

6.3 Infrastructure Plan

6.4 Product Acceptance Plan



7.0 Supporting Process Plans

7.1 Configuration Management Plan

7.2 Verification and Validation Plan

7.3 Documentation Plan

7.4 Quality Assurance Plan

7.5 Reviews and Audits Plan

7.6 Problem Resolution Plan (includes Issue Management)

7.7 Subcontractor Management Plans

7.8 Process Improvement Plan

8.0 Additional Plans

Scope Change Management Plan

Quality Management Plan

M-4 The Contractor must provide project management documents (e.g., Project Management Plan, Project Schedule, Work Breakdown Structure, etc.) using Microsoft software products. The software version must be no less than a version still available on the common market and that is still supported by the manufacturer. CDCR will work with the vendor in approving specific versions to assure that the application is synchronized with CDCR’s plans.

N/A


Team EDS complies with Management requirement number M-4. We provide project management documents, including the project management plan, the project schedule, and the project work breakdown structure, using the following Microsoft software products: Project, Word, Excel, PowerPoint, and Visio. Our team uses the version of these Microsoft products specified by CDCR. The draft project management plan and draft work plan were created using version 2007 of Microsoft Word and Microsoft Project, respectively.



M-5 The Contractor shall advise CDCR and Contractor management of progress in meeting goals and schedules contained in the work plans. This shall be initiated one week after contract effective date and applied weekly thereafter, and shall consist of the following:

Weekly progress meetings attended by the Contractor and CDCR. These may include walkthroughs of selected deliverables as requested by CDCR staff.

Weekly written progress reports, provided by the Contractor to CDCR one working day before each weekly meeting, and containing items to be discussed at the meeting, including:

Progress of each task/activity.

Updated project schedule.

Action items and decisions from the previous meeting.

Problems encountered, proposed resolutions, and projected completion dates for problem resolution

Planned activities for the next two reporting periods.

Status of contractually defined deliverables, milestones, and walkthroughs scheduled in the project schedule.

Other information as needed (per Contractor or CDCR).

Monthly Status Report. This report shall include deliverables, milestones, walkthroughs, CDCR approvals, and lessons learned and shall be used by the Contractor and CDCR in measuring the Contractor’s progress and performance. The report shall also contain:

Issues, problems, and corrective actions, steps, and assignments.

Risks and Mitigations.

Cost Variance reporting

Lessons Learned.

Appendix C


Team EDS complies with Management requirement number M-5, submitting weekly and monthly progress reports as described in RFP Table VI-3, Summary of Project Deliverables. Our team works with CDCR to develop the actual format and delivery protocol for progress and status reports. Appendix C provides sample reports, drawn from the CalWIN project, for a subset of the status reports we provide to CDCR. While the sample reports are not representative of the format we use for SOMS status reports, these samples do reflect EDS’ dedication to communicating project progress to the client.

M-6 The Contractor must provide contract close-out plans and manage project close-out activities in accordance with the plan.

Vol 1 – Appendices

Appendix A,

Section 5.5




Team EDS complies with Management requirement number M-6, and as such we are submitting a contract close-out plan that describes activities and deliverables associated with project closure, including a schedule for disengaging our team, a list of close-out deliverables, system documentation, and post implementation support responsibilities. During the post-implementation support period, Team EDS carries out activities as described in the close-out plan, included in Appendix A, Section 5.5 Project Close Out Plan.

6.1.B General Procurement Requirements

VI.D.4.a General Procurement Requirements

Req.


M-7 The Contractor shall submit to CDCR as part of their proposal, specifications for all necessary hardware, software and tools for the five (5) SOMS system environments.

Appendix D


Team EDS complies with General Procurement Requirements number M-7 and has provided specifications in Appendix D for all necessary hardware, software, and tools for the five SOMS system environments: 1) Development, 2) Test, 3) Pre-Production, 4) Production, and 5) Training

M-7b The Contractor must procure all hardware, software, and automated tools necessary for the development environment to be housed at CDCR EIS, and the four environments to be housed at either DTS COEMS or vendor site.

The Contractor should leverage to the greatest extent possible, the State’s purchasing vehicles, so long as they afford CDCR the lowest cost.

N/A


EDS will procure all hardware, software, and automated tools utilizing the State’s purchasing vehicles such as the California Strategic Sourcing Initiative (CSSI) or EDS’ pricing whichever offers the lowest cost to the CDCR. Regardless of the purchasing vehicle, all components that comprise the SOMS infrastructure adheres to the standard components utilized by the Department of Technology Services (DTS) to facilitate the eventual transition of SOMS management to the State. Upon procurement, EDS installs the equipment that comprises the SOMS environments. The SOMS development environment will be hosted at the CDCR EIS and the other four environments (test, training, pre-production, and production) will be hosted at either DTS COEMS or at an EDS facility in the Sacramento area.



6.1.C Environment Installation and Configuration Requirements

VI.D.4.b Environment Installation and Configuration Requirements

Req.


M-8 The Contractor shall develop a technical infrastructure document which describes all of the hardware, system software and tools necessary for each of the five (5) SOMS system environments.

Section 6.4,

Appendix E


Section 6.4, System Design and Development, describes the technical infrastructure that Team EDS will be employing in the SOMS project. Team EDS complies with Environment Installation and Configuration Requirements number M-8 and with the SOMS RFP, and within 60 days of contract award, we will submit a technical infrastructure description for all hardware, system software, and tools used in each of the following five SOMS system environments: 1) Development, 2) Test, 3) Pre-Production, 4) Production, and 5) Training

Appendix E contains a sample infrastructure and configuration manual drawn from the CalWIN project.

M-9 The Contractor shall develop an environment configuration manual that describes the environment installation and configuration necessary for each of the five (5) SOMS system environments.

Appendix E


Team EDS complies with Environment Installation and Configuration Requirements number M-9 and with the SOMS RFP requirements, and within 60 days of contract award we will submit an environment configuration manual that describes the installation and configuration requirements for the following five SOMS system environments: (1) Development; (2) Test; (3) Pre-Production; (4) Production; and (5) Training. Appendix E contains a sample infrastructure and configuration manual drawn from the CalWIN project.

M-10 The Contractor is responsible for installing and configuring all hardware, software and tools purchased under this Contract until Systems Acceptance for the development and test environments.

Section 6.9




Team EDS complies with Environment Installation and Configuration Requirements number M-10, and as described in proposal Section 6.9, Production Support and Transition, we install, configure, and operate the hardware, software, and tools for the development and test environments.

M-11 The Contractor is responsible for maintaining all hardware, software and tools purchased under this Contract until Systems Acceptance for the development and test environments.

Section 6.9


Team EDS complies with Environment Installation and Configuration Requirements number M-11, and as described in proposal Section 6.9, Production Support and Transition, we manage all hardware, software, and tools for the development and test environments.

M-12 Source Code – The selected Contractor shall furnish the readable source code and object (executable) code and documentation for all software developed by the Contractor, under this contract, ownership of which shall be assigned to the State of California. The selected Contractor shall provide source code and documentation for COTS software licensed for use by the State of California under this contract.

Section 6.9


Team EDS complies with Environment Installation and Configuration Requirements number M-12, and as described in proposal Section 6.9, Production Support and Transition, we provide source code pursuant to the terms and conditions of the SOMS contract and will provide documentation for all SOMS software to CDCR.



THIS PAGE INTENTIONALLY LEFT BLANK


DOC

Business

Transcript of DOC