Stakeholder Readiness Assessment (W) – State Responsibility · Web view2021. 4. 9. · During this task functional specifications from the design phase are broken down into detailed

Supplement 1:

KRONOS Expansion

Scope of Work

RFP 0A1302Page 1 of 64

Table of Contents1. What is OAKS?.........................................................................................................................................................................................41.1. OAKS System Components.............................................................................................................................................................4

1.2. OAKS Governance...........................................................................................................................................................................5

1.3. Major Project Governance................................................................................................................................................................6

2. Background..............................................................................................................................................................................................72.1. Work Hours And Project Conditions...............................................................................................................................................10

3. Project Overview....................................................................................................................................................................................113.1. Overview.........................................................................................................................................................................................11

4. OAKS Project Management Methodology............................................................................................................................................124.1. PMI’s Project Management Processes and OAKS PMO Methodology Phase Mapping.................................................................12

5. Scope of Work........................................................................................................................................................................................145.1. Initiate Phase..................................................................................................................................................................................14

5.1.1. Initiate Phase Key Tasks................................................................................................................................................................15

5.1.1.1. Initiate Phase Deliverables and Work Products..............................................................................................................................18

5.1.1.1.1. Internal Gate Review Results (W) – State Responsibility...............................................................................................................18

5.1.2. Project Plan (D) – Contractor Responsibility...................................................................................................................................18

5.1.2.1.1. Project Kick-Off Deck (D) – Contractor Responsibility....................................................................................................................18

5.1.2.1.2. Initiate Gate Review Results (D) – Contractor Responsibility.........................................................................................................18

5.2. Analysis Phase...............................................................................................................................................................................19

5.2.1. Analyze Phase Key Tasks..............................................................................................................................................................20

5.2.2. Analyze Phase Deliverables and Work Productsf...........................................................................................................................22

5.2.2.1. RICEFW / Retrofit Inventory (D).....................................................................................................................................................22

5.2.2.2. Requirements Traceability Matrix (D).............................................................................................................................................22

5.2.2.3. Conference Room Pilot Results (D)................................................................................................................................................23

5.2.2.4. Environments Approach (D)...........................................................................................................................................................23

5.2.2.5. Organizational Change Management Strategy (D).........................................................................................................................23

5.2.2.6. Risk / Issue Log (W).......................................................................................................................................................................23

5.2.2.7. Analyze Gate Review Results (D)...................................................................................................................................................23

5.3. Design Phase.................................................................................................................................................................................24

5.3.1. Design Phase Key Tasks................................................................................................................................................................24

5.3.2. Design Phase Deliverables and Work Products.............................................................................................................................27

5.3.2.1. Functional Design Specifications (D)..............................................................................................................................................27

5.3.2.2. Configuration Design Specifications (D).........................................................................................................................................27

5.3.2.3. Security Design Specifications (D)..................................................................................................................................................27

5.3.2.4. Batch Processing Specification(D)..................................................................................................................................................27

5.3.2.5. Technical Design Specifications (D)...............................................................................................................................................28

5.3.2.6. Technical Architecture Specifications (D).......................................................................................................................................28

5.3.2.7. Testing Strategy (D)........................................................................................................................................................................28

5.3.2.8. Training Course Curriculum (D)......................................................................................................................................................28

5.3.2.9. Risk / Issue Log (W).......................................................................................................................................................................28

5.3.2.10. Design Gate Review Results (D)....................................................................................................................................................28

5.4. Build Phase....................................................................................................................................................................................29

5.4.1. Build Phase Key Tasks...................................................................................................................................................................30

5.4.2. Build Phase Deliverables and Work Products.................................................................................................................................33

5.4.2.1. Build and Unit Test Results (D).......................................................................................................................................................33

5.4.2.2. Master Test Plan (D).......................................................................................................................................................................34

5.4.2.3. Completed Test Scripts (D)............................................................................................................................................................34

5.4.2.4. Operations and Maintenance Documentation (D)...........................................................................................................................34

5.4.2.5. Training Deployment Plan (D)........................................................................................................................................................34


5.4.2.6. Deployment Strategy (D)................................................................................................................................................................35

5.4.2.7. Risk / Issue Log (W).......................................................................................................................................................................35

5.4.2.8. Build Gate Review Results (D).......................................................................................................................................................35

5.5. Test Phase.....................................................................................................................................................................................36

5.5.1. Test Phase Key Tasks....................................................................................................................................................................37

5.5.2. Test Phase Deliverables and Work Products..................................................................................................................................39

5.5.2.1. System Test Results (D).................................................................................................................................................................39

5.5.2.2. User Acceptance Test (UAT) Results (D).......................................................................................................................................39

5.5.2.3. Performance Test Results (D)........................................................................................................................................................39

5.5.2.4. Operational Readiness Test Results (D)........................................................................................................................................39

5.5.2.5. Training Materials (D).....................................................................................................................................................................40

5.5.2.6. Risk / Issue Log (W).......................................................................................................................................................................40

5.5.2.7. Test Gate Review Results (D)........................................................................................................................................................40

5.6. Deployment Phase.........................................................................................................................................................................41

5.6.1. Deploy Phase Key Tasks................................................................................................................................................................42

5.6.2. Deployment Phase Deliverables and Work Products......................................................................................................................43

5.6.2.1. Stabilization Plan (D)......................................................................................................................................................................44

5.6.2.2. Go / No-Go Meeting (D)..................................................................................................................................................................44

5.6.2.3. Knowledge Transfer Plan Signoff (W).............................................................................................................................................44

5.6.2.4. Risk / Issue Log (W).......................................................................................................................................................................44

5.7. Closure Phase................................................................................................................................................................................45

5.7.1. Closure Phase Key Tasks..............................................................................................................................................................46

5.7.2. Closure Phase Deliverables and Work Products............................................................................................................................49

5.7.2.1. Updated Training Materials (D).......................................................................................................................................................49

5.7.2.2. Project Acceptance (D)...................................................................................................................................................................49

5.7.2.3. Risk / Issue Log (W).......................................................................................................................................................................49

5.7.2.4. Lessons Learned (W).....................................................................................................................................................................49

6. Project Team Requirements..................................................................................................................................................................506.1. State Key Project Team Roles and Responsibilities.......................................................................................................................50

6.2. Contractor Key Project Team Roles and Responsibilities...............................................................................................................51

6.3. Offeror Response - Project Staffing and Time Requirement...........................................................................................................54

7. Deliverables............................................................................................................................................................................................55


1. What is OAKS?

The Ohio Administrative Knowledge System (OAKS) team is an organization in the Office of Information Technology (OIT), within the Ohio Department of Administrative Services (DAS). DAS is committed to providing quality centralized services, specialized support and innovative solutions to state agencies, boards and commissions as well as local governments and state universities.

OIT delivers statewide information technology and telecommunication services to state government agencies, boards and commissions as well as policy and standards development, lifecycle investment planning, and security management.

DAS has more than 40 program areas serving Ohio government customers, who in turn directly serve the interests of Ohio citizens. DAS procures goods and services, delivers information technology and mail, recruits and trains personnel, promotes equal access to the state workforce, leases and manages office space, processes payroll, prints publications, and performs a variety of other services.

1.1.OAKS System Components

The OAKS application is the State’s Enterprise Resource Planning (ERP) system which is responsible for management and support of its Managed Service Provider (IBM) and of all the applications listed below:

Customer Relationship Management (CRM) : Management and tracking of OAKS IT Service Management (ITSM) incidents and service requests.

Enterprise Business Intelligence (BI) : Provides key financial and human resources data utilizing Cognos-driven reporting, targeted business intelligence, and Tableau analytics.

Ohio Learn : Provides management of training content utilized by Internal Learners (state employees and Contractors) and External Learners (citizens). Management includes development of training curriculums, training content delivery, and training status reporting.

Financial Management (FIN) : Oversees accounts payable, accounts receivable, asset management, billing, financial reporting, general ledger, planning and budgeting, procurement, and travel & expense.

Human Capital Management (HCM) : Oversees benefits administration, eBenefits, ePerformance, KRONOS, payroll, position management, time and labor, and workforce administration.

Recruit / Onboard System : Oversees the process of identifying candidates for positions, managing those candidates through the recruiting cycle and then onboarding selected candidates through the hiring process.


Figure 1 - OAKS Trajectory

1.2.OAKS Governance

Project governance is the management framework that will drive the manner in which project decisions are made. The role of project governance is to help support and guide the project team as issues and decisions are identified during the project. The graphic below depicts the type of decision-making authority held by each governing body.

Figure 2 - OAKS Governance


1.3.Major Project Governance

On June 1, 2018, the Department of Administrative Service and Office of Budget and Management released a Major IT Project Oversight policy (DAS Policy IT-16). The policy applies to projects that meet the following criteria. Total expenditures over the project lifecycle are estimated at over $5 million. Total expenditures over the project lifecycle are estimated at over $2.5 million and the project is

categorized as "high-risk". A high-risk project may include:o A major technology project or business project/business transformation involving significant technology

investment.o The project is determined to be high risk (new or emerging technology, sensitive subject area) or high

impact (affecting many constituents or stakeholders, creating profound change).o The project has an enterprise or statewide impact; involves more than one state agency, board or

commission; or is initiated by a state agency and will involve other non-state governmental entities/organizations.

o The project develops, adds functionality, or re-engineers a mission critical business process and/or application.

The project is otherwise designated as a major project or a high risk or high impact project by the Office of the Governor, or the Director of the Ohio Department of Administrative Services (DAS), or the Director of the Ohio Office of Budget and Management (OBM).

Since OAKS provides enterprise services for the State, most projects will fall under the Major Project Governance Policy. The process defined within the OAKS PMO Methodology do align with the Major Project Governance processes.


2. Background

The State of Ohio is a large, complex government entity comprised of over 50,000 employees from 91 separate agencies, including 8 independently elected offices. Included in the workforce are bargaining unit employees represented by 11 separate unions which have various timekeeping rules collectively bargained into those contracts.

Every agency performs its own essential Human Capital duties, and may have unique time reporting rules, but the Department of Administrative Services (DAS) Human Resources Division (HRD) acts as the shared services office that validates these transactions. HRD also processes Timekeeping and Payroll for all employees who are paid by warrant of the Director of the Office of Budget Management (OBM).

The State of Ohio has migrated twenty-seven (27) agencies onto enterprise instance of KRONOS Workforce Central 8.1.6 over the course of four (4) projects with the end goal of all employees being onboarded to the enterprise solution in the future. Those four (4) projects included the configuration to set up KRONOS Workforce Central rules, leave cases, and any required conversions from agency legacy platforms to the enterprise KRONOS platform.

Those twenty-seven (27) agencies account for approximately twenty-seven thousand (27,000) employees which translates to over fifty-four (54) percent of all State of Ohio employees. In addition to Workforce Central, there is one (1) agency, the Department of Medicaid, which is currently using the KRONOS Activities module on the enterprise platform.

The State agencies that need to be migrated can be categorized as either:

OAKS PeopleSoft HCM employee self-service; Time Collection Device (TCD) Agency (which may include use of a homegrown timekeeping system); or Manual/Direct Entry users (agencies enter time directly on the timesheet).

Agencies today who manually track employee time do so with spreadsheets, which are then directly entered into the PeopleSoft Time & Labor timesheets. TCD agencies interface their time which is then loaded directly onto the employee pay sheets in the State’s PeopleSoft HCM.

The Department of Administrative Services (DAS) Human Resources Division (HRD) provides services and information to State employees and assists State agencies in conducting their human resource, talent management, and learning and development functions. Services are offered in the areas of policy development, payroll administration, classification and compensation, drug testing, central recruiting, training and development, workforce planning and records maintenance. HRD is the business owner for the State’s payroll and timekeeping functions.

The DAS Office of Information Technology (OIT) delivers statewide information technology and telecommunication services to state government agencies, boards and commissions, as well as policy and standards development, lifecycle investment planning and privacy and security management.

The Ohio Administrative Knowledge System (OAKS) is an enterprise resource planning software system integrating central government business functions, including human resources, procurement, budgeting, accounting and asset management.


Overview of Project Scope. The tables below provides information on the agencies the State will bring into the State’s KRONOS Activities enterprise with the services procured via this RFP:

Agency Total Employee

Count

Employees Onboarding for

Project

Enterprise Workforce

Activities Advanced Scheduler

Dept of Aging (AGE) 95 95 into Activities Currently Onboard

Project Onboard

NA

Dept of Administrative Services (DAS)

817 64 into Activities Currently Onboard

Project Onboard

NA

Dept of Mental Health and Addiction Services (DMH)

3,129 50 into Activities Currently Onboard

Project Onboard

NA

Dept of Natural Resources (DNR) 2,091 700 into Activities

Currently Onboard

Project Onboard

NA

Dept of Developmental Disabilities (DODD)

2,400 1,650 into Advanced Scheduler

Currently Onboard

NA Project Onboard

Dept of Public Safety (DPS) 3,800 3,800 into Enterprise Workforce

Project Onboard

NA NA

Dept of Jobs and Family Services (JFS)

2,362 2,362 into Enterprise

Workforce and 2,020 into Activities

Project Onboard

Project Onboard

NA

Library Board (LIB) 50 50 into Enterprise Workforce

Project Onboard

NA NA

Ohio Tuition Trust Authority (TTA) 30 30 into Enterprise Workforce

Project Onboard

NA NA

Bureau of Workers Compensation (BWC)

1,655 1,655 into Enterprise Workforce

Project Onboard

NA NA

Department of Insurance 248 248 into Enterprise Workforce

Project Onboard

NA NA

This represents 2,929 state employees that would be onboarded into KRONOS Activities, 8,145 employees that would be onboarded into the core Enterprise Workforce module and 1,650 employees to be onboarded into Advanced Scheduler. The project to onboard employees into Enterprise Workforce and Activities is expected to


last between six (6) to twelve (12) months; however, the Contractor is responsible for detailing the timeline and associated tasks needed to fulfill the project requirements.

During project planning, the Contractor will capture standard KRONOS configuration requirements in order to prepare KRONOS for agency use. Additionally, any functional requirements submitted by agencies that are above and beyond current KRONOS services must be captured for review by the Human Capital Management (HCM) Service Owner for future implementation.

The Contractor’s project team will then lead the State OAKS and Human Resource Division (HRD) KRONOS teams to promote these new timekeeping solutions to the broad population.

Technical. The State is currently using PeopleSoft HCM 9.1. However, that State intends to have upgraded to HCM 9.2 with image #33 before the KRONOS Expansion project begins – targeting Feb 2021. The PeopleTools version is 8.58. The State has 27 agencies that are currently using KRONOS Workforce Central 8.1.6. Below is a listing of all the KRONOS modules that the State owns and pays support on:

Workforce Mobile Employee Workforce Mobile Manager Workforce Tablet Workforce Timekeeper Workforce Employee Workforce Manager Workforce Activities Workforce Scheduler Workforce Absence Manager Workforce Enterprise Archive Workforce Integration Manager Knowledge Pass Subscription


2.1.Work Hours and Project Conditions

The State is currently working remotely as part of the response to the ongoing pandemic. As a result, Contractors will also be working remotely until such time that the State has relaxed its pandemic rules assuming that the Contractor has the capability to utilize Microsoft Teams, SharePoint and other tools to allow teams to perform the duties necessitated by the Contract.

Additionally, the State understands that Contractors have their own set of rules regarding travel as part of the pandemic response. The Contractor must make the State aware of any internal policies which would limit their ability to perform the duties necessitated by the Contract.

When, and if, the State returns to onsite work; the State will provide primary Contractor workspace at 30 W Spring Street, Columbus, Ohio 43215. A secondary project location will be provided at a DAS-HRD’s location at Rhodes Tower, 30 E Broad St. in downtown Columbus. The secondary location is within walking distance of the primary location. Any work requiring assistance from State staff or completion by State staff will be performed at a State location. The Contractor is expected to have their resources onsite from 10:00 a.m. on Monday through 3:00 p.m. on Thursday, if traveling. If local, resources will need to be onsite Monday through Friday from 8:00 a.m. to 5:00 p.m. Exceptions to this rule must be approved by the State and identified on the resource plan. The offeror will indicate, as part of its response, any dependencies on the State by way of work location, hours outside those indicated or any other specialized project delivery work, location or conditions requirements.

The State will provide Internet connectivity and administrative printer access when onsite at a State location. Any office supplies, high volume publications or non-routine printing are the responsibility of the Contractor and must be included in the quoted cost. The Contractor will be required to provide computer and phone service for their staff which will adhere to State security provisions in this RFP.

The Contractor must utilize the State’s hosted document management and team collaboration tool (SharePoint). Access will be provided via internal State networks and secure external connections to all Contractor team members.


3. Project Overview

3.1.Overview

The Contractor’s Scope for the Project includes: Project Management, Organizational Change Management (OCM), KRONOS Configuration, Testing and Training. Note: State of Ohio will be responsible for reviewing and approving KRONOS configuration and testing execution.

The Contractor must review and update where applicable current system configuration, agency readiness, any current documentation and other change management materials already developed and used during the initial implementations of KRONOS Activities and Workforce Central. A listing of some of these existing materials is provided below:

1. Workforce Timekeeper Employee Workspace Guide2. Workforce Timekeeper Task Guide3. Agency Administrator Guide4. KRONOS Workforce and Activities Configuration documentation5. KRONOS Onboarding Plan6. Project Management Templates7. KRONOS Guidebook

The Contractor will be responsible for defining the project timeline and associated activities needed to onboard the agencies into the State’s existing KRONOS application. This RFP describes the State’s view of the minimum set of activities, deliverables and milestones required to deliver the KRONOS solution to additional State agencies. The Contractor must include any additional considerations that would increase the overall probability of success and result in a high quality of delivery.

The State Project Manager will provide oversight for the Project, but the Contractor is responsible for work plan creation and management of day to day activities of the project. This includes business analysis tasks for the work under this Contract and the day-to-day management of its staff. The Contractor also must assist the State with coordinating assignments for State staff involved in the Project. Additionally, the Contractor must provide all administrative support for its staff and activities.

The Contractor must adhere to the following meeting and reporting requirements: Immediate Reporting - The Contractor must immediately report any staffing changes for the project to the

State Project Manager as described in the Replacement Personnel section of the RFP. Facilitate Weekly Status Meetings - The Project Manager and other Contractor team members as

required must attend and facilitate status meetings with the Project Representative and other people deemed necessary to discuss project issues. The Project Representative will schedule these meetings, which will follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.

Prepare Weekly Status Reports - During the Project, the Contractor must submit a written weekly status report to the State Project Manager on a mutually agreed upon day. Any changes to the contract require an amendment. At a minimum, weekly status reports must contain the following:

o A description of the overall completion status of the Project in terms of the approved Project Plan (schedule and cost)

o Updated Project scheduleo The plans for activities scheduled for the next weeko The status of any Deliverableso Achievements for the current reporting periodo Time ahead or behind schedule for applicable taskso Risks/issueso A risk analysis of actual and perceived problemso Strategic changes to the Project Plan


4. OAKS Project Management Methodology

The purpose of the OAKS PMO Methodology is to provide a standard approach for planning, executing and deploying OAKS Information Technology projects. The main goal is to provide a repeatable process with project-specific methods, best practices, guidelines, and templates that promote the delivery of quality solutions and result in projects that are completed on time and within budget.

The OAKS PMO Methodology outlines the major guidelines that can lead to a successful project implementation. It is important to note that the information contained within this document is a guideline and that the project manager is responsible for determining what is appropriate for any given project.

The OAKS PMO Methodology is designed to be prescriptive (answering the who, when, how and why, in addition to the what) and describes in detail the process that the OAKS Project Management Office (PMO) and the OAKS Community intends to use during the Initiate, Analyze, Design, Build, Test, Deploy and Closure phases of projects.

By utilizing this methodology, the OAKS PMO expects to reach the following benefits:

Ensure common understanding of the project scope and what is expected among everyone engaged in the project: Contractors, project team members, stakeholders and sponsors

Mitigate project cost overruns and delay, or loss of benefits due to rework as a result of ill-defined, misinterpreted, misleading, conflicting or mistaken requirements/expectations

Establish a solid foundation for replication of appropriate project management processes that over time promote project management maturity

Improve communication, measurement and reporting efficiency within the organization Promote a culture of best practices, which lays the foundation for skill growth Define the roles of the Sponsor, Project Manager, Stakeholders, and other OAKS Community team

members and obtain consensus within the organization about their importance.

Note: The State understands that many organizations have their own project management methodologies. Ultimately it is the Contractor’s responsibility to execute to the project. Therefore, the contract mutually agreed upon between the State and the Contractor supersedes the State’s OAKS PMO Methodology. The closer the Contractor adheres to the OAKS PMO Methodology, the greater the likelihood of project success.

Note: throughout this document, the term Contractor refers to the organization and individuals that have been awarded the contract and are responsible for executing the work.

4.1.PMI’s Project Management Processes and OAKS PMO Methodology Phase Mapping

According to the Project Management Institute (PMI), project management processes ensure the effective flow of the project throughout its existence. The Project management processes are grouped into five groups:

Initiating Process Group Planning Process Group Executing Process Group Monitoring and Controlling Process Group Closing Process Group

The OAKS PMO Methodology has elected to leverage the principles of the PMI methodology as the foundation of its project management methodology. By leveraging PMI’s principles, the OAKS PMO Methodology will maintain a close alignment with the Project Management Institute and ensure that project management principles are incorporated into its OAKS project phases such as Initiate, Analyze, Design, Build, Test, Deploy and Closure.

The following diagram depicts the OAKS PMO Methodology and how it fits in the overall project life cycle methodology:


Figure 2 - OAKS PMO Methodology Relationship to PMI Processes


5. Scope of Work

This section details the work the selected Contractor is required to perform on the KRONOS Expansion project. This section will leverage the Phases and Tasks from the OAKS PMO Methodology identified in Section 4 and identify the tasks the Contractor is expected to perform and those tasks the State is expected to perform.

Each phase identifies the expected tasks to be executed from the OAKS PMO Methodology. Since the OAKS PMO Methodology is intended to cover many different types of projects, all tasks identified in the OAKS PMO Methodology may not apply to the KRONOS Expansion project. The Mandatory Task column will identify those tasks the Contractor is expected to execute

Similarly, where the State has indicated that a task is not Mandatory, the Contractor must specify if they will produce the artifact. All deliverables the Contractor will produce must be identified in their Cost Workbook. Also, if the Contractor is planning on multiple releases to accomplish the work there will likely be some deliverables that must be produced in all of the releases. When a deliverable occurs in multiple releases they must be labeled as A, B, C etc. to clarify the release associated with the deliverable. For example, in this scenario the Contractor plans a Release A to cover the Workforce Central and Activities requirements and a Release B specifically to address Advanced Scheduler. For this example, the Configuration Design for Release A would be labeled Configuration Design – A for the Workforce Central and Activities Release and Configuration Design – B for the Advanced Scheduler configuration. Again, this is only an example.

The State requires that all key tasks and deliverables that will be executed as part of the Kronos Expansion project be docuemented into the Project Plan. The Contract must determine the length of the tasks, the associated dependencies, and the number of releases to accomplish the project requirements. The State will evaluate and score the Project Plan based on comparing the State’s requirements and deliverables against what Contractors provide in their Project Plan and based on how well the Contractor can accomplish the work based on the time they allot in the Project Plan.

The State requires that Contractor document their approach to fulfilling the project requirements in detail. This description of the work will be scored as the Project Implementation Statement of Work. The scoring of this section will be based on how well the description of the activities the Contractor will execute to complete the project aligns with the State’s requirements and ties back to the Contractor Project Plan. The Contractor may choose to deviate from the State’s requirements but deviating from the State’s requirements may have an adverse effect on their Project Implementation Statement of Work score.

Organizational Change Management (OCM) is vital in preparing people for change and helping them adopt the ways they need to perform their work in the future State. The State has defined its specific processes and deliverables associated with OCM across the phases listed below. The State will evaluate and score the Organizational Change Management response based on comparing the State’s OCM requirements and deliverables against what Contractors provide in their response. The Contractor may choose to deviate from the State’s requirements but deviating from the State’s requirements may have an adverse effect on their OCM score.

Additionally, this section outlines the Work Products (W) and Deliverables (D) that the Contractor must provide to the State, unless otherwise noted. Work Products should be viewed as materials needed to create the Deliverable.

5.1. Initiate Phase

The purpose of the Initiate Phase is to initiate project activities, validate the project scope and establish the appropriate project management and quality management plans required to execute the project. At this point it is assumed and expected that the pre-initiation phase is completed, the Project Charter has been approved and signed, and the project manager has been assigned. In this phase, the project plan is completed along with


project staffing plan. The activities and tasks contained within the WBS and project plan must be relatively constant throughout each OAKS project.

Since this phase sets the foundation for the project the project manager must provide the following: A realistic and achievable project plan A staffing plan accounting for realistic time commitment expectations Clearly defined roles and responsibilities for the project team and stakeholders Concise and accurate statements of the project and deliverable objectives Comprehensive accounting of planned project expenditures A clear understanding of project team seating and resource needs (computers, security access, software,

etc.) A plan for boarding large number of team members at the beginning of the project

The Initiate Phase is broken down into three key activities: Ensure Alignment with the Business Organize the Project Engage the Project Team

Figure 3 - Key Activities of Initiate Phase

5.1.1. Initiate Phase Key Tasks

The Initiate phase key tasks and task responsibilities are identified in the table below.

Initiate Phase

Activities Task Purpose Mandatory Task

Contractor State

Ensure Alignment with the Business(Internal State Responsibilities)

Conduct an Internal Initiate Gate Review

Ensure the State is internally in agreement on the project scope and solution and is fully staffed and ready for the project to start.

Yes NA Perform

Develop Project Governance Plan

Describes how risks, issues, decisions and problems are to be escalated and handled.

Yes NA Perform


Initiate Phase


Contractor State

Validate High Level Requirements

Use the Business Case and Project Charter to validate the high-level requirements of the project.

Yes NA Perform

Validate Project Benefits

Use the Business Case and Project Charter to validate the project's benefits.

Yes NA Perform

Validate Stakeholders

Use the Business Case and Project Charter to validate stakeholders for the project.

Yes NA Perform

Create Stakeholder Readiness Assessment

To document the level of impact, support, and influence that each stakeholder group may have over the change initiative.

Yes NA Perform

Assign Reviewers and Approvers to all Work Products and Deliverables

Identifies all work products and deliverables and assigns the proper reviewers and approvers.

Yes NA Perform

Organize the Project

Identify and Confirm Project Resources

State and Contractor project resources confirmed.

Yes Perform Perform

Define Project Organization Structure

Depicts graphically the project team members and their interrelationships.

Yes Perform Support

Onboard Project Resources

Documents the personnel's information - vendors must fill out appropriate paperwork to have access to OAKS data environments, etc.

Yes Perform Support

Define Roles and Responsibilities

Describes the responsibilities for each project team member.

Yes Perform Support

Create RACI Chart

A responsibility assignment matrix that describes the participation by various roles in completing tasks and deliverables for a project

No Perform Support

Develop Project Staffing Plan

Defines the required human resources needed to implement the solution.

Yes Perform Support


Initiate Phase


Contractor State

Socialize SharePoint Site

A repository of information maintained on a project.

Yes Support Perform

Engage the Project Team

Plan Project Kick-off Meeting

Planning for the project kick-off meeting which includes finalizing the project deck, meeting facilitators / speakers, and all tasks to prepare for the meeting.

Yes Perform Support

Develop Project Kick-Off Deck

Documents the governance for the project, roles, approach, timeline and deliverable in a presentation format.

Yes Perform Support

Execute Project Kick-Off Meeting

Execution of the project kick-off meeting for project sponsors and team members.

Yes Perform Support

Update Work Breakdown Structure

A hierarchical decomposition of the proposed solution into phases, deliverables and work products.

Yes Perform Support

Create Project Plan

Documents the major tasks, resources, deliverables, timeframes, milestones, constraint dates and dependencies to complete the project.

Yes Perform Support

Create Project Status Report

Provides a clear and concise picture of the status of the project.

Yes Perform Support

Conduct an Initiate Gate Review

Documents the completion of phase, decision to progress to the next phase and lessons learned.

Yes Perform Support


5.1.1.1. Initiate Phase Deliverables and Work Products

5.1.1.1.1. Internal Gate Review Results (W) – State Responsibility

Stakeholder Readiness Assessment (W) – State Responsibility Project Governance Plan (W) – State Responsibility Deliverables Tracker (W) – State Responsibility

5.1.2. Project Plan (D) – Contractor Responsibility

Work Breakdown Structure (W) Project Organization Chart (W) Roles and Responsibilities (W) RACI Chart (W) Project Staffing Plan (W) Project Status Report Template (W)

5.1.2.1.1. Project Kick-Off Deck (D) – Contractor Responsibility

5.1.2.1.2. Initiate Gate Review Results (D) – Contractor Responsibility


5.2.Analysis Phase

The purpose of the Analyze Phase is to transform the stakeholder needs and high-level requirements specified in earlier phases into unambiguous sets of requirements that are measurable, testable, and traceable. The Analyze Phase is critical to the success of the project. Therefore, all documented requirements are to be reviewed by the sponsor and the project team to provide them with a clear understanding on what the system must do. At the end of this phase the project team must be able to determine all the business processes and system enhancements, if required, that will be required to meet the end user’s needs and have enough requirements to design the solution.

Additionally, this phase documents key elements of the change management approach that will be implemented regarding communications, training, and agency readiness activities.

The Analyze Phase is broken down into three key activities: Finalize Requirements Develop Change Management Plans Manage Project Work

Figure 4 - Key Activities of the Analyze Phase


5.2.1. Analyze Phase Key Tasks

The Analyze phase key tasks and task responsibilities are identified in the table below.

Analyze Phase

Activities Tasks Purpose Mandatory Task

Contractor Responsibility

State Responsibility

Finalize Requirements

Validate Functional Requirements

During this task the functional and technical teams will validate, and if necessary, expand upon the requirements provided in the contract. Validating the requirements may involve only the internal functional and technical teams or can be expanded to include external entities, such as agency end users.

Yes Perform Support

Identify Technical Requirements

During this task the functional team will identify any technology requirements that will support the business processes. It also lists the following type of requirements: • Interface Requirements• Conversion Requirements• Single Sign On (SSO) Requirements.

Yes Perform Support

Conduct Conference Room Pilot (CRP) Sessions

This task is conducted to illustrate the new features of the proposed solution to super users and confirm the fit/gap between the existing and new solution.

Must be conducted for the new modules: Activities and Advanced Scheduler.

Yes Perform Support

Create CRP Gap Analysis

Documents the results of the CRP sessions in a spreadsheet format for each business process and functional requirement.

Yes Perform Support

Create RICEFW / Retrofit Inventories

Identifies the required RICEFW objects and configuration changes for the software components.

Note: this is not required because the assumption is that no changes to existing interfaces are needed, no

No Perform Support


Analyze Phase




data conversion is needed, and that configuration changes, and not code, is all that is required to fulfill the requirements. However, if conversion and/or code changes are required, the Contractor will be responsible to make those changes.

Create Conference Room Pilot (CRP) Results

Documents the results of the CRP sessions.

Yes Perform Support

Define Environments Approach

Documents the technical environments that will be used and describes how they relate to the existing production environments.

No Perform Support

Create Requirements Traceability Matrix (RTM)

Lists the requirements for the processes which will be designed and/or built and subsequently deployed.

Yes Perform Support

Initiate Procurement of Development, Test, Training and Other Production Environments

Initiate and communicate procurement activities required for acquisition of hardware, software, software licenses and other infrastructure required to create the development, test, training and production environment. The project manager is responsible for the procurement of the various technical environments.

No Perform Support

Develop Change Management Plans

Develop Organizational Change Management Strategy

Defines the various change management activities that will be addressed throughout the project (overall OCM approach - needs to be supported by the activities/tasks in the project plan).

Yes Perform Support

Develop Communication Plan

Outlines the approach the project team is going to undertake to manage the project communication activities.

Yes Perform Support


Analyze Phase




Develop Communication Strategy Matrix

Documents the communication types, audiences, frequencies, timelines and vehicles to be used to communicate project activities.

Yes Perform Support

Develop Training Strategy and Plan

To outline the objectives, strategy, and curriculum that needs to be developed and deployed.

Yes Perform Support

Develop Training Needs Analysis

Identifies the training needs that the target audiences affected by the project require.

Yes Perform Support

Develop Readiness Plan

Outlines the approach that will be taken to track end user adoption and readiness for the proposed solution.

Yes Perform Support

Manage Project Work

Maintain Project Plan

The project manager will validate and update the project plan at this phase, as well as document risk/issues as they occur. Overall, the project manager will be responsible and will hold the project team accountable for their assigned work.

Yes Perform Support

Report and Manage Project Risks / Issues

A repository of all project risks/issues on SharePoint.

Yes Perform Support

Conduct an Analyze Gate Review / Capture Lessons Learned


Yes Perform Support

5.2.2. Analyze Phase Deliverables and Work Products

5.2.2.1. RICEFW / Retrofit Inventory (D)

The Report, Interface, Conversion, Enhancement, Form, Workflow (RICEFW) / Retrofit Inventories identify the required RICEFW objects and configuration changes for the software components of the project. This inventory must include all changes necessary to OAKS as well as any software being implemented to integrate with OAKS in order to create a holistic view of the work at hand. The functional lead is responsible for this deliverable.


Note: this is not required because the assumption is that no changes to existing interfaces are needed and that configuration changes, and not code, is all that is required to fulfill the requirements. However, if code changes are required, the Contractor will be responsible to make those changes.

5.2.2.2. Requirements Traceability Matrix (D)

The RTM is a “living” document that lists the requirements identified by the system users and validated by the functional team. This document must be in the State’s format, utilizing the RTM Template. It lists the requirements for the processes, which will be designed and/or built, and subsequently tested and deployed. This document must be continually updated throughout the project for traceability of the business need being conceived in requirements, configured into design documents, implemented into a system, tested through scripts, and ultimately deployed as a new component. The functional lead is responsible for this deliverable. The RTM must also be updated with the results from CRPs.

5.2.2.3. Conference Room Pilot Results (D)

Requirements Analysis Document (RADS) (W)

5.2.2.4. Environments Approach (D)

5.2.2.5. Organizational Change Management Strategy (D)

Communication Plan (W) Communication Strategy Matrix (W) Training Needs Analysis (W) Training Strategy and Plan (W) Readiness Plan (W)

5.2.2.6. Risk / Issue Log (W)

5.2.2.7. Analyze Gate Review Results (D)


5.3.Design Phase

The purpose of the Design Phase is to transform the functional requirements into complete and detailed system design specifications. At this point in the project lifecycle all functional requirements must be documented, containing a complete description of the operational needs of the various organizational entities that will use the new system. The task is to translate all this information into technical specifications that accurately describe the design of the system and meet expectations of the business sponsors and stakeholders.

In addition to the technical design aspects that occur in this phase, this phase is also where the OCM team prepares for training development and executes the readiness plan activities. Note: Training courses must be developed in the Adobe Captivate tool. Contractors are responsible for providing Captivate licenses for their training development staff.

Successful completion of the Design Phase must comprise: Transformation of all requirements into detailed specifications covering all aspects of the system Assessment and planning for security risks Approval to progress to the Build Phase

5.3.1. Design Phase Key Tasks

The Design phase key tasks and task responsibilities are identified in the table below.

Design Phase Activities Tasks Purpose Mandator

y TaskContractor State

Design Solution

Create Functional Design Specifications

Documents the functional design for RICEFW requirements and details the functional approach that will be followed to meet the identified requirements.

Note: this is not required because the assumption is that no changes to existing interfaces are needed, data conversion is not

No Perform Support




needed, and that configuration changes, and not code, is all that is required to fulfill the requirements. However, if code changes are required, the Contractor will be responsible to make those changes and create the associated Design Specifications.

Create Configuration Design Specifications

Details the functional approach that will be followed to meet the identified configuration requirements.

Yes Perform Support

Create Security Design Specifications

Documents the security design for RICEFW requirements and outlines the plan for updating and implementing system security.

Yes Perform Support

Create Batch Processing Design

Identifies the existing batch flows and includes the new batch processes.

Yes Perform Support

Create Technical Design Specifications

Documents the technical design for RICEFW requirements and details the technical approach that will be followed to meet the identified requirements.

Note: this is not required because the assumption is that no changes to existing interfaces are needed, data conversion is not needed, and that configuration changes, and not code, is all that is required to fulfill the requirements. However, if code changes are required, the Contractor will be responsible to make those changes and create the associated Design Specifications.

No Perform Support

Update Requirements Traceability Matrix

If new functional or technical requirements are identified during the Design phase, the RTM must be updated to reflect these new requirements prior to the start of the Test phase.

Yes Perform Support

Define Technical

Create Technical

Documents any changes to the OAKS architecture introduced by the

No Perform Support




Architecture Architecture Specifications

project.

Define Testing Strategy

Develop Testing Strategy

Describes the testing approach that will be used; it outlines the testing scope, benefits, required testing environment, testing resources etc.

Yes Perform Support

Identify Testing Methods and Testing Tools

The functional team analyzes the requirements and design specifications to determine the appropriate methods for performing the unit, system, integration, and user acceptance system and security tests. In addition, the testing lead identifies all tools required to perform the tests.

Note: Training courses must be developed in the Captivate. Contractors are responsible for providing Captivate licenses for their training development staff.

Yes Perform Support

Identify Tester Requirements

The functional team needs to identify the resources and the skills required by those resources to perform the tests. The team identifies the specific tasks the individual teams/groups is required to perform, timeframe needed, and any special skills required (programming language, system familiarity etc.).

Yes Perform Support

Manage Change Work

Design Training Course Curriculum

During the Analyze Phase, high-level course objectives were identified. In the Design Phase, the training team will review the high-level course objectives and design a training course curriculum. During this task, the training team will draft a course description for each course.

Yes Perform Support

Execute and Monitor Readiness Activities

During this task, the organizational change management team will execute the various activities as outlined in the readiness and communication plan.

Yes Perform Support

Manage Project Work


The project manager will validate and update the project plan at this

Yes Perform Support




phase, as well as document risk/issues as they occur. Overall, the project manager will be responsible and will hold the project team accountable for their assigned work.

Report and Manage Project Risks/ Issues

The project manager is responsible in identifying and documenting project risks/issues throughout the project.

Yes Perform Support

Conduct Design Gate Review & Capture Lessons Learned


Yes Perform Support

5.3.2. Design Phase Deliverables and Work Products

5.3.2.1. Functional Design Specifications (D)

The functional design specifications deliverable will translate the business requirements into a functional representation of how the system and processes will operate. The functional team is responsible for this task and confirms that the construction details of the system, each system component’s interaction with other components and external systems, and the interface that allows end users to operate the system and its functions. The designs may be developed for various component types, some examples are (Report, Interface, Conversion, Extension and Forms).

5.3.2.2. Configuration Design Specifications (D)

The configuration design specification deliverable documents the table configuration changes required for all in scope processes. This includes PeopleSoft and non-PeopleSoft configuration. In addition, it details the functional approach that will be followed to meet the identified configuration requirement, the method for updating the existing configuration values and lists the requirements associated with the changes. The functional team is responsible for this deliverable.

5.3.2.3. Security Design Specifications (D)

The security design specifications deliverable outlines the plan for updating and implementing system security for the OAKS projects. The security design deliverable usually contains the following sections: Gathering Security Requirements Building out Permission Lists and Security Roles Testing Security User Profile Maintenance Production Security Implementation


The State’s Single Sign On / Identify Management Solution needs to be accounted for in the security design specifications.

5.3.2.4. Batch Processing Specification(D)

The batch processing design deliverable updates existing batch flows to include any new batch processes as a result of the new project being implemented.


5.3.2.5. Technical Design Specifications (D)

The technical design specifications deliverable translates the functional design into a representation of all software components needed to fulfill the functional requirements and associated business process. Additionally, this task confirms differences between the business requirements, functional design and technical design are that those differences are clearly identified, communicated, and resolved with the appropriate parties prior to the build of the work unit.

5.3.2.6. Technical Architecture Specifications (D)

The purpose of the technical architecture specifications deliverable is to describe changes to OAKS architecture that will be introduced by the new project. Aspects of existing OAKS architecture that will remain unchanged as a result of the new project, including physical infrastructure, development standards, and remote access are beyond the scope of this deliverable. The architectural changes resulting from the new project are organized into the following categories: Execution Architecture Development Architecture Operations Architecture Interface Architecture Security Architecture

5.3.2.7. Testing Strategy (D)

The testing strategy includes the testing objective, methods of testing new functions; total time and resources required for the project and the required testing environment. Test strategies describe how the product risks of the stakeholders are mitigated at the test-level and which types of test are to be performed. The testing strategy must provide details on entry and exit criteria, script format, defect severity definitions, status meetings, reporting, defect tracking, environment refreshes and any other relevant data.

Overall, the test strategy must give a clear vision of what the testing team will do for the whole project for the entire duration.

5.3.2.8. Training Course Curriculum (D)

During the Analyze Phase, high-level course objectives were identified. In the Design Phase, the training team will review the high-level course objectives and design a training course curriculum which provides a course description for each course.


Ongoing management of project risks and issues.

5.3.2.10. Design Gate Review Results (D)

The Design Gate Review Results confirms the Design Phase work was completed successfully, the appropriate team members have reviewed deliverables and that the team is ready to move to the Build phase. This deliverable must document the following: All deliverables specified to be completed during the Design phase have been approved by the

State.


The overall status of the project with clear documentation related to any significant risks and issues.

5.4.Build Phase

The purpose of the Build Phase is to convert the system designed in the Design Phase into a working information system that addresses all documented system requirements. Although much of the activity in the Build Phase addresses the software that make up the system, this phase also puts in place the hardware, test scripts and communications environment for the system and other important elements of the overall system.

The Build Phase represents an iterative process during which the project team builds the system, tests individual components of the system build, modifies the system based on any problems identified during build testing, and retests the modified system build. The project team uses established configuration management repositories to manage work as it proceeds. Overall, activities of this phase translate the system design produced in the Design Phase into a working information system capable of addressing the information system requirements that are documented in the functional design specifications deliverable. In addition, it is imperative that the project manager confirms that all project resources work on their assigned activities as described in the project plan and are not pulled in other competing assignments.

The Build Phase is broken down into 5 key activities: Define Deployment Strategy Build & Test Code Prepare Implementation Materials Manage Change Work Manage Project Work

Figure 5 - Key Activities of the Build Phase


5.4.1. Build Phase Key Tasks

The Build phase key tasks and task responsibilities are identified in the table below.

Build PhaseActivities Tasks Purpose Mandatory

TaskContractor State

Define Deployment Strategy

Develop Deployment Strategy and Plan

Defines the plan for cutover activities, deployment preparation, stabilization plan and transitioning the in-scope process into production.

Yes Perform Support

Define Knowledge Transfer Plan

Defines the plan to transition project specific information required to support the solution to the ongoing staff at the State.

Yes Perform Support

Build & Test Code

Initiate Development Activities

The Development Team begins development by verifying selection for standards, templates, checklists, methods, necessary hardware/software tools and computer languages. In addition, the development team performs configuration management, change control and documents/resolves problems and non-conformances found in the software products.

Note: this is not required because the assumption is that no changes to existing interfaces are needed and that configuration changes, and not code, is all that is required to fulfill the requirements. However, if code changes are required, the Contractor will be responsible Initiate Development Activities.

No Perform Support

Code and Test During this task functional specifications from the design phase are broken down into detailed technical specifications, by work package, which are used as the guideline for developing the software. Members of the development team involved in constructing the software may include architects, technical analysts, and programmers with different levels of expertise, database administrators, testing leads and other roles.

Note: this is not required because the assumption is that no changes to existing interfaces are needed and that configuration changes, and not

No Perform Support




code, is all that is required to fulfill the requirements. However, if code changes are required, the Contractor will be responsible for Creating Code and Unit Testing that code.

Develop Test Scripts

During the Build phase the main task of the functional team is to prepare for Test Phase, including the creation of System Test scripts. Test scripts in software testing are a set of instructions that will be performed on the system under test to test that the system functions as expected.

Yes Perform Support

Develop Build Documentation and Unit Test Results

Provides build documentation, changes to code and the results of unit tests conducted.

Note: this is not required because the assumption is that no changes to existing interfaces are needed and that configuration changes, and not code, is all that is required to fulfill the requirements. However, if code changes are required, the Contractor will be responsible for Developing Build Documentation and Unit Test Results.

No Perform Support

Develop Master Test Plan

Documents the plan, scripts and schedule required to execute the various tests. Covers all testing phases.

Yes Perform Support

Update Requirements Traceability Matrix

If new functional or technical requirements are identified during the Design phase, the RTM must be updated to reflect these new requirements prior to the start of the Test phase.

Yes Perform Support




Prepare Implementation Materials

Develop Operations and Maintenance Documentation

Document all procedural information necessary for operating and maintaining the application after deployment.

Yes Perform Support

Manage Change Work

Build Detailed Course Outline and Storyboards

During this task, the training development team will execute the training strategy that was outlined in previous phases to develop training courses for the user community. Each detailed course outline must include the following:• Course title• Duration of the course• Suggested class size • Clear course objectives• A course syllabus• Training resources to be used, such as devices, aids, materials and media.

Yes Perform Support

Design Training Evaluation Approach

During this task, the training team will design a training evaluation approach. A training evaluation approach is very important as it provides an objective summary of quantitative and qualitative data gathered about the effectiveness of training.

Yes Perform Support

Prepare Training Deployment Logistics

Document how instructor-led and/or web-based training will be deployed.

Yes Perform Support

Develop Content for Business Process Workshops

Hands-On workshops to provide end users an early introduction of the new processes

Yes Perform Support

Deliver Business Process Workshops to End-Users

The agency readiness lead will conduct the business process workshops to selected stakeholders.

Yes Perform Support

Develop Training Deployment Plan

Documents the plan for rolling out the training to end users by including calendar dates, locations, users to be trained, etc.

Yes Perform Support




Updated Training Strategy

The training development team as they develop and schedule the training courses will also update the training strategy if necessary.

Yes Perform Support



Yes Perform Support

Manage Project Work



Yes Perform Support

Report and Manage Project Risk Issues


Yes Perform Support

Develop Go-Live Acceptance Criteria

Documents the formal project acceptance criteria. This will be used later in the Go/No-Go Meeting.

Yes Perform Support

Conduct a Build Gate Review Phase and Capture Lessons Learned


Yes Perform Support

5.4.2. Build Phase Deliverables and Work Products

5.4.2.1. Build and Unit Test Results (D)

The Build Documentation and Unit Test Results deliverable documents the development of each unit or module, including the test cases, software, test results, approvals and any other items that will help explain the functionality of the system. In addition, the deliverable must include any changes to code and have traceability back to the system requirements documented in the RTM.

5.4.2.2. Master Test Plan (D)


The Master Test Plan describes the scope, approach, resources and schedule of the intended testing activities. It will identify each specific test phase to be executed and for each phase it will identify , the scope of the test phase, the testing tasks, who will execute each task, and any risks requiring contingency planning.

5.4.2.3. Completed Test Scripts (D)

The completed set of test scripts that will be utilized in System Test. These scripts must include the step-by-step instructions, required data sets, and expected results. Additionally, the scripts must be referenced in the RTM to ensure that all system functionality is tested.

These details are necessary to ensure that the tester has enough information to test the process correctly and have the information necessary to determine if the test was successful or not.

5.4.2.4. Operations and Maintenance Documentation (D)

All procedural documentation necessary for operating and maintaining the application after the new services have been deployed. This documentation may include maintenance schedules, run book updates, batch job documentation, and operational manuals. During this task the following documents need to be developed / updated: User Procedures are documented in a user’s manual that provide system procedures to allow user

organizations to determine the software’s applicability and when and how to use it.

Operations procedures are documented in the operations manual and provide computer personnel with a description of the system, the environment, which the system will run, and the procedures to be followed. Components of the Operations Procedures may include the following artifacts. Specific documents to be developed / updated depend on the organizations role in supporting the software:o Maintenance Schedule o Run Booko Maintenance Procedures o Business Process Flow Diagrams

5.4.2.5. Training Deployment Plan (D)

The purpose of the training deployment plan is to define a deployment plan for rolling out the training to the end users. The training lead is responsible in developing the training deployment plan.

The training deployment plan lists all the tactical activities that need to happen as training gets rolled out to end users. The following sections need to be included in the training deployment plan: Reservation of Rooms Training Schedule Infrastructure Requirements Training Schedule

5.4.2.6. Deployment Strategy (D)

The Deployment Strategy and Plan deliverable outlines a high-level approach for transitioning the in-scope processes into production. The deployment strategy must include all resources needed to successfully execute deployment activities including people, process, technology, and change management.

The Deployment Strategy must include Go-Live Acceptance criteria, which will be evaluated during the Go / No-Go meeting, and a Knowledge Transfer Plan. A knowledge transfer plan defines the


knowledge transfer process and the methods that will be used to successfully transition project team application, technology, business process, and operational knowledge, skills and responsibility required to support the OAKS solution to the ongoing support staff at the State. The plan must clearly define what skills and knowledge need transferred to whom, the timeframe and method for transferring the knowledge, and a mechanism for the State transferee to acknowledge the information has been transitioned to them.



5.4.2.8. Build Gate Review Results (D)

The Build Gate Review Results confirms the Build Phase work was completed successfully; the appropriate team members have reviewed deliverables and that the team is ready to move to the Test phase. This deliverable must document the following:• All deliverables planned to be completed during the Build phase have been approved by the State.• The overall status of the project with clear documentation related to any significant risks and issues.


5.5.Test Phase

The purpose of the Test Phase is to determine whether the IT solution that was successfully built, satisfies the functional and technical requirements defined in the functional requirements definition deliverable and the system is ready for deployment. During the Test Phase, formally controlled and focused testing is performed to uncover errors and bugs in the IT solution that need to be resolved. In addition, there are number of validation tests that are performed (e.g., requirements validation, system integration, interface, regression, security, performance, stress, usability, and user acceptance).

Successful completion of the Test Phase must comprise: Proof through system, security, user acceptance, parallel, performance and operational readiness tests that

the system meets all requirements, functions according to design parameters and satisfies all stakeholders Assurance that the system functions as described in the operations manual and user manual Conversion of data from the legacy system Approval to progress to Deploy Phase

The Test Phase is broken down into 4 key activities: Plan for Testing Conduct Testing Manage Change Manage Project Work

Figure 6 - Key Activities of the Test Phase


5.5.1. Test Phase Key Tasks

The Test phase key tasks and task responsibilities are identified in the table below.

Test PhasePhase Activities

Phase Tasks Purpose Mandatory Task

Contractor State

Plan for Testing

Review & Update Master Test Plan

The Development team reviews and updates the test plan by including the test conditions, scenarios and scripts for the various testing that need to be performed.

Yes Perform Support

Migrate Solution to Appropriate Testing Environment

The Development team is responsible for migrating the solution to the appropriate testing environment.

Yes Perform Support

Perform Legacy Data Conversion Testing

The development team executes and fully tests the conversion plan to migrate legacy data to the new system. The development team may repeat data migration and conversion for each iteration associated with a release to production.

Note: this is not required because the assumption is that Data Conversion is not required. However, if Data Conversion is required to successfully deploy the system requirements and fulfill the Contract, the Contractor will be responsible for testing the Data Conversion.

No Perform Support

Initiate Testing Activities

The development team confirms all data is loaded to test databases and prepares any internal or external interfaces. Planning testing activities need to be performed for each release.

Yes Perform Support

Conduct Testing

Conduct System Testing

Documents the plan, scripts, results from the system testing

Yes Perform Support

Conduct User Acceptance Testing

Documents the plan, scripts, results from the user acceptance testing.

Yes Perform Support




Contractor State

Conduct Parallel Testing

Documents the plan, scripts, results from the parallel testing

No Perform Support

Conduct Performance Testing

Documents the plan, scripts, results from performance testing

Yes Perform Support

Conduct Operational Readiness Testing

Documents the plan, scripts, results from operational readiness testing.

No Perform Support

Manage Change Work

Prepare Training Environment

Document the datasets for entry into training environment.

Yes Perform Support

Develop Training Materials

During this task the training team will build the training content that will be utilized to train end users.

Yes Perform Support

Finalize Training Logistics

During this task the OCM team will finalize the training logistics and start registering training participants. Some of the tasks that need to be handled are such as acquiring ID’s for training participants and trainers, providing them access with the internet/intranet and other technical requirements.

Yes Perform Support

Test Equipment and Access

All training equipment needs to be tested and be ready for the training development.

Yes Perform Support

Pilot/ Test Training Materials

All training materials identified in the course curriculum.

Yes Perform Support



Yes Perform Support

Manage Project Work



Yes Perform Support




Contractor State

Report and Manage Project Risks/ Issues


Yes Perform Support

Plan for Deploy Phase

The Deployment Plan must be updated based on information learned in mock deployments executed during testing. The Deployment Plan, which was initially developed in 6.2.1 – Development Deployment Strategy and Plan, must be finalized prior to the end of the Test phase and the status will be reviewed as part of the Test Phase Gate Review.

Yes Perform Support

Conduct Test Gate Review Phase and Capture Lessons Learned


Yes Perform Support

5.5.2. Test Phase Deliverables and Work Products

5.5.2.1. System Test Results (D)

The completed set of executed system test scripts which confirms the executed test scripts match the expected results. To successfully exit system test, the System Test Results must be consistent with the System Test Exit criteria documented in the Testing Strategy deliverable.

5.5.2.2. User Acceptance Test (UAT) Results (D)

The completed set of executed UAT test scripts which confirms the executed test scripts match the expected results. To successfully exit UAT, the UAT Test Results must be consistent with the UAT Test Exit criteria documented in the Testing Strategy deliverable.

5.5.2.3. Performance Test Results (D)

The documented results of Performance Testing. To successfully exit Performance Test the Performance Test Results must be consistent with the Performance Test Exit Criteria documented in the Testing Strategy deliverable.

5.5.2.4. Operational Readiness Test Results (D)


The documented results of Operational Readiness Testing. To successfully exit Operational Readiness Test, the Operational Readiness Test Results must be consistent with the Performance Test Exit Criteria documented in the Testing Strategy deliverable.

5.5.2.5. Training Materials (D)

The completed set of training content approved by the State OCM team which aligns with the Training Course Curriculum.



5.5.2.7. Test Gate Review Results (D)

The Test Gate Review Results confirms the Test Phase work was completed successfully, the appropriate team members have reviewed deliverables and that the team is ready to move to the Test phase. This deliverable must document the following: All deliverables planned to be completed during the Test phase have been approved by the State. The overall status of the project with clear documentation related to any significant risks and issues.


5.6.Deployment Phase

The purpose of the Deploy Phase is to install and release the new solution in its target environment. During the Deploy Phase end-users will be trained and the system will be turned over to maintenance personnel. After the Deploy Phase, the team conducts a project review, captures lessons learned and conducts a customer satisfaction review. The overall objective of the Deploy Phase is to make the solution operational and available to the business community and other stakeholders.

Successful completion of the Deploy Phase must comprise: Assess go-live readiness Production installation and release Training of end users on the system

The Deploy Phase is broken down into 3 key activities: Prepare for Deployment Manage Change Work Go Live

Figure 7 - Key Activities of the Deploy Phase


5.6.1. Deploy Phase Key Tasks

The Deploy phase key tasks and task responsibilities are identified in the table below.

Deploy PhaseActivities Tasks Purpose Mandatory


Prepare for Deployment

Assess Go-Live Readiness

Meeting to assess go-live readiness across the project with a formal vote by the project sponsors to allow deployment to begin.

Yes Perform Support

Initiate Deployment Activities

The technical team updates the deployment plan, installs, configures and tests the hardware and software components of the solution.

Yes Perform Support

Create Stabilization Plan

Documents the post go live support tasks, operational cutover tasks and converting data.

Yes Perform Support

Manage Change Work

Deliver Training to End Users

The formal training materials that have been developed to train end users

Yes Perform Support

Communicate Go-Live Details

The project manager sends the final implementation communication notice to all end users and organizations affected by the implementation. In addition, stakeholders that are not directly affected by the implementation will also be informed. The communication notice must include the following:• Implementation Schedule• Brief description of the benefits of the new system• Differences between the old and new system• Responsibilities of end users during the Deploy Phase• Instructions for contacting technical support, including contact names and phone numbers

Yes Perform Support

Execute Knowledge Transfer Activities

Documents the knowledge transfer activities from the vendor to the State Personnel with State signoff and acceptance

Yes Perform Support

Prepare Yes Perform Support




Support Centers for Go Live ( Help Desks)

Implement Benefit Tracking Mechanisms

During this task, any benefit tracking mechanisms that were documented in the business and designed / built throughout the course of the project must be deployed. Benefit tracking mechanisms may need to be executed by organizations outside of the OAKS community and the project manager must ensure that these organizations understand their responsibilities and have the resources needed to accomplish this task.

Yes Support Perform



Yes Perform Support

Go Live Migrate Solution to Production Environment

The technical team installs the system in the production environment. While migrating the solution, the technical team must keep the configuration information updated by following the configuration management plan and deployment as defined in the Design Phase.

Yes Perform Support

Handoff to Service Assurance Team

During this task the project lead officially hands over the solution to the service assurance team after the criteria defined in the Stabilization Plan has been successfully met.

Yes Perform Support

Manage Project Work



Yes Perform Support

Report and Manage Project

The project manager is responsible in identifying and

Yes Perform Support




Risks/ Issues documenting project risks/issues throughout the project.

5.6.2. Deployment Phase Deliverables and Work Products

5.6.2.1. Stabilization Plan (D)

The stabilization plan that details the support structures and processes implemented for Deployment. This plan will detail the roles of the various teams involved in support, how production defect meetings and resolution will occur, and the communication processes to inform project executives and end users of issues. The Stabilization Plan will also identify the criteria by which support will be formally transferred from the project team to the service assurance team.

The stabilization plan must be created in collaboration with the OAKS Operations and support teams. This collaboration is required to confirm roles, responsibilities, and access requirements for deployment and hypercare activities.

How much support? 30 days or 60 days

5.6.2.2. Go / No-Go Meeting (D)

Completed presentation materials and a facilitated Go / No-Go Meeting with project leadership and sponsors to ensure the criteria established to go live and deploy the software, has been met.

5.6.2.3. Knowledge Transfer Plan Signoff (W)

Documentation of the completed Knowledge Transfer Plan as identified in the Deployment Strategy. Documentation must include sign-off by the State resources receiving the Knowledge Transfer.


Ongoing Management of project risks and issues


5.7.Closure Phase

The purpose of the Closure Phase is to ensure the project is successfully closed from a contractual and resource perspective. During the Closure Phase contractual project agreements are closed out, project resources are off-boarded, project documentation is appropriately archived, and any remaining project funds are returned to the general OAKS funds. At the conclusion of the Closure Phase, the project is officially complete.

The Closure Phase is broken down into 4 key activities: Obtain Stakeholder Acceptance Reinforce Change Close Out Procurements Off-Board Project Resources/ Decommission Project Environments Archive Project Documentation

Figure 8 - Key Activities of the Closure Phase


5.7.1. Closure Phase Key Tasks

The Closure phase key tasks and task responsibilities are identified in the table below.

Closure PhaseActivities Tasks Purpose Mandatory


Obtain Stakeholder Acceptance

Confirm Stakeholder Expectations Have Been Met

After the system has been successfully deployed, the project manager needs to confirm that the project stakeholder’s expectations have been successfully met. The final project governance meeting is the forum where the documented stakeholder expectations must be reviewed. Any expectations that have not been met need to be documented along with the appropriate disposition of that expectation.

Yes Support Perform

Obtain Final Project Acceptance from Project Sponsors

The project manager needs to confirm that the project sponsors agree that all project requirements have been successfully delivered and that they agree to formally close the project. This step must take place after the production support phase of deployment is complete and the system is stable. This task must be accomplished at the final project governance meeting.

Yes Perform Support

Close Out Procurements

Complete Contractual Agreements

The project manager must ensure that all contractual agreements with all Contractors have been successfully met. Contractors will need to provide 90 days of post-production support with all High Defects Resolved prior to project closure. They must complete the successful transition of the system(s) to production/live use, support resolution of defects in the period following, and then handoff to the State for ongoing operation and maintenance. If any agreement has not been met, then the outstanding requirements need to be escalated and dealt with appropriately.

Yes Perform Support

Consolidate and Document the Finalized Project

The project manager must ensure that all approved Contractor payments were successfully executed and that there are no outstanding payments

Yes Support Perform




Financial Statements

required. If, for some reason, a purchase order has any remaining funds after all required payments have been met; the purchase order must be closed out. This information will need to be confirmed with both the OAKS Service Transition team and the OIT Business office before the purchase order is closed.

Confirm and Disperse Remaining Project Funds

Any remaining project funds, either remaining from project purchase orders or from unused contingency, must be returned to general OAKS budget pool and must then be available for use by other OAKS projects.

Yes NA Perform

Off-Board Project Resources

Off-Board Project Resources

All project resources, Contractor and State, which participated on the project must be appropriately off-boarded. For Contractor resources, they need to be formally off-boarded from OAKS and all system access must be revoked. State resources must be return to their operational organizations and responsibilities. State resources may also need to have system access revoked depending upon their operational roles and responsibilities.

Any project environments that are not part of the operational production support migration path will need be decommissioned. The decommission date for all project environments must be documented in the project Environment Approach.

Yes Perform Support

Decommission Project Environments

After completion of the project the documentation needs to be managed appropriately. The hard copies of project documentation need to be reviewed and either destroyed or stored appropriately. Any hard copies of project information that contains any sensitive data must be destroyed.

Yes Perform Support

Clean Up Project Office Space

All project offices and conference rooms that were utilized by the project team need to be cleaned up and returned to the state prior to the project.

Yes Perform Support




Archive Project Documentation

Manage Project Documentation

Yes Support Perform

Manage Project SharePoint

Soft copies of project documentation must be stored in the appropriate library on the project SharePoint site. Also, the project SharePoint site must be moved to the Project library that is accessible to all OAKS SharePoint users to the Project Management SharePoint library so that the public site remains uncluttered and to ensure that the PMO team controls all project documentation.

Yes Support Perform

Manage Change Work

Post-Implementation Satisfaction Survey

An end-user survey or focus group discussion to gauge the success of the project. This information would feed into the State’s continuous adoption efforts.

Yes Perform Support

Post-Implementation Scorecard

An assessment to determine the level of use and comfort of the new software/functionality. This information would feed into the State’s continuous adoption efforts.

Yes Perform Support

Update Training Materials

The Contractor will update the training materials to incorporate necessary changes identified during end user training or a result of defect resolutions.

Yes Perform Support

Conduct Lessons Learned Sessions

The final project lessons learned session must be held with the stakeholders and sponsors. Their feedback must be added to the other project lessons learned documentation.

Yes NA Perform


5.7.2. Closure Phase Deliverables and Work Products

5.7.2.1. Updated Training Materials (D)

The Contractor will update the training materials to incorporate necessary changes identified during end user training or a result of defect resolutions. .

5.7.2.2. Project Acceptance (D)

Project Acceptance documents that all project requirements have been successfully delivered and that the State's agreement to formally close the project. This step must take place after the production support phase of deployment is complete and the system is stable. This task must be accomplished at the final project governance meeting. Knowledge Transfer Plan Signoff (W) Documentation of the completed Knowledge Transfer Plan as identified in the Deployment Strategy. Documentation must include sign-off by the State resources receiving the Knowledge Transfer.


Ongoing Management of project risks and issues

5.7.2.4. Lessons Learned (W)

The project lessons learned session must be held with the stakeholders and sponsors. Their feedback must be added to the other project lessons learned documentation.


6. Project Team Requirements

6.1.State Key Project Team Roles and Responsibilities

Key State Project Team Member ResponsibilitiesRole ID State Role Role Activity FT/PT

1 Project Sponsors Provide input for development of strategic objectives, potential initiatives, and anticipated benefits

Provide input on key Project decisions Interpret current State policies and provide

guidance on potential policy updates Interpret current State policies and provide

guidance on potential policy updatesSupport Project deliverables approvals

PT

2 Project Manager Provide direction to State resources Review and approve deliverables Communicate with Project Sponsors Provide leadership and management of the Project Oversee daily Project activities including budget

and schedule management Serve as the point of contact to coordinate the

activities with the State functional Subject Matter Experts (SMEs)

Monitor the status of the Project, and takes any steps necessary to re-direct priorities, re-define the Project organization, work plan, toward completion of the Project

Participate in the development of a communication strategy and is responsible for the delivery and dissemination of Project communication and statuses

Provide guidance to State and Project resources and oversee development of Project deliverables

PT

3 KRONOS Administrator Facilitate contact with agency resources for Analysis/Design workshop and data collection scheduling

Provide information on current KRONOS systems, support and usage

Provide guidance to State and Contractor Project resources and oversee development of Project deliverables

PT

4 KRONOS SME (Functional Lead)

Provide information on current KRONOS system, support and usage

Provides PeopleSoft (HCM) expertise and knowledge

Support development of Project deliverables

PT


Key State Project Team Member ResponsibilitiesRole ID State Role Role Activity FT/PT

5 KRONOS Configuration/Operations Analyst(s)

Provide information on current KRONOS system, support and usage

Supports development of Project deliverables

PT

6 OCM Lead

Provide guidance in State OCM methodology and recommended change management practices

Provide State tools & templates for OCM practices and guidance in the use of these tools

Lead the Contractor in completing the required Prosci Proprietary Impact Index risk analysis

Review and provides Quality Assurance for all OCM work products

PT

6.2.Contractor Key Project Team Roles and Responsibilities

The following table identifies key Contractor roles and responsibilities that are deemed critical to the success of the Project and are required to be full time and dedicated only to this Project. The offeror, as part of their proposal, is required to identify these key positions and may also include other designated positions for support of the Project. At a minimum, the Contractor’s staffing plan must include names and biographical resumes for all Key Roles and positions, including the project manager. If the offeror deems appropriate and DAS agrees, some roles may be filled by a single resource.

Resumes must be provided for all Key Project personnel in order to supplement the descriptive narrative provided by the offeror regarding their proposed project team.

The resume, not to exceed 2 pages, must include: Candidate’s Name Proposed role on this Project Education Professional Licenses/Certifications/Memberships List of completed projects that are comparable to this Project or required similar skills based on the

candidate’s assigned role and responsibilities in the Project, including the following details:o Project title and descriptiono Beginning and ending dates o Client/company name for which the work was performed o Client contact information for sponsoring Directors, Managers or equivalent level position (name,

phone number, email address, company name, etc.) for referenceso Detailed description of the person’s role/responsibility on the project


The Contractor must provide a dedicated Project Manager for the Project. This Project Manager and proposed key staff must work on-site at the designated State office through Project implementation except as approved by the State Project Manager.

Key Contractor Project Team Member ResponsibilitiesRole ID State Role Role Activity FT/PT

1 Project Manager Minimum requirements 5 years of Kronos project implementation

experience 3 years of experience leading Kronos teams in a

project environment

Project responsibilities Create and Maintain Project Plan Review Deliverables and Manage the State’s

Approvals Create Project Status Reports Report and Manage Issues and Risks Manage relationships with sponsors and

stakeholders Oversee daily Project activities including budget

and schedule management Manage Contractor Project Staff Collaborate with State Project Staff Oversee development of Project deliverables Oversee daily Project activities including budget

and schedule management Responsible for design and implementation of

Project management processes, organizational structures, resource allocation assignments and other control mechanisms necessary to accomplish the Project objectives within the agreed upon time frames

Monitor the status of the Project, and take any steps necessary to re-direct priorities, re-define the Project organization or work plan toward completion of the Project

Manage, Maintain and Meet Change Management/Business Analysis Deliverable Milestones

Identify and manage project issues and risks

FT

2 KRONOS Business Analyst(s)

Minimum requirements 3 years of experience working on Kronos teams in

a project environment

Project responsibilities Identify and collect business analysis data required

for project deliverables Develop project deliverables Conduct Fit / Gap Analysis Support change management activities and

deliverables Create the KRONOS Expansion Adoption

Guidebook

FT


Key Contractor Project Team Member ResponsibilitiesRole ID State Role Role Activity FT/PT

3 KRONOS OCM Lead Minimum requirements 5 years of organizational change management

project experience Project experience must include training,

communications, and readiness

Project responsibilities Create and manage the OCM Strategy, which

includes the State’s approved approaches for communication, business readiness and training.

Create and manage the OCM Communication Strategy & Plan

Oversee the execution of the Training Needs Analysis, Training Strategy, Training Materials, Training Deployment Plan and Knowledge Transfer Plan.

Work with the Project Manager, key leaders and project teams to integrate OCM activities into the overall Project Plan.

Coordinate development of communications and training materials.

Coordinate development of business readiness activities

Report OCM readiness status to Project Manager Manage, resolve and escalate issues that are

raised by the OCM team.

FT

4 KRONOS Training Developer members

Minimum requirements 2 years of web-based training development

experience

Project responsibilities Develop we-based training using Captivate

software

PT

5 KRONOS OCM Team members

Minimum requirements 1 year of organizational change management

project experience

Project responsibilities Communications resource will work with the OCM

Lead to create and manage the communications plan and write communications.

Training resource(s) will complete training needs analysis, training strategy, training materials, training deployment plan and knowledge transfer plan.

Agency readiness resource(s) will work with business analysts to track readiness tasks

FT

The quality of the offeror’s proposed Project team to deliver the Projects as defined and required in Supplement 1 including the quality of the offeror’s proposed Project team and ongoing Project delivery capacity will impact


the success of the Projects. Therefore, each team member’s experience, education, and skills will be considered in assigning a score to this area.

6.3.Offeror Response - Project Staffing and Time Requirement

The offeror’s Staffing Plan and Time Commitment response must include the following information: An organizational chart including any subcontractors and key management and administrative personnel

assigned to this project. A contingency plan that shows the ability to add more staff if needed to ensure meeting the Project’s due

date(s). The number of people onsite at State location(s) at any given time to allow DAS to plan for the

appropriate workspace. A statement and a chart that clearly indicates the time commitment, inclusive of the Project Manager and

the offeror’s proposed team members for this Work during each stage of the Project and the System Development Life Cycle.

A statement indicating to what extent, if any, the candidates may work on other projects or assignments that are not related to DAS during the term of the Contract.

DAS may reject any Proposal that commits the proposed Project Manager or any proposed Key Project Personnel to other projects during the term of the Project, if DAS believes that any such commitment may be detrimental to the offeror’s performance.


7. Deliverables

The following is a consolidated list of the Project deliverables and Work Products the Contractor must produce to successfully complete the Project .

Each offeror responding to this procurement must follow the deliverables set for KRONOS Expansion and include cost per each deliverable.

# Section Reference Phase

Work Product /

DeliverableName Description

1 5.1.2.2 Initiate Deliverable Project Plan

The plan detailing the phases, tasks and activities to be executed during the project. The project plan must contain tasks, resources, work products, deliverables, timeframes, milestones, constraint dates, and dependencies in a Work Breakdown Structure (WBS) format. The project plan must include OCM and Training related tasks, work products and deliverables.

2 5.1.2.3 Initiate Deliverable Project Kick-off Deck

The Project Kick-off Deck illustrates the project scope, objectives, project structure, high level schedule, major deliverables, etc. The State Project Manager will still be held accountable in reviewing the deck, inviting the appropriate stakeholders and co-presenting at the kick-off meeting.

3 5.1.2.4 Initiate DeliverableInitiate Gate Review Results

The Initiate Gate Review Results confirms the Initiate Phase work was completed successfully, the appropriate team members have reviewed deliverables and that the team is ready to move to the Analyze phase. This deliverable must document the following: The project must have approved a complete, realistic and updated project plan. A project kick-off deck and meeting must have been completed by the project team. Initiate Phase Work Products and Deliverables have all been approved by the State and are stored on SharePoint. Change Requests that result from the Initiate Phase must be introduced. Completion of the PAC Kick Off Meeting and an understanding of the PAC process. Acknowledgement of an understanding of the CAB process. Acknowledgement of an understanding of the OAKS Risk and Issue Management process and the OAKS SharePoint Log must be linked to the project SharePoint site.

Completion of the SLA Initiation Meeting.



Work Product /


4 5.1.3.1 Analyze DeliverableRICEFW / Retrofit Inventory

The Report, Interface, Conversion, Enhancement, Form, Workflow (RICEFW) / Retrofit Inventories identify the required RICEFW objects and configuration changes for the software components of the project. This inventory must include all changes necessary to OAKS as well as any software being implemented to integrate with OAKS in order to create a holistic view of the work at hand. The functional lead is responsible for this deliverable.

5 5.1.3.2 Analyze DeliverableRequirements Traceability Matrix (RTM)

The RTM is a “living” document that lists the requirements identified by the system users and validated by the functional team. This document must be in the State’s format, utilizing the RTM Template. It lists the requirements for the processes, which will be designed and/or built, and subsequently tested and deployed. This document must be continually updated throughout the project for traceability of the business need being conceived in requirements, configured into design documents, implemented into a system, tested through scripts, and ultimately deployed as a new component. The functional lead is responsible for this deliverable. The RTM will also be updated with the results from Conference Room Pilots (CRPs).

6 5.1.3.3 Analyze DeliverableConference Room Pilot (CRP) Results

A Conference Room Pilot (CRP) is conducted to illustrate the new features of the proposed solution to users. CRP sessions review the delivered software and then evaluate it against the State’s requirements. The CRPs will result in requirements that “fit” the OAKS PeopleSoft software or are a “gap”. If the requirement is a gap, then it must be determined how to best solution that requirement. This could result in a business process change, a system enhancement, or rollout training that will address the gap and enable the requirement to be deployed. If those options do not seem viable, then the requirement could be rejected or deferred. The CRP results deliverable documents the results of the CRP sessions in a deliverable. This document is key to support the rationale for configuration and design decisions on the project. The CRP Results deliverable must contain the following components:

Description of all CRP sessions with key decisions from the sessions.

Attendance list for all CRP sessions. All OAKS Requirements Analysis Documents

(RADs) created in support of the CRP sessions.



Work Product /


Note: May be needed for new modules: Activities and Advanced Scheduler.

7 5.1.3.4 Analyze Deliverable Environment Approach

The purpose of this deliverable is to outline the approach and procedures for the chosen solution’s development, test, training, and other application environments. It must identify each environment needed to support the full life cycle of the project. For each environment listed the following information must be provided:

Environment Name Intended use of the environment Identify if the environment data will be masked Identify the type of data will be available (demo,

production, test, etc.) Planned availability and decommission dates Hardware stack (Dev, Test, Prod) is referring to

PeopleSoft environments

8 5.1.3.5 Analyze Deliverable

Organizational Change Management Strategy

The Organizational Change Management (OCM) strategy defines the various change management activities that will be addressed throughout the lifecycle of the project. The organizational change management strategy covers the four major OCM disciplines, which are (communication, training, agency readiness and governance). All four disciplines work together to structure the overall preparation and readiness of stakeholders as it relates to the upcoming changes new solutions bring. The OCM Strategy must include the following components:

Communication Plan Communication Strategy Matrix Training Needs Analysis Training Strategy and Plan Readiness Plan

9 5.1.3.6 Analyze Work Product

Risk / Issue Log

The project manager is responsible in identifying and documenting project risks/issues in the OAKS Issues / Risks Log on SharePoint throughout the project. Weekly meetings to discuss risks/issues need to be scheduled.

10 5.1.3.7 Analyze Deliverable Analyze Gate Review Results

The Analyze Gate Review Results confirms the Analyze Phase work was completed successfully, the appropriate team members have reviewed deliverables and that the team is ready to move to the Design phase. This deliverable must document the following:

All deliverables planned to be completed during the Analyze phase have been approved by the State.



Work Product /



11 5.1.4.1 Design DeliverableFunctional Design Specifications

The functional design specifications deliverable translates the business requirements into a functional representation of how the system and processes will operate. The functional team is responsible for this task and confirms that the construction details of the system, each system component’s interaction with other components and external systems, and the interface that allows end users to operate the system and its functions. The designs may be developed for various component types, some examples are (Report, Interface, Conversion, Extension and Forms).

12 5.1.4.2 Design DeliverableConfiguration Design Specifications

The configuration design specification deliverable documents the table configuration changes required for all in scope processes. This includes PeopleSoft and non-PeopleSoft configuration. In addition, it details the functional approach that will be followed to meet the identified configuration requirement, the method for updating the existing configuration values and lists the requirements associated with the changes. The functional team is responsible for this deliverable.

13 5.1.4.3 Design DeliverableSecurity Design Specifications

The security design specifications deliverable outlines the plan for updating and implementing system security for the OAKS projects. The security design deliverable usually contains the following sections:

Gathering Security Requirements Building out Permission Lists and Security

Roles Testing Security User Profile Maintenance Password Controls Production Security Implementation

The State’s Single Sign On / Identify Management Solution needs to be accounted for in the security design specifications.

14 5.1.4.4 Design DeliverableBatch Processing Specifications

The batch processing design deliverable updates the existing batch flows to include any new batch processes as a result of the new project being implemented.



Work Product /


15 5.1.4.5 Design DeliverableTechnical Architecture Specifications

The technical design specifications deliverable translates the functional design into a representation of all software components needed to fulfill the functional requirements and associated business process. Additionally, this task identifies differences between the business requirements, functional design and technical design to identify and communicated resolutions with the appropriate parties prior to the build of the work unit.

16 5.1.4.7 Design Deliverable Testing Strategy

The testing strategy includes the testing objective, methods of testing new functions; total time and resources required for the project and the required testing environment. Test strategies describe how the product risks of the stakeholders are mitigated at the test-level and which types of test are to be performed. The testing strategy must provide details on entry and exit criteria, script format, defect severity definitions, status meetings, reporting, defect tracking, environment refreshes and any other relevant data. Overall, the test strategy must give a clear vision of what the testing team will do for the whole project for the entire duration.

17 5.1.4.8 Design DeliverableTraining Course Curriculum

During the Analyze Phase, high-level course objectives were identified. In the Design Phase, the training team will review the high-level course objectives and design a training course curriculum which provides a course description for each course.

18 5.1.4.9 Design Work Product

Risk / Issue Log Ongoing management of project risks and issues.

19 5.1.4.10 Design DeliverableDesign Gate Review Results

The Design Gate Review Results confirms the Design Phase work was completed successfully, the appropriate team members have reviewed deliverables and that the team is ready to move to the Build phase. This deliverable must document the following:

All deliverables planned to be completed during the Design phase have been approved by the State.


20 5.1.5.1 Build Deliverable

Build Documentation and Unit Test Results

The Build Documentation and Unit Test Results deliverable documents the development of each unit or module, including the test cases, software, test results, approvals and any other items that will help explain the functionality of the system. In addition, the deliverable must include any changes to code and have traceability back to the system requirements documented in the RTM.



Work Product /


21 5.1.5.2 Build Deliverable Master Test Plan

The Master Test Plan describes the scope, approach, resources and schedule of the intended testing activities. It will identify each specific test phase to be executed and for each phase it will identify , the scope of the test phase, the testing tasks, who will execute each task, and any risks requiring contingency planning.

22 5.1.5.3 Build Deliverable Completed Test Scripts

The completed set of test scripts that will be utilized in System Test. These scripts must include the step-by-step instructions, required data sets, and expected results. Additionally, the scripts must be referenced in the RTM to ensure that all system functionality is tested. These details are necessary to ensure that the tester has enough information to test the process correctly and also have the information necessary to determine if the test was successful or not.

23 5.1.5.4 Build Deliverable

Operations and Maintenance Documentation

All procedural documentation necessary for operating and maintaining the application after the new services have been deployed. This documentation may include maintenance schedules, run book updates, batch job documentation, and operational manuals. During this task the following documents need to be developed / updated:

User Procedures- Are documented in a user’s manual that provide system procedures to allow user organizations to determine the software’s applicability and when and how to use it.

Operations procedures- Are documented in the operations manual and provide computer personnel with a description of the system, the environment, which the system will run, and the procedures to be followed. Components of the Operations Procedures may include the following artifacts. Specific documents to be developed / updated depend on the organizations role in supporting the software:

o Maintenance Schedule o Run Book o Maintenance Procedures o Business Process Flow Diagrams

24 5.1.5.5 Build DeliverableTraining Deployment Plan

The purpose of the training deployment plan is to define a deployment plan for rolling out the training to the end users. The training lead is responsible in developing the training deployment plan.



Work Product /


The training deployment plan lists all the tactical activities that need to happen as training gets rolled out to end users. The following sections need to be included in the training deployment plan:

Reservation of Rooms Training Schedule Infrastructure Requirements

25 5.1.5.6 Build Deliverable Deployment Strategy

The Deployment Strategy and Plan deliverable outlines a high-level approach for transitioning the in-scope processes into production. The deployment strategy must include all resources needed to successfully execute deployment activities including people, process, technology, and change management. The Deployment Strategy must include Go-Live Acceptance criteria, which will be evaluated during the Go / No-Go meeting, and a Knowledge Transfer Plan. A knowledge transfer plan defines the knowledge transfer process and the methods that will be used to successfully transition project team application, technology, business process, and operational knowledge, skills and responsibility required to support the OAKS solution to the ongoing support staff at the State. The plan must clearly define what skills and knowledge need transferred to whom, the timeframe and method for transferring the knowledge, and a mechanism for the State transferee to acknowledge the information has been transitioned to them.

26 5.1.5.7 Build Work Product


27 5.1.5.8 Build DeliverableBuild Gate Review Results

The Build Gate Review Results confirms the Build Phase work was completed successfully, the appropriate team members have reviewed deliverables and that the team is ready to move to the Test phase. This deliverable must document the following:

All deliverables planned to be completed during the Build phase have been approved by the State.


28 5.1.6.1 Test Deliverable System Test Results

The completed set of executed system test scripts which confirms the executed test scripts match the expected results. To successfully exit system test, the System Test Results must be consistent with the System Test Exit criteria documented in the Testing Strategy deliverable.

29 5.1.6.2 Test Deliverable User The completed set of executed User Acceptance



Work Product /


Acceptance Test (UAT) Results

Test scripts which confirms the executed test scripts match the expected results. To successfully exit UAT the UAT Results must be consistent with the UAT Exit criteria documented in the Testing Strategy deliverable.

30 5.1.6.3 Test Deliverable Performance Test Results

The documented results of Performance Testing. To successfully exit Performance Test the Performance Test Results must be consistent with the Performance Test Exit criteria documented in the Testing Strategy deliverable.

31 5.1.6.4 Test DeliverableOperational Readiness Test Results

The documented results of Operational Readiness Testing. To successfully exit Performance Test the Operational Readiness Test Results must be consistent with the Operational Readiness Test Exit criteria documented in the Testing Strategy deliverable.

32 5.1.6.5 Test Deliverable Training Materials

The completed set of training content approved by the State OCM team which aligns with the Training Course Curriculum.

33 5.1.6.6 Test Work Product


34 5.1.6.7 Test DeliverableTest Gate Review Results

The Test Gate Review Results confirms the Test Phase work was completed successfully, the appropriate team members have reviewed deliverables and that the team is ready to move to the Deploy phase. This deliverable must document the following:

All deliverables planned to be completed during the Test phase have been approved by the State.


35 5.1.7.1 Deploy Deliverable Stabilization Plan

The stabilization plan that details the support structures and processes implemented for Deployment. This plan will detail the roles of the various teams involved in support, how production defect meetings and resolution will occur, and the communication processes to inform project executives and end users of issues. The Stabilization Plan will also identify the criteria by which support will be formally transferred from the project team to the service assurance team. The stabilization plan must be created in collaboration with the OAKS Operations and support teams. This collaboration is required to confirm roles, responsibilities, and access requirements for deployment and hypercare activities.



Work Product /


36 5.1.7.2 Deploy Deliverable Go / No-Go Meeting

Completed presentation materials and a facilitated Go / No-Go Meeting with project leadership and sponsors to ensure the criteria established to go live and deploy the software, has been met.

37 5.1.7.3 Deploy DeliverableKnowledge Transfer Plan Signoff

Documentation of the completed Knowledge Transfer Plan as identified in the Deployment Strategy. Documentation must include sign-off by the State resources receiving the Knowledge Transfer.

38 5.1.7.4 Deploy Work Product


39 5.1.8.1 Closure DeliverableUpdated Training Materials

The Contractor will update the training materials to incorporate necessary changes identified during end user training or a result of defect resolutions.

40 5.1.8.2 Closure Deliverable Project Acceptance

Project Acceptance documents that all project requirements have been successfully delivered and that the State's agreement to formally close the project. This step must take place after the production support phase of deployment is complete and the system is stable. This task must be accomplished at the final project governance meeting.

41 5.1.8.3 Closure Work Product


42 5.1.8.4 Closure Work Product

Lessons Learned

The project lessons learned session must be held with the stakeholders and sponsors. Their feedback must be added to the other project lessons learned documentation.
