The file's text, extracted by GovTribe without its formatting.
OFFER FORM OF-9
IMPLEMENTATION SERVICES REQUIREMENTS
RFP-23-01-UI
| OFFER FORM OF-9 | 1 | RFP-23-01-UI |
| OF-9 Implementation Services Requirements | 1 | RFP-23-01-UI |
Table of Contents
| 1.0 | Overview of Document | 3 |
| 2.0 | Implementation Services | 3 |
| 2.1 | Project Planning | 4 |
| 2.2 | Initial Analysis and Design | 9 |
| 2.3 | Final Analysis and Design | |
| 2.4 | Configuration and Development | |
| 2.5 | Testing and Training | |
| 2.6 | Data Conversion Roles and Responsibilities | |
| 2.7 | Supplemental Staffing (Implementation) | |
| 2.8 | Deployment and Go-Live Support | |
| 2.9 | Final Acceptance | |
| 2.10 | Warranty Services | |
| 3.0 | Minimum List of Deliverables | |
List of Tables
| Table 1. | Project Planning Roles and Responsibilities | 4 |
| Table 2. | Initial Analysis and Design Roles and Responsibilities | 9 |
| Table 3. | Final Analysis and Design Roles and Responsibilities | |
| Table 4. | Configuration and Development Roles and Responsibilities | |
| Table 5. | Testing and Training Roles and Responsibilities | |
| Table 6. | Data Conversion | |
| Table 7. | Implementation Supplemental Staffing (If Needed by DLIR) Roles | |
| Table 8. | Deployment and Go-Live Support Roles and Responsibilities | |
| Table 9. | Warranty Roles and Responsibilities | |
| Table 10. | Proposed Implementation Services Deliverables | |
Overview of Document
This document clarifies the roles and responsibilities of the State of Hawaii (State) and the prime UIS System Integrator (Offeror) across the life cycle of the project, which consists of the following work activities:
· Implementation Services
· Project Planning
· Initial Analysis and Design
· Final Analysis and Design
· Configuration and Development
· Testing and Training
· Deployment and Go-Live Support
· Warranty
· Minimum List of Deliverables
Implementation Services
The purpose of the Implementation Services section is to describe the tasks and Deliverables expected to occur during this Phase of the Project and to define the expected roles and responsibilities of the State and the Offeror.
As noted in the RFP, each subsection below outlines the high-level roles and responsibilities of both the State and the Offeror overall and for each Deliverable. The State requires the Offeror to assume full management responsibility for the required Offeror and subcontractor Project personnel and associated Deliverables related to this Project. See Attachment E - Deliverables.
Project Planning
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Project Planning Roles and Responsibilities
* Responsible - Anyone responsible for completing tasks. Accountable - Anyone who is accountable for the project.
Consulted - Anyone who should be consulted. Informed - Anyone who should be informed about project progress.
| # |
| Project Planning Roles and Responsibilities |
| Offeror |
| State |
| Offeror Response |
| Offeror Comment |
| 2.1.1 |
| Provide a Project Manager (PM) to represent the Offeror in the management of the Project, interfacing with the State Project Manager (PM) in any decisions relating to the Project. |
| R, A |
| 2.1.2. |
| Assume and lead all day-to-day management of all Offeror personnel, including subcontractor personnel, and associated Deliverables related to the required services. |
| R, A |
| 2.1.3 |
| Provide a Project Manager to represent the State organization in this Project, interfacing with the Offeror’s PM, and representing the State in any decisions relating to the Project. |
R, A
| 2.1.4 |
| Establish a program management office (PMO) for the Project by integrating with the State’s current PMO. |
| R, A |
| 2.1.5a |
| Create a Project Charter, or review and revise an existing Project Charter as necessary. |
R, A
| 2.1.5b |
| Provide a Project Schedule (e.g., in MS Project) that includes the following key components: |
Tasks and activities required to successfully complete the Project Schedule/milestone tracking and resource allocation Critical path identification and dependencies Provide periodic updates (as mutually agreed upon by the State and the Offeror) to the Project Schedule.
R, A
| 2.1.6 |
| Establish a formal requirements management process that shall include: |
Assumption definition, tracking, and traceability in a requirements traceability matrix (RTM) Functional and Technical Requirement definition, tracking, traceability, and verification R, A
| 2.1.7 |
| Provide, update, and maintain a Project Management Plan (PMP) as mutually agreed upon by the State and the Offeror that includes the following key components: |
Project initiation activities Issue tracking, escalation, and resolution Change request approval, management and tracking Deliverable/product review and approval and other acceptance criteria Risk management, identification, quantification of impact, monitoring, and mitigation plans Quality management Relationships to other IT or business efforts Status and other reporting activities Status reporting templates (including Deliverable status reports, issues, risks, plan vs. actual status, etc.)
R, A
| 2.1.8 |
| Provide and implement risk mitigation measures and contingency plans as high-priority risks are identified and monitored. |
| R, A |
| C, I |
| 2.1.9 |
| Provide the initial Project Team Training Plan to document State Project Team “boot camp” training requirements and the approach the Offeror will use to prepare the State Project Team for the Initial Design and Analysis phase (both Functional and Technical Teams) so that the State Project Team can gain an in depth understanding of the UIS application modules scheduled for implementation, introduction to configuration, table structures, technical terminology, etc. as mutually agreed upon by the State and the Offeror. |
| R, A |
| C, I |
| 2.1.10 |
| Provide a Communication Plan that shall be used to communicate with all Project stakeholders throughout the life of the Project, as mutually agreed upon by the State and the Offeror, including at a minimum the following activities: |
Communication with internal and external stakeholders Formal kickoffs of phases Communication of milestones Team-building exercises
R, A
| 2.1.11 |
| Provide Weekly Status Reviews, Issues Logs, and Progress Reports at the sub-team level (e.g., functional teams, technical team, and deployment team). |
| R, A |
| 2.1.12 |
| Provide Project Status Reports and conduct regularly scheduled status meetings reviewing Project progress, risk mitigation, issue resolution, Deliverable status, and next steps mutually agreed upon by the State and the Offeror. |
| R, A |
| 2.1.13 |
| Use documentation repository provided by the State to store, organize, track, control and disseminate all information using documentation standards and naming convention. |
| R, A |
| 2.1.14 |
| Communicate Project scope change process and procedures to State stakeholders. |
R, A
| 2.1.15 |
| Document impact analysis associated with proposed changes. |
| R, A |
| 2.1.16 |
| Provide training materials for “boot camp” training. |
| R, A |
| 2.1.17 |
| Provide State Project Team Training (“boot camp” training) to the Project Team and key SMEs to support the Initial Analysis and Design phase. |
| R, A |
| 2.1.18 |
| Provide a Work Breakdown Structure that maps major tasks for all phases of project |
| R, A |
Initial Analysis and Design
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Initial Analysis and Design Roles and Responsibilities
| # |
| Initial Analysis and Design |
Roles and Responsibilities
| Offeror |
| State |
| Offeror Response |
| Offeror Comments |
| 2.2.1 |
| Act as primary point of contact with stakeholders and offices to refine functional and technical requirements, including scheduling State staff for interviews and workshops. |
R, A
| 2.2.2 |
| Develop a detailed plan and schedule to conduct State interviews, group workshops, and surveys to refine, and prioritize detailed functional and technical requirements. |
| R, A |
| 2.2.3 |
| Conduct and document State interviews, group workshops, and surveys to refine, and prioritize detailed functional and technical requirements. |
| R, A |
| 2.2.4 |
| Provide periodic updates to refine, clarify and prioritize the detailed functional and technical requirements including “to-be” process flows, use cases, and business re-engineering opportunities. |
| R, A |
| 2.2.5 |
| Coordinate, schedule and communicate with all functional and technical SMEs for planning sessions. |
| R |
| A |
| 2.2.6 |
| Conduct and document functional and technical planning sessions to establish system(s) configuration. |
| R, A |
| C, I |
| 2.2.7 |
| Develop and document operational and technical requirements (technical as well as performance) around the current IT infrastructure (desktop, network, directories, and any dependent systems) to allow the State to perform any mitigations. |
| R, A |
| C, I |
| 2.2.8 |
| Provide a Technical Architecture Strategy (e.g., including application, database, network, infrastructure, system management, security, administration). |
| R, A |
| C, I |
| 2.2.9 |
| Conduct business process analysis and reengineering focused on the adoption of standard, best-practice business processes implicit within the proposed solution. |
| R, A |
| C, I |
| 2.2.10 |
| Analyze, validate and provide recommendations regarding any proposed enhancements to the application based on existing laws, policies, and other government regulations. |
| R, A |
| C, I |
| 2.2.11 |
| Assess whether the solution is compliant with State’s digital records retention policies. |
| R, A |
| C, I |
| 2.2.13 |
| Assess needs and develop the design for a Business Intelligence (BI)/Data Warehouse (DW) solution which addresses the State’s reporting requirements. |
| R, A |
| C, I |
| 2.2.14 |
| Provide BI/DW recommendations on an integrated versus federated implementation approach. |
| R, A |
| C, I |
| 2.2.15 |
| Provide the Configured Environment (pre-development and/or sandbox) required to support fit-gap activities. |
| R, A |
| 2.2.16 |
| Conduct and document assessments of detailed functional requirements and generate a fit-gap analysis, including affected systems recommendations and alternative design scenarios, etc. |
| R, A |
| C, I |
| 2.2.17 |
| Provide a State-wide UIS Implementation Strategy document which outlines the proposed approach for implementation, including timelines for deployment across all phases; and staffing plan for the Offeror and the State. |
| R, A |
| C, I |
| 2.2.18 |
| Provide the Initial System Design Document, including “to-be” business process flows, business process fit-gap analysis, updated and validated RTM (e.g., updated requirements fit-gap), RICEFW, data dictionary, and role-based access control. |
| R, A |
| 2.2.19 |
| Facilitate interviews, group workshops, etc. to obtain and gain consensus on design. |
| R, A |
| C, I |
| 2.2.20 |
| Define and document the system’s security and privacy features, including role-based access controls. |
| R, A |
| 2.2.21 |
| Provide a Business Process Re-engineering Plan to address the business process and organizational change management activities necessary to successfully implement the system in the State. |
| R, A |
| 2.2.22 |
| Provide and document a Business Process and Organizational Change Management Plan. |
| R, A |
| 2.2.23 |
| Perform and document an Organizational Readiness Assessment to identify opportunities and resistance to changes. |
| R, A |
Final Analysis and Design
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Final Analysis and Design Roles and Responsibilities
| # |
| Final Analysis and Design Roles and Responsibilities |
| Offeror |
| State |
| Offeror Response |
| Offeror Comments |
| 2.3.1 |
| Act as primary point of contact with stakeholders and offices to refine functional and technical requirements, including scheduling State staff for interviews and workshops. |
| C, I |
| R, A |
| 2.3.2 |
| Develop a plan and schedule to conduct State interviews, group workshops, and surveys to finalize the detailed functional and technical requirements. |
| R, A |
| 2.3.3 |
| Conduct and document State interviews, group workshops, and surveys to finalize the detailed functional and technical requirements. |
| R, A |
| 2.3.4 |
| Provide final updates to refine, clarify and prioritize the detailed functional and technical requirements including “to-be” process flows, use cases, and business re-engineering opportunities. |
| R, A |
| 2.3.5 |
| Coordinate, schedule and communicate with all functional and technical SMEs for planning sessions. |
| C, I |
| R, A |
| 2.3.6 |
| Conduct and document final functional and technical planning sessions to establish system(s) configuration. |
| R, A |
| C, I |
| 2.3.7 |
| Develop and document operational and technical requirements (technical as well as performance) around the current IT infrastructure (desktop, network, directories, and any dependent systems) to allow the State to perform any mitigations |
| R, A |
| 2.3.8 |
| Conduct business process analysis and reengineering focused on the adoption of standard, best-practice business processes implicit within the proposed solution. |
| R, A |
| 2.3.9 |
| Assess needs and design BI/DW solution which supports the analysis and report requirements defined in functional requirements. |
| R, A |
| C, I |
| 2.3.10 |
| Provide the Configured Environment (pre-development) required to support the final fit-gap activities. |
| R, A |
| 2.3.11 |
| Conduct and document assessments of detailed functional requirements and update the fit-gap analysis, including affected systems recommendations and alternative design scenarios, etc. |
| R, A |
| 2.3.12 |
| Conduct and document assessments of detailed technical infrastructure requirements and generate a fit-gap analysis, including network infrastructure, desktops, etc. |
| R, A |
| 2.3.13 |
| Ensure alignment of the system architecture with the State’s technical architecture preferences. |
| R, A |
| 2.3.14 |
| Perform and document system security planning and create a formal Security Plan in accordance with State’s security requirements and regulations. |
| R, A |
| 2.3.15 |
| Provide a Final System Design Document, including “to-be” business process flows, final business process fit-gap analysis and documentation, validated detailed functional and technical requirements, configuration settings, and requirements traceability matrix. |
| R, A |
| C, I |
| 2.3.16 |
| Facilitate interviews, group workshops, etc. to obtain and gain consensus on design. |
| R, A |
| C, I |
| 2.3.17 |
| Define and document the system’s security features. |
| R, A |
| C, I |
| 2.3.18 |
| Provide and apply appropriate business process and organizational change management templates and guidance while ensuring processes are in place for communication. |
| R, A |
| C, I |
| 2.3.19 |
| Lead business process and organizational change management activities. |
C, I
| 2.3.20 |
| Assess effectiveness of business process and organizational change management activities. |
| R, A |
| C, I |
| 2.3.21 |
| Provide a System Security Plan detailing the methodology and approach to the implementation of system security throughout the application. |
| R, A |
| C, I |
| 2.3.22 |
| Provide recommendations for ongoing business process and organizational change management activities. |
| R, A |
| C, I |
| 2.3.23 |
| Provide a Communication Plan detailing the approach to communicating to the entire organization the progress for the Project. |
| R, A |
| C, I |
| 2.3.26 |
| Implement business process and organizational change management recommendations. |
| C, I |
| R, A |
| 2.3.27 |
| Provide a Business Intelligence Plan detailing the approach to meeting the State reporting requirements. |
| R, A |
| 2.3.28 |
| Provide and document the System Landscape Architecture, Technical and Business Design Plan which includes hardware specifications (e.g., make, model, CPU, memory), server configuration, system diagrams, database design, SAN storage requirements, high availability design, and Disaster Recovery infrastructure and procedures, as it relates to current State IT Governance policies and standards. |
| R, A |
| 2.3.29 |
| Develop procedures for data replication and disaster recovery. |
| R, A |
| C, I |
| 2.3.30 |
| Provide a Data Conversion Strategy, including identification of the methodology and tools for the conversion of State legacy UI database information. |
| R, A |
| C, I |
| 2.3.31 |
| Implement Knowledge Transfer Plan for the State Project Team throughout all Phases as well as to State support personnel in support of developing a Level 1 and Level 2 support team prior to deployment. |
| R, A |
| C, I |
Configuration and Development
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Configuration and Development Roles and Responsibilities
| # |
| Configuration and Development Support Roles and Responsibilities |
| Offeror |
| State |
| Offeror Response |
| Offeror Comment |
| 2.4.1 |
| Establish and document the Detailed Functional and Technical Specifications, including requirements documents, use cases, and logical, data flow diagrams, architecture documents and physical data models inclusive of forms, reports, interfaces, conversions, enhancements, and workflow (FRICEW). |
| R, A |
| 2.4.2 |
| Perform all necessary technical design, configuration, testing, or scripting, of systems as required to provide and implement the functional and technical requirements. |
| R, A |
| C, I |
| 2.4.3 |
| Perform all necessary technical design, configuration, testing, or scripting, of temporary and permanent interfaces as required to provide and implement the functional and technical requirements. |
| R, A |
| C, I |
| 2.4.4 |
| Develop and document custom reports (as required to provide and implement functional and technical requirements). |
| R, A |
| C, I |
| 2.4.5 |
| Manage all configuration and interface development efforts using State-approved tools and methodologies adhering to defined standards and guidelines. |
| R, A |
| C, I |
| 2.4.6 |
| Provide configuration management tools. |
| R, A |
| C, I |
| 2.4.7 |
| Provide software development audit trail capabilities (e.g., developer ID, time). |
| R, A |
| C, I |
| 2.4.8 |
| Coordinate and communicate with State partners, owners of external systems, and/or third-party service providers regarding interfaces. |
| R, A |
| C, I |
| 2.4.9 |
| Work with State partners, owners of external systems, and/or third-party service providers to collect information required to develop and document a detailed interface design (both inbound and outbound) and approach according to State and Federal standards. |
| R, A |
| C, I |
| 2.4.10 |
| Conduct code reviews to ensure customized software and interfaces comply with coding standards to reduce defects. |
| R, A |
| 2.4.11 |
| Review and approve results of Offeror code reviews at the State’s discretion. |
| C, I |
| R, A |
| 2.4.12 |
| Define and document configuration management policies and procedures consistent with industry best practices. |
| R, A |
| C, I |
| 2.4.13 |
| Perform configuration management activities throughout the Project. |
| R, A |
| C, I |
| 2.4.14 |
| Tag and maintain an inventory of hardware and maintain an inventory of software. |
| R, A |
| 2.4.15 |
| Label all hardware to correspond with appropriate diagrams and include description of function. |
| R, A |
| 2.4.16 |
| Ensure software license compliance. |
| R, A |
| C, I |
| 2.4.17 |
| Schedule releases (e.g., configuration changes). |
| R, A |
| C, I |
| 2.4.18 |
| Manage documentation of changes to the underlying environment via use of library management version control and turnover management. |
| R, A |
| C, I |
| 2.4.19 |
| Review configuration management results. |
| C, I |
| R, A |
| 2.4.20 |
| Provide a Role-to-Position Mapping document to map the end-user roles to the positions within the organization. |
| R, A |
| C, I |
| 2.4.21 |
| Provide a Data Conversion Plan, including identification of roles and responsibilities for Offeror and State staff, and policies and procedures to ensure controls are in place in accordance with State rules and regulations. |
| R, A |
| C, I |
| 2.4.22 |
| Specify Extract, Transform, and Load (ETL) tools for data conversion. |
| R, A |
| 2.4.23 |
| Provide ETL tools. |
| R, A |
| 2.4.24 |
| Install and configure ETL tools (UIS environments). |
| R, A |
| 2.4.25 |
| Transfer knowledge of the ETL tools to DLIR IT resources. |
| R, A |
| C, I |
| 2.4.26 |
| Provide an Integration, Parallel, User Acceptance, Regression, Stress, and Security Test Plans that provides the detailed approach that shall be taken to fully test all components of the system including test control and approval processes, test participants, how testing will interface with the configuration management process, and test documentation expectations for the following test types: unit, integration, end-to-end, interface, user acceptance, data conversion, performance (including stress and volume), availability, disaster recovery (including failover), regression, and security. |
| R, A |
| C, I |
| 2.4.27 |
| Provide a Business Continuity Plan that describes the approach to perform disaster recovery activities and align with the Service-Level Agreements (SLAs) as mutually agreed upon by the State and the Offeror. |
| R, A |
| C, I |
| 2.4.29 |
| Provide an End-User Training Plan. |
| R, A |
| C, I |
| 2.4.30 |
| The Contractor must provide a data governance structure plan. |
| R, A |
| C, I |
| 2.4.31 |
| The Contractor must detail their plan/procedure for the handling of the disposal of records (electronic, paper) that contain PII data. |
| R, A |
| C, I |
| 2.4.32 |
| The Contractor must detail their plan/procedure for the handling of external requests for anything related to the State of Hawaii data |
| R, A |
| C, I |
| 2.4.33 |
| The Contractor must provide their Data Protection, or Data Loss Prevention (DLP) plan |
| R, A |
Testing and Training
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Testing and Training Roles and Responsibilities
| # |
| Testing and Training Roles and Responsibilities |
| Offeror |
| State |
| Offeror Response |
| Offeror Comment |
| 2.5.1 |
| Provide automated testing tools and procedures for testing including integration, UAT, end to end, regression, performance, stress, etc. |
| R, A |
| C, I |
| 2.5.2 |
| Document/create standards and procedures for the use of the tools that support all testing activities. |
| R, A |
| C, I |
| 2.5.3 |
| Install, configure, and implement the testing application software, hardware, data, desktops, etc. |
| R, A |
| C, I |
| 2.5.4 |
| Create Test Scripts, Test Cases, and Test Data, and perform all appropriate testing (e.g., unit, integration, end-to-end, interface, data conversion, performance (including stress and volume), regression, and security. Assist with user acceptance testing. |
| R, A |
| C, I |
| 2.5.5 |
| Support and Assist with all test phases. Provide guidance and input to Test Scripts, Test Cases, and Test Data. |
| R, A |
| C, I |
| 2.5.6 |
| Test the capability of failover to secondary DR site. |
| R, A |
| C, I |
| 2.5.7 |
| Test the capability to move back to primary data center after deployment on secondary DR data center. |
| R, A |
| C, I |
| 2.5.8 |
| Provide the Configured Hardware Environments (testing) to test and/or demonstrate the functionality has been satisfied. |
| R, A |
| C, I |
| 2.5.9 |
| Provide Configured Hardware Environments (testing) Documentation, including specification of hardware, network, storage, utilities, licensees, and other required infrastructure. |
| R, A |
| C, I |
| 2.5.10 |
| Provide and document test results in a Documented Successful Testing Results deliverable. |
| R, A |
| C, I |
| 2.5.11 |
| Validate the system for compliance with the Security Plan. |
| R, A |
| C, I |
| 2.5.12 |
| Manage the State functional, integration, user acceptance, and regression test environments and associated test data including creation and maintenance during the testing period. |
| R, A |
| C, I |
| 2.5.13 |
| Review testing results for compliance with policies, procedures, plans, and test criteria and metrics (e.g., defect rates, progress against schedule). |
R, A
| 2.5.14 |
| Coordinate the scheduling of user acceptance testing (e.g., gain user involvement, establish, and define acceptance criteria, set high-level test objectives, establish high-level test scenarios). |
| C, I |
| R, A |
| 2.5.15 |
| Facilitate and support user acceptance test as prescribed by the State, including: establishing adequate test environment based on user acceptance criteria; preparing data to support test scenarios within modified system as well as managing the relationship with all interfaced systems necessary to conduct test; troubleshooting; supporting users to progress through scenarios; simulating interfaces or working with integrated systems to conduct end-to-end tests; supporting batch processing; exercising functionality; converting production data, and reporting results. |
| R, A |
| C, I |
| 2.5.16 |
| Conduct user acceptance testing. |
| C, I |
| R, A |
| 2.5.17 |
| Use a Defect Tracking System (provided by the Offeror) for purposes of allowing the State to initiate, track, and report all testing defects (e.g., integration, end to end, and user acceptance testing). |
| R, A |
| 2.5.18 |
| Notify Offeror in the event the State notices a discrepancy between the State’s requirements and the requirements document or other Offeror Deliverables. |
R, A
| 2.5.19 |
| Correct defects found as a result of testing efforts. |
| R, A |
| 2.5.20 |
| Create data conversion extracts from legacy/existing data files in a format specified by the Data Conversion Plan. |
R, A
| 2.5.21 |
| Provide coding of automated data conversion extracts from legacy/existing data files, using techniques that are consistent with the development standards. |
| R, A |
| 2.5.22 |
| Extract legacy data for purposes of transformation and loading into new application files structures. |
| C, I |
| R, A |
| 2.5.23 |
| Transform and load cleansed legacy data. |
| R, A |
| 2.5.24 |
| Review the data and the data cleansing metrics as delineated in Data Conversion Plan, for data currently residing in State databases. |
| C, I |
| R, A |
| 2.5.25 |
| Perform data cleansing (cleansing of data that cannot be cleansed automatically) prior to provision to the Offeror for consumption into the future state UI system. |
| C, I |
| R, A |
| 2.5.26 |
| Coordinate and execute manual data loads if required. |
| R, A |
| 2.5.27 |
| Provide converted legacy data for transactional testing during integration, end to end, user acceptance, etc. test events. |
| R, A |
| 2.5.28 |
| Perform Data Conversion from existing system(s) to the new system, by electronic or manual methods and track data conversion status and notifications. |
| R, A |
| 2.5.29 |
| Provide tool for obfuscation of data (subject to approval by the State). |
| R, A |
| 2.5.30 |
| Provide tool for automated data reconciliation for all conversion-related data between legacy and new system (subject to approval by the State). |
| R, A |
| 2.5.31 |
| Provide knowledge transfer materials including dialogue scripts, for Level 1 support for the system. |
| R, A |
| 2.5.32 |
| Provide Training Curriculum Document, including the course outlines and schedules for end-user training. |
| R, A |
| 2.5.33 |
| Provide Enhanced Training Materials. |
| R, A |
| 2.5.34 |
| Provide Final Training Materials, including end-user documentation, standard templates, and online training, to support end-user training. |
| R, A |
| 2.5.35 |
| Tailor the standard training templates to incorporate State-specific business processes. |
| R, A |
| 2.5.36 |
| Conduct Enhanced Training for the system early and often. |
| R, A |
| C, I |
| 2.5.37 |
| Participate in Enhanced Training for the system. |
R, A
| 2.5.38 |
| Conduct in-person End-User Training for the system at all DLIR offices on all Hawaiian Islands. |
| R, A |
| 2.5.39 |
| Support end-user training for the system. The training leads will be those provided by the Offeror. |
| C, I |
| R, A |
| 2.5.40 |
| Participate in end-user training for the system. |
R, A
| 2.5.41 |
| Provide the Configured Environments (Training) to support training as defined in End-User Training Plan. |
| R, A |
| 2.4.42 |
| Provide Configured Environments (Training) Documentation, including specification of hardware, network, storage, utilities, licensees, and other required infrastructure. |
| R, A |
| 2.5.43 |
| Create and maintain the State training data as required by the State. |
| R, A |
| 2.5.44 |
| Provide detailed Technical Documentation including the technical and architectural documents, diagrams, and specifications. |
| R, A |
| 2.5.45 |
| Survey end-users following End-User Training for End-User training effectiveness reports. |
| C, I |
| R, A |
| 2.5.47 |
| Provide the End-User Survey and develop End-User Training Effectiveness Reports. |
| R, A |
| 2.5.48 |
| Provide external video training content for external users (employers and claimants) |
| R, A |
| 2.5.49 |
| Build and provide FAQs for all components and functions of the system. |
| R, A |
| 2.5.50 |
| Build and provide Job Aids for all components and functions of the system |
| R, A |
Data Conversion Roles and Responsibilities
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Data Conversion
| # |
| Data Conversion Roles and Responsibilities |
| Offeror |
| State |
| Offeror Response |
| Offeror Comment |
| 2.6.1 |
| Inventory the current state Hawaii UI system and supporting components to understand both the scope and details they will be working with as they transition the data into the Proposed UI system. |
| R, A |
| C, I |
| 2.6.2 |
| Review the data and data types being converted. It’s important to understand information such as: |
· The amount, type, and quality of data
· The original and target sources and formats
· Any cross-reference and transformation complexities
| 2.6.3 |
| Evaluate the experience of the Offeror project team to determine their ability to successfully perform the data conversion. This includes ensuring that all of the Offeror resources have the appropriate skill sets to complete this activity in an efficient and accurate manner. |
| R, A |
| 2.6.4 |
| Identify the criticality of the data and associated consumption sequence. This may impact the approach taken to convert the data as well as the amount and type of resources required to successfully perform the effort. |
| R, A |
| 2.6.5 |
| Ensure the controls are in place for the security of the data. |
| R, A |
| C, I |
| 2.6.6 |
| Determine how the data conversion will be performed (environments, timing, frequency, and reconciliation). This requires approval by DLIR. |
| R, A |
| C, I |
| 2.6.7 |
| Perform a high-level mapping to determine which data elements in the existing system will be converted/migrated to the new system. Decide which data will be transferred, converted, which is redundant, etc. |
| R, A |
| C, I |
| 2.6.8 |
| Develop business rules that outline how items will be handled. Items such as blank fields, new codes, inappropriate entries, etc. |
| R, A |
| C, I |
| 2.6.9 |
| Develop and deliver outbound extract specification documents to DLIR. |
| R, A |
| C, I |
| 2.6.10 |
| Develop conversion consumption scripts and programs. Conversion scripts and programs are used for extracting data from the source, transforming the data as needed, and loading the data into the target UI system. |
| R, A |
| 2.6.11 |
| Create a master conversion specification document that maps out exactly how the converted data will look. |
| R, A |
| C, I |
| 2.6.12 |
| Other conversion activities include items such as communication, education, data normalization, quality assurance, and validation of data accuracy and completeness. Identify target application dependencies. |
| R, A |
| C, I |
| 2.6.13 |
| Generate a backup of all target data within the proposed system prior to any manipulation or conversion activity. This backup represents the system baseline. If needed, this backup can be used to restore the system. |
| R, A |
| 2.6.14 |
| Extract the data in the provided format from the legacy UI system. |
| C, I |
| R, A |
| 2.6.15 |
| Perform test conversions of a sample of existing data and adjust as needed. This converted data should reconcile and be fully functional within the target system (this must include normalization, transformations, crosswalks, etc.). |
| R, A |
| C, I |
| 2.6.16 |
| Verify the conversion consumption results and its usability within the target system. |
| R, A |
| C, I |
| 2.6.17 |
| Report out to DLIR the conversion results as they occur and agreed upon timeline. This report must include the reconciliation results, target system usability, timeline, and timeline. |
| R, A |
| 2.6.18 |
| Provide DLIR with a schedule for all mock “dress rehearsal” conversions along with estimated timelines for each conversion data set. The schedule must include but not be limited to: |
· Target environment (dev, conv, test, uat, sandbox, etc.)
· Data volumes
· Special considerations
| 2.6.19 |
| Review and approve Offeror provided mock conversion iterations plan. |
| C, I |
| R, A |
| 2.6.20 |
| Perform mock conversion as approved and in accordance with the project timeline. |
| R, A |
| C, I |
| 2.6.21 |
| Report out to DLIR the mock conversion results as they occur. This report must include the reconciliation results, target system usability, timeline, and timeline. |
| R, A |
| C, I |
| 2.6.22 |
| Review and approve the mock conversion report and associated reconciliation results, usability evidence, and testing results. |
| C, I |
| R, A |
| 2.6.23 |
| Review and approve all conversion status reports before going forward. |
| C, I |
| R, A |
Supplemental Staffing (Implementation)
This section provides the Offeror the ability to let DLIR know if any additional implementation supplemental resources can be made available in the event that DLIR should need additional implementation resources outside of those planned internally, along with those planned within the Offeror provided Implementation Staffing Plan.
Offerors shall respond to the “Lead Time (Days)” column which represents the estimated lead time the Offeror would need before the “if needed” resource would be made available to DLIR for Implementation. Additionally, the Offeror would respond to the “Hourly Rate” column in the table below. A blank in “Lead Time (Days)” without providing a “Offeror Comment” may cause the Offer to be rejected.
Note: This if needed by DLIR Supplemental Staff section is separate from the Offeror provided Implementation Staffing Plan.
Implementation Supplemental Staffing (If Needed by DLIR) Roles
| # |
| Supplemental Staffing Roles |
(If Needed by DLIR) Lead Time (Days)
| Offeror Comment |
| Hourly Rate |
| 2.7.6 |
| SME – Reporting & Analytics |
| 2.7.8 |
| SME – Financial Research & Analysis |
| 2.7.10 |
| Conversion Lead (Outbound extracts) |
Deployment and Go-Live Support
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Deployment and Go-Live Support Roles and Responsibilities
| # |
| Deployment and Go-Live Support Roles and Responsibilities |
| Offeror |
| State |
| Offeror Response |
| Offeror Comment |
| 2.8.1 |
| Provide initial and Final Detailed Deployment Plan. |
| R, A |
| C, I |
| 2.8.2 |
| Provide the Configured Environments (production and disaster recovery). |
| R, A |
| C, I |
| 2.8.3 |
| Provide Configured Environments (production and disaster recovery) Documentation, including specification of hardware, network, storage, utilities, licensees, and other required infrastructure. |
| R, A |
| C, I |
| 2.8.4 |
| Provide Go/No-go Documentation, including the Production Cutover Plan and the Go-Live Checklist). |
| R, A |
| C, I |
| 2.8.5 |
| Conduct Go/No-go Meeting. |
| R, A |
| C, I |
| 2.8.6 |
| Perform deployment and support activities with parties as directed by the State Project Manager. |
| R, A |
| C, I |
| 2.8.7 |
| Provide System and User Documentation, including functional, technical, and architectural specifications, operational documentation (e.g., batch schedule, runtime procedures). |
| R, A |
| C, I |
| 2.8.8 |
| Provide a Production Support Plan to cover the Post Go-Live Support prior to Warranty, the Warranty Period, and the M&O Support period. The plan should include the proposed organizational structure, roles and responsibilities and estimated level of effort for the Offeror and the State. |
| R, A |
| 2.8.9 |
| Assist with a Decommissioning and Archiving Plan for legacy data and systems. |
R, A
| 2.8.10 |
| Provide recommended operations and administration procedures related to the deployment. |
| R, A |
| C, I |
| 2.8.11 |
| Approve production deployment go/no-go decisions. |
| C, I |
| R, A |
| 2.8.12 |
| Deploy application into production. |
| R, A |
| 2.8.13 |
| Track deployment status and notification. |
| R, A |
| C, I |
| 2.8.14 |
| Escalate and resolve issues with Offeror post-production support team. |
| C, I |
| R, A |
| 2.8.15 |
| Provide 12 weeks of post go-live deployment support prior to final acceptance. |
| R, A |
| C, I |
| 2.8.16 |
| Provide Successful Deployment Documented deliverable. |
| R, A |
| C, I |
| 2.8.17 |
| Provide the configuration and customization documentation and readable source code and object (executable) code for the system in the configuration management system. |
| R, A |
| C, I |
| 2.8.18 |
| Perform Phase Closeout including system tuning activities, assessment of knowledge transfer tasks, transfer Project artifacts to Project repository, lessons learned document, update design documents to the State as appropriate . |
| R, A |
| C, I |
| 2.8.19 |
| Develop help desk scripts (level 1 and 2 help desk). |
| R, A |
| C, I |
| 2.8.20 |
| Maintain in-house DLIR help desk scripts. |
R, A
| 2.8.21 |
| Provide Level 1 Help Desk—simple (with coordination of user support activities including “how to” support) and user account and password administration. |
R, A
| 2.8.22 |
| Provide Level 2 Help Desk |
| R, A |
| 2.8.23 |
| Provide Level 3 Help Desk for the system-related incidents and problems. |
| R, A |
| 2.8.24 |
| Assist the State in the development of support organization. |
| R, A |
| 2.8.25 |
| Provide support organization to advise and assist business end-users and staff in the use of systems and State specific policies. |
R, A
| 2.8.26 |
| Respond to escalated trouble ticket items in accordance with established procedures. |
| R, A |
| 2.8.27 |
| Establish priority of trouble ticket items / service requests. |
R, A
| 2.8.28 |
| Maintain “end state” system architecture documentation. |
| R, A |
| 2.8.29 |
| Provide maintenance and repair policies and procedures. |
| R, A |
| C, I |
| 2.8.30 |
| Provide technical and functional support to the State IT staff and other groups as directed by the State. |
| R, A |
| C, I |
| 2.8.31 |
| Provide Organizational Change Management Effectiveness Assessment Report. |
| R, A |
| C, I |
| 2.8.32 |
| Perform diagnostics on software and services. |
| R, A |
| 2.8.33 |
| Provide Final Acceptance Documented deliverable that includes a checklist of all Project closeout activities and validates that support has been provided for the duration of the Minimum Support Period (see below). |
R, A I
Final Acceptance
Go-Live and Support will occur for a specified period of time, as detailed in the tables below and prior to Final Acceptance. The purpose is to stabilize the system after each Phase and minimize the impact of any early system issues. The Offeror Go-Live Support team will closely monitor the newly deployed system and user activity; assign appropriate resources to resolve issues; rapidly detect and escalate issues as required; and quickly resolve and communicate resolution. Four levels of priority will be assigned to issues identified during the Go-Live Support period: Critical, High, Medium, and Low (see Attachment A - Service Level Agreements).
The Offeror is responsible for application availability and usability, including reports, interfaces, and development. Prior to the end of the Go-Live Support period for each implementation Project and wave, the Offeror and the State will jointly assess the status of the implementation and review the status of outstanding issues and adherence to SLAs. The purpose of the assessment will be to provide written verification in the Final Acceptance Documented Deliverable that the UIS System operates as expected after each Project and wave implementation. Final Acceptance will be granted at the end of the Go-Live Support period and when 100% of the Critical and High issues have been resolved.
Warranty Services
Offerors shall respond “Yes” or “No” to each requirement in the table below. A “No” response without providing a comment may cause the Offer to be rejected.
Warranty Roles and Responsibilities
| # |
| Configuration and Development Support Roles and Responsibilities |
| Offeror |
| State |
| Offeror Response |
| Offeror Comment |
| 2.9.1 |
| Provide processes and procedures for tracking and reporting the status of all warranty services. |
| R, A |
| 2. 9.2 |
| Perform system fixes for problems that the Offeror was responsible for providing. |
| R, A |
| 2.9.3 |
| Perform data fixes for errors that the Offeror was responsible for, including but not limited to improperly converted files or tables. |
| R, A |
| 2.9.4 |
| Test the system to ensure that no regression errors are introduced. |
| R, A |
| 2.9.5 |
| Approve all warranty service fixes with formal sign-off. |
R, A
| 2.9.6 |
| Update all documentation and related files/Deliverables associated with Warranty Services. |
| R, A |
Warranty Services are the activities associated with repairing defects that are discovered within the Warranty Period of twelve (12) months of a system component or enhancement being accepted by the State in the production environment. Warranty Services include the applicable life cycle support activities necessary to repair errors/defects to enable programs and enhancements to perform in accordance with the documented specifications and documented operational functionality.
The Offeror shall repair the configuration and customized code provided by Offeror during the Warranty Period, at no charge to the State provided that:
I. The problem encountered occurs within twelve (12) months of the acceptance of such provided component.
II. The root cause analysis indicates the problem is in the system not meeting requirements where the Offeror has responsibility (e.g., a problem caused by configured or customized COTS software or hardware component not meeting requirements, a defect in the configuration or code created by the Offeror, a problem with the system not meeting SLAs).
Full correction of the system defect is to be completed by the Offeror unless otherwise approved by the State, and the corrected code shall be appropriately tested to verify that no regression errors are introduced.
The Offeror shall warrant against “version locking” due to customization of the system.
Services include updating all appropriate documentation. The Offeror shall provide monthly reports showing the amount of warranty work (i.e., number of defects and hours to correct).
It is the State’s policy to try to resolve all Warranty work controversies by mutual agreement without litigation. In appropriate circumstances, informal discussions between the State and the Offeror can aid in the resolution of differences by mutual agreement and are encouraged. If such informal discussions do not resolve the controversy, individuals who have not participated substantially in the matter in controversy may be brought in to conduct discussions if this is feasible.
Minimum List of Deliverables
The following Table 10 provides a listing of key proposed Deliverables that must be provided at a minimum. The Deliverables in the list below include the formal Deliverables that are required in the OF-5 Cost Proposal Form. However, there may be other work products that are part of the Project artifacts that are required for Project delivery but that are not formally tied to individual payments. Strategy Deliverables are considered Contract-wide Deliverables and should cover the entire State UIS Project while Plans will be delivered throughout the implementation. Strategy Deliverables should be reviewed and updated during the development of Plan Deliverables. Deliverables may be leveraged from one Project Phase to another by reviewing and updating, as applicable.
The Offeror shall add to the list provided below in alignment with its proposed methodology and work plan.
Proposed Implementation Services Deliverables
| Name of Deliverable |
| Deliverable Group |
| Project Schedule |
| Project Planning |
| Project Team Training Plan |
| Project Planning |
| Project Team Training |
| Project Planning |
| Communication Strategy |
| Project Planning |
| Configured Environments (sandbox and development) |
| Project Planning |
| Project Charter |
| Project Planning |
| Project Management Plan |
| Project Planning |
| Business Process Organizational Change Management Strategy |
| Project Planning |
| Initial System Design Document |
| Initial Analysis and Design |
| Requirements Traceability Matrix |
| Initial Analysis and Design |
| Technical Architecture Strategy |
| Initial Analysis and Design |
| UIS Implementation Strategy |
| Initial Analysis and Design |
| Business Process Re-engineering Plan |
| Initial Analysis and Design |
| Knowledge Transfer Strategy |
| Initial Analysis and Design |
| Business Process Organizational Change Management Plan |
| Initial Analysis and Design |
| System Landscape, Technical and Business Design Strategy |
| Initial Analysis and Design |
| Organizational Readiness Assessment |
| Initial Analysis and Design |
| End-User Training Strategy |
| Initial Analysis and Design |
| System Security Strategy |
| Initial Analysis and Design |
| Project Status Reports (including deliverable status reports, issues, risks, plan vs. actual status, etc.) |
| All Phases |
| Data Conversion Strategy |
| Final Analysis and Design |
| Final System Design Document |
| Final Analysis and Design |
| Knowledge Transfer Plans |
| Final Analysis and Design |
| Business Intelligence Plan |
| Final Analysis and Design |
| Communication Plan |
| Final Analysis and Design |
| Business Continuity Strategy |
| Final Analysis and Design |
| Detailed Functional and Technical Specifications, including requirements documents, use cases, and logical, data flow diagrams, architecture documents and physical data models inclusive of forms, reports, interfaces, conversions, enhancements, and workflow (RICEW) |
| Configuration and Development |
| Test Plans: Integration, Parallel, User Acceptance, Regression, Stress, Security, and End-to-End |
| Configuration and Development |
| Test Scripts, Test Cases and Test Data |
| Configuration and Development |
| Data Conversion Plan |
| Configuration and Development |
| Data Governance Structure Plan |
| Configuration and Development |
| Organizational Readiness Assessment |
| Configuration and Development |
| System Security Plan |
| Configuration and Development |
| Data Loss Prevention Plan |
| Configuration and Development |
| PII Data Handling Plan |
| Configuration and Development |
| External Requests Plan |
| Configuration and Development |
| Data Loss Prevention Plan |
| Configuration and Development |
| Role to Position Mapping |
| Configuration and Development |
| Business Continuity Plan |
| Configuration and Development |
| End-User Training Plan |
| Testing and Training |
| Training Curriculum Document |
| Testing and Training |
| Documented Successful Testing Results |
| Testing and Training |
| Enhanced Training Materials |
| Testing and Training |
| Final Training Materials |
| Testing and Training |
| Technical, System, and User Documentation (including technical and architectural specifications, etc.) |
| Testing and Training |
| End-User Training |
| Testing and Training |
| System and User Documentation |
| Deployment and Go-Live Support |
| Production Support Plan |
| Deployment and Go-Live Support |
| Go/No-go Meeting and Go/No-go Documentation |
| Deployment and Go-Live Support |
| Final Detailed Deployment Plan |
| Deployment and Go-Live Support |
| Organizational Change Management Effectiveness Assessment |
| Deployment and Go-Live Support |
| Phase Closeout (to include System Tuning, Knowledge Transfer Assessment, Project Artifacts in Repository, Lessons Learned, Update Blueprint, Impact Assessment, and Transition Support to COE and Shared Services, M&O Services Staff |
| Deployment and Go-Live Support |
| Successful Deployment Document (Final Migrated Data) |
| Deployment and Go-Live Support |
| Support Phase |
| Deployment and Go-Live Support |
image1.png