Appendix 1 – Proposal Forms Vendors shall complete each of the Tabs 1 – 10 and submit per the instructions provided in Section 6.1.3 of the RFP. Any Exhibits provided by the Vendors are to be inserted at the end of each applicable tab. Vendors are permitted to add rows/lines/pages up to 150 pages, inclusive of existing Appendix 1 language.

In addition to the information captured through the questions and tables in Appendix 1, Vendors are required to provide additional detail, diagrams, and/or images to help substantiate and support their response to each tab section.

DOC Offender Management System

Tab 1 – Software Solution

I. SUMMARY DESCRIPTION OF EACH FUNCTIONAL AREA

Vendors must provide a summary description of the capabilities for each functional area contained in the RFP, in narrative format (the entire Appendix 1 has a maximum page count of 150 pages, inclusive of the original Appendix 1 language). The purpose of this summary is so that the Agency has a high-level understanding of the proposed solution. The narrative should be written for an audience of the end-user community. Descriptions should be included for any products proposed by third parties to meet the capabilities described in the Functional and Technical Requirements in Appendix 2.

II. SOFTWARE DOCUMENTATION FEATURES AND FUNCTIONS

Vendors must provide a summary of their software documentation that describes the features and function of the proposed application software. Identify what makes your documentation intuitive and streamlined to the end user and technical user of the software.

III. PROPOSED SOFTWARE MODULES TABLE

Vendors must complete the table below. Proposed modules that are required to satisfy the requirements associated with the functional areas identified below cannot be proposed as complementary or optional.

Table 1-01: Proposed Functional Areas/Modules Proposed Software Information

Product Component/Suite (Name and Version of the Proposed Software Solution)

Time on Market

Release Date of Most Current Version

Next Major Release Date

Next Minor Release Date

Was the product proposed originally developed by your firm, or, was the product acquired from another developer/entity?

If the proposed product was acquired, what was the date of acquisition?

What is the future roadmap for the proposed product? Is there an end of sales or support date for the product?

Does your company have plans to release a differing product that offers the same or similar functionality in the next 5 – 10 years?

Licensing

Describe how the software is licensed (e.g., named user, concurrent users, enterprise/site, power user, subscription) and the options available for licensing.

How many licenses have been proposed?

Are the same licenses required for all users, or would some users have a different license type than other users?

How are new users added to the system? Are there incremental costs per user?

If an existing user separates from service at the Agency, can their license be re-assigned to a new staff member, or, must a license remain assigned to that staff member?

Deployment Model

Deployment Models Proposed to the Agency (Corresponding Appendix 3 Cost Worksheets shall be completed for each separate deployment model proposed)

Summary of Modules Proposed

*Successful integration should include only those instances where both the software and the client are in production environments.

IV. VALUE-ADD: OPTIONAL AND COMPLEMENTARY MODULES

What other system modules or products, not included in the scope of your proposal, would the Vendors recommend to be complementary (free of charge) or optional (pricing to be identified in Appendix 3 – Cost Proposal) to the Project Scope?

Table 1-02: Value-Add Optional and Complementary Modules

V. PARTNERSHIPS/THIRD-PARTY PRODUCT RELATIONSHIP

i. Vendors must fill out the table below for each Partnership/Third-Party software product proposed.

– Not applicable, no Partnership/Third-Party software proposed Table 1-03: Partnership and/or Third-Party Product Identification

ii. For each product proposed as a Partnership/Third-Party product, detail the options available to the Agency as it relates to contracting relationship between the Agency and the Partnership/Third Party.

iii. Vendors must provide the approach and responsibilities for managing the implementation and acceptance testing for each of the proposed Partnership/Third-Party products.

iv. Vendors shall indicate if the proposed approach utilizes a systems integrator or consulting firm as the third-party.

VI. General

i. Vendors to provide a comprehensive history statement of the firm, including any mergers, assignments, or other corporate changes during the past 10 years.

ii. Please describe your relevant experience working with Iowa entities (counties, municipalities, etc.).

iii. Please describe any relevant experience working with similarly situated State Agencies, including any unique factors that arise during the implementation process.

iv. Identify two recent project implementations that are most comparable to the Agency’s proposed implementation, and provide a project profile for each, including: scope of modules; project duration; any unique requirements or circumstances that were a part of, or came up during, the project; the legacy system migrated from; etc.

v. Describe implementation barriers or challenges experienced on prior projects of similar scope, size, or complexity. The response should explain how those experiences inform the Vendor’s proposed approach and the measures that will be implemented to reduce the likelihood or impact of similar challenges on this Project?

vi. What sets the product(s) and services that your firm proposes apart from competitors’ products and services? Why should the Agency select your firm to partner with?

vii. Vendors shall fully describe the integration/interface/data exchange capabilities of the proposed system, including available API’s, middleware, web services, etc.

viii. For available APIs, does the proposed pricing include access to the entire API library? What functionality is exposed in the systems’ APIs? Describe any tiers, rate limits or other throttling that could impact Iowa’s API use.

ix. Describe your proposed reporting features native to the system and how the Agency staff will be trained to develop and configure their own reports.

x. What strategic decisions or direction is your firm taking or making related to the product being proposed today?

xi. The core requirements identified in Appendix 2 represent the Agency’s expected functionality. Proposers must clearly identify, explain, and justify any exceptions or deviations from the core requirements. For each exception, include the impacted requirement(s), the reason for the exception, and any alternative approach or work-around proposed.

xii. The Vendor should provide a narrative that describes the proposed approach to State and federal compliance including meeting the requirements described in Section 2.4 of the RFP Specifications document.

Tab 2 – Project Schedule

I. PROJECT SCHEDULE

i. Vendor shall submit a proposed Project Schedule with the major milestones, activities, and timing of deliverables for the Scope of Work described in the RFP. In addition, the response should reflect Project predecessors, successors, and dependencies.

· The Agency anticipates that implementation activities would begin in Insert Date Here. The Agency would like to target Insert Date Here as a potential go-live date for all modules.

· Vendors to use the table below to provide the Project Schedule that matches the project phasing from Tab 3 and milestones within Appendix 3 – Cost Worksheet. The table contains sample content; Vendors may remove sample content and add rows to table as necessary to highlight key milestones in the Project Schedule.

Table 2-01: Project Timeline

II. PROJECT DELIVERABLES, MILESTONES, AND PAYMENT APPLICATIONS

i. Vendors to include a list of deliverables and milestones of the Project and should describe exactly how and what will be provided to meet the needs of the Agency.

ii. Vendors to submit their payment schedule, tied to the listed deliverables and milestones for review by the Agency, as an exhibit to Tab 3. This schedule shall be consistent with the terms provided in Appendix 3 of the RFP (Cost Worksheet) and should not include the dollar amounts for payments, but rather the events that would trigger payments. Notation should be made as to the payment structure for services (e.g., fixed fee, time, and materials).

III. PROJECT SCHEDULE QUESTIONS

Table 2-02: Project Schedule Questions Project Schedule Questions

1. Based on current obligations, what is the earliest you can begin implementation after contract signing?

2. What activities would the Vendors expect to occur within the first 60 days of contract signing?

3. How long does the typical implementation of the product being proposed take for an organization of similar size to the Agency? Is a Big Bang or phased approach recommended?

4. What special considerations are there related to the timing of go-live activities? Does it vary based on functionality?

Tab 3 – Project Approach and Implementation Methodology

I. PROJECT APPROACH

Vendors must provide a description of the proposed approach for providing the scope described in the RFP, including a comprehensive description of the proposed implementation methodology for the Project. The description should include how the Vendors have developed this methodology to both incorporate lessons learned from experiences as well as to meet the needs described in the RFP.

i. Based on information provided in this RFP and experience in working with other localities, what is the Vendors’ perspective on the most significant risks to this Project, and how do you plan to mitigate these risks?

ii. With what frequency will Vendors’ Project Team staff be on-site at the Agency during implementation? Will staff be on-site for full or partial weeks?

iii. Describe in detail the approach to developing interfaces/integrations/data exchanges. What is the division of responsibility between the Agency and Vendor project teams? What technical skills are required of the Agency staff for this work?

a. Describe your experience working with integration hubs within the public safety domain, including the types of systems integrated and the role your solution played.

b. Following go-live of the software, what is the role of the Vendors in supporting the ongoing maintenance of developed interfaces/integrations/data exchanges?

iv. Describe in detail the approach to configuration and setup activities. Will the Vendors team complete the majority of the configuration based upon information gathered from the Agency subject matter experts, or will the Agency be expected to perform much of the configuration?

II. DEPLOYMENT

Vendors must provide a detailed narrative description of how the implementation approach will vary between the deployment methods proposed (i.e., a Vendor-hosted and/or a subscription-based solution, etc.).

III. GO-LIVE AND ONGOING SUPPORT

Vendors must describe what level of pre- and post-go-live support is available under the proposed fee structure. If varying levels of support are available, this section of the RFP response should clarify these potential support services and highlight the level of support that has been proposed. Vendors shall use Appendix 3, Cost Proposal, to clearly identify the varying fees based on the varying levels of support that are available.

i. What are the standard hours that support is offered, and through what means (telephone, web ticket submission, etc.)?

ii. Are after hours and weekend support offered, and if so, is this part of the standard support offering or part of a different tier/offering?

iii. Describe the support that is offered to assist in potential situations where the Agency is unable to conduct certain mission-critical processes, such as processing intakes and releases, due to emergency situations.

iv. Is product support offered by Vendors, through the software developer/provider, or subcontracted?

v. Are there optional, “enhanced” support tiers or offerings above and beyond what has been proposed?

vi. How often are releases provided, how is advance notification provided to customers of upcoming releases, and what is the process to test each release?

vii. Would the Agency be able to test releases in a test environment prior to pushing updates to a live environment?

viii. Does the system have the ability to roll back updates should challenges or bugs be encountered? If so, describe the process.

ix. Describe how often major and minor software updates are provided, as well as the level of the Agency resources required for a major update and the level of resources required for a minor update.

x. Please describe the major/minor upgrade process that is required if the solution requires a client-based installation.

xi. Are there future costs associated with upgrade processes? For example, costs associated with purchasing licensing for upgrades, professional services costs associated with implementing upgrades, etc.? Vendors to describe the frequency of upgrades and any price ranges for anticipated upgrades.

xii. How are upgrades tracked and validated to ensure all updates released from the start of implementation are applied consistently throughout the implementation and are fully up to date by go-live?

xiii. What is the role of the Agency in providing ongoing support and maintenance of the system proposed? How many FTE are typically required to support the system on the client-side, and what tasks are entailed?

xiv. What organizational change management (OCM) resources will be made available during implementational to support users during the transition?

xv. Do you offer a warranty with the system? Vendors to describe the details of the warranty.

IV. STATUS REPORTING

Vendors to detail their approach to providing status reports throughout the course of the Project. This section should include an example of the recurring status report and identify the expected delivery mechanism that will be used to provide the report to the Agency as an exhibit to Tab 3. Table 3-03 includes information on Weekly Reporting (D11) and Monthly Reporting (D12).

V. RESOURCE HOURS

Vendors shall include the proposed resource levels for the Agency Implementation Project Team and their project teams by completing Attachment 3. NOTE: During contract negotiations, the Agency will require the preferred Vendor to submit a comprehensive RACI chart that clearly defines roles and responsibilities for the full work breakdown structure (WBS) of the project. The RACI chart must cover all project phases, milestones, and deliverables, and identify responsibilities for the Vendor, the Agency, and any subcontractors. The RACI chart must clearly define responsible, accountable, consulted, and informed parties for each activity and will be used as a foundational governance and project management artifact throughout implementation.

Vendors shall include the anticipated resource hour levels for the Agency Implementation Project Team based on typical project role by completing the tables below. Any comments related to the anticipated hours, and any phase-specific involvement, should be noted in the Additional Vendor Comments column.

Table 3-01: Anticipated Hours by Project Role Anticipated Hours by Project Role

Agency Project Role (e.g., Project Sponsor, Project Manager, Migration Lead)

Executive Sponsor

Steering Committee

Project Manager

Project Management Team

Functional Area Lead(s) – Assuming one lead per tab of Appendix 2

Subject Matter Expert(s) – Note: one SME may serve as SME on two or more modules/functional areas

Integration Lead

Data Migration Lead

System Administrator

Reporting Lead

Organizational Change Management Lead

Training Lead

Other Vendor-Defined Roles (list below)

Vendors to provide their overall estimated split/division of the work effort as shared between the Agency and the Vendor teams (example: the Agency owns 20% of the work effort, and the Vendors own 80% of the work effort) along with any narrative to support this estimate.

Table 3-02: Anticipated Work Effort Division Anticipated Work Effort Division

Estimated number of individuals required for Project Team

Approximate Percentage of Work Effort Owned

General Comments

VI. IMPLEMENTATION PLAN

Vendors must provide their overall objectives and approach to the Agency’s implementation. This plan must align with project phasing identified in Table 4-01: Project Team Resource Hours and must align with milestone pricing provided in Appendix 3 – Cost Proposal. Discuss timing as being chronological, in parallel, etc., for all of the modules proposed.

VII. Project Management Deliverables Vendors may adjust the listed project management deliverables as necessary based on their proposed approach. Any exceptions, modifications, or deviations from the identified deliverables must be clearly noted and accompanied by an explanation describing the rationale for the change. Vendors are also encouraged to propose additional deliverables they believe would add value or support successful project execution by adding rows to the table as needed.

Table 3-03: Project Management Deliverables Project Management Deliverable Requirements

· Project Management Approach

· Staffing Management Plan

· Scope Management Plan

· Schedule Management Plan

· Requirements Management Plan

· Change Management Plan

· Risk and Issue Management Plan

· Quality Management Plan

· Communications Management Plan

· Installation Plan – The Vendor shall collaborate with the State to define required environments, then provision them.

· System Architecture Document – Shall describe the technical approach to developing the system, including a high-level architectural approach and the anticipated technologies, hardware, operating software, programming aids, application programs, third-party products, and integration points. Elements of the technical approach can be modified prior to completion of the Technical System Design Document.

· Requirements Management Plan – The Vendor shall document how the it will review and validate existing requirements, refine existing requirements, document new requirements, and adhere to industry standards for requirements management.

· Technical System Design Document – The Vendor shall summarize how it will configure, customize, and develop the system in accordance with the Agency’s requirements.

· Configuration Plan – The Vendor shall develop a plan that describes how configuration changes will occur for the proposed solution, including which are to be completed by State resources, and which the Vendor will complete. This Plan is an output of the Gap Analysis work sessions.

· Customization Plan – The Vendor shall develop a plan that describes how it will develop custom Offender Management System (OMS) components to accommodate the unique needs of the State as defined in the Contract, as resulting from the Gap Analysis work sessions.

· Interface Design and Development Plan – The Vendor shall describe system interfaces with other systems in an Interface Control Document (ICD). The Document shall describe system interfaces with other systems and specify the interactions between systems, including data exchange, communication protocols, and interface standards, while clearly defining system boundaries and responsibilities. The document must detail data formats, communication methods, error handling, security protocols, and performance requirements, ensuring that the interfaces operate seamlessly. Additionally, the document must include version control to track changes and updates, making it an essential tool for facilitating integration and preventing compatibility issues. Additionally, the document must include version control to track changes and updates, making it an essential tool for facilitating integration and preventing compatibility issues.

· System Environment Document - The Vendor must outline the processes and practices for managing and maintaining the various environments required for the system, including development, testing, staging, and production. The plan shall ensure that each environment is appropriately configured, monitored, and maintained to support system operations and project activities effectively.

· A data management strategy that supports integration, optimization, quality, stewardship, standards, security, and governance of data.

· Description of appropriate skill sets, processes, technologies/tools, and any naming conventions followed.

· Approach to migration, cleansing, and migration.

· Approach to risk management for data migration effort.

· Approach for testing migrated data.

· Approach to reporting the number of records successfully migrated vs. errors or exceptions.

· Approach for cleansing data to prepare it for loading to the proposed solution that is refined as necessary.

· Approach to resolving data migration errors and issues.

· Tasks, timelines, and responsible parties for all migration tasks.

· Entrance and exit criteria for each phase of the effort.

· Unit testing

· Integration testing

· System testing

· Data migration testing

· Interface testing

· Usability/Accessibility, ADA 508 testing

· Performance load/stress testing, including testing to the point of system failure

· Security testing (role-based, penetration, and vulnerability)

· Disaster recovery testing

· Regression testing

· State regression testing

· User Acceptance Testing (UAT), including support of UAT activities for users as defined by the Agency

· Testing, including testing of system components that affect external system users, such as web portals, web-based software, and data entry by other Vendors; testing is a part of the operational readiness testing period

· Operational readiness testing and implementation, including disaster recovery

· Data Migration Testing

· Usability/Accessibility

· Documentation of a testing approach that includes:

· Roles and responsibilities of all entities involved in testing

· Orientation and kickoff plan

· Test techniques and methods

· Test standards, including compliance with CJIS test requirements

· Test phases

· Description of the planned test environments

· Types of automated testing tools depending on type of testing (different automated testing tools may be used for load/stress, unit, system performance and regression testing).

· Pre-testing validation of functional requirements

· Test preparations, including at a minimum:

· Test environment preparation plan.

· Security and privacy requirements.

· Testing location.

· Unique tests by test identifier and a brief description of each test scenario.

· Hardware preparation plan.

· Software preparation plan.

· Test data, including use of sanitized test data.

· Training Materials – for user training that will be used during UAT to verify the accuracy, comprehensiveness, understandability, and usability of the materials. The materials shall include visuals, handouts, workbooks, manuals, computerized display (videos), quick reference guides, frequently asked questions (FAQ) guides, demonstrations, and online help. The Vendor must update materials after UAT in response to Agency feedback and must also modify the materials as needed to support changes during go-live.

· Frequently asked questions (FAQ) guides, demonstrations, and online help. The Vendor must update materials after UAT in response to Agency feedback and must also modify the materials as needed to support changes during go-live.

· Other pre-test preparations (e.g., description of other pre-test personnel actions, preparations, or procedures necessary to perform UAT).

· Schedule of Vendor personnel to support user testing.

· Test descriptions to simulate workflow and validate that the system meets functional requirements. Test descriptions must include:

· Unique identifier for each test case

· Prerequisite conditions

· Test inputs/outputs

· Expected test results/Acceptance criteria

· Criteria for evaluating results

· Testing procedure (step-by-step)

· Assumptions and constraints

· Error reporting and remediation plan

· System documentation update plan

· Traceability from each test case to the detailed requirement it addresses and mapped back to the RTM; if a test case addresses multiple requirements, then traceability from each set of test procedure steps to the requirement(s) is addressed.

· A summary of the tools and environments required for UAT to ensure that the test environment is ready for use in UAT, including:

· Verification that the test environment is populated with the latest version of code and contains all components the production environment requires, including copies of all software and database tables.

· Connection of UAT tools and the environment to the Agency’s network, appropriately configured, to adequately emulate production system use.

· Inclusion of applicable third-party and test partner files in order to adequately test system-to-system interfaces.

· Acceptance Criteria shall include, but is not limited to: no critical or urgent defects in code released to production and production releases will not be promoted if more than 5% of requirements have an open defect.

· Align with the Agency’s requirements.

· Describe the Vendor’s plan to protect the system and maintain critical business processes in the event of natural disasters, hardware and software failures, human error, or other contingencies that could interrupt services.

· Address recovery of business functions, human resources, and technology infrastructure associated with the system.

· Documentation of Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs).

· Steps required for troubleshooting, replacing, reconfiguring, and restoring the System hardware, software, and infrastructure.

· Processes utilized to verify the health and accuracy of Agency system backups.

· System and data backup, retention, and restoration processes.

· Testing and training procedures for the Business Continuity and Disaster Recovery Plan.

· Connection to incident response policy and plans.

· A complete set of updated and current output from the Project Work Plan.

· A description of the overall completion status of the project including schedule variations that report the earned value of the work completed, the planned value of the work completed, and the variance.

· Planned tasks and activities for the week.

· Deliverable status, with percentage of completion and time ahead or behind schedule for particular tasks.

· Identification of any staffing issues or changes.

· An updated status on all issues and/or being monitored.

· An updated status on all Service Level Agreements (SLAs) being monitored.

A weekly project status meeting shall take place in conjunction with the issuance of the weekly project status report.

· A complete set of updated and current output from the Project Work Plan.

· A description of the overall completion status of the project including schedule variations that report the earned value of the work completed, the planned value of the work completed, and the variance.

· Completed activities during the reporting period and upcoming tasks for the month.

· Deliverable status, with percentage of completion and time ahead or behind schedule for particular tasks.

· Identification of any staffing issues or changes.

· An updated status on all issues and/or being monitored.

· An updated status on all SLA being monitored.

A monthly project status meeting shall take place in conjunction with the issuance of the monthly project status report.

· All critical tasks that are required for cutover

· Description of final data migration activities

· Description of migration of configuration and customization items to the production environment

· Final testing and validation of the solution in production, including security testing

· The rollback strategy

· Communication and Vendor support procedures

· Vendor and State roles and responsibilities during the go-live process

· Operational Readiness Checklist(s) that defines, in advance, the go/no-go decision, and all aspects of Vendor, solution, and State readiness

· Post-cutover monitoring

· The on-site and off-site user support provided by the Vendor and the State for the phase

· Solution acceptance procedures

· Post-implementation production deployment process and activities

· Time frames for response and resolution for critical and urgent issues immediately post-go-live.

Table 3-04: Security Deliverable Requirements Security Requirements

The SSP must be approved before any State data is transferred or entered into the solution. The State must approve all revisions of the SSP.

· The system must be compliant with Statement on Standards for Attestation Engagements (SSAE-18) SOC 2 Type 2 and has Federal Risk and Authorization Management Program (FedRAMP) Certification, FedRAMP Risk Assessment that indicates compliance, or has a documented NIST 800-53 rev 4 at a “moderate” system risk assessment designation. The system shall comply with the CJIS Security Policy v.6.0 and remain compliant with future versions of this policy;

· The solution must adhere to industry‑recognized architecture best practices and will be subject to review by the Architecture Review Board;

· Explicitly defines the authorization boundary for the system;

· Describes the operational context of the information system in terms of mission and business processes;

· Provides the security categorization of the information system, as established by the State, including supporting rationale;

· Describes the operational environment for the informational system and relationships with or connection to other information systems;

· Provides an overview of the security requirements for the system;

· Identifies any relevant overlays, if applicable;

· Identifies any specific statutory and/or regulatory requirements (above and beyond the requirements stated in the current version of NIST 800-53 rev 4 at a “moderate” system risk assessment designation), if applicable;

· Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions;

· Is accepted by the authorizing official or designated representative prior to plan implementation;

· Is distributed to appropriate personnel;

· Is reviewed and updated, at least annually, or whenever changes to the information system/environment of operation occur; and

· Is protected from unauthorized disclosure and modification.

· Describes in detail the process and plans to update the application to stay current with platforms and infrastructure.

· Describes in detail the process to maintain and update security documents to reflect new requirements from federal partners.

The Vendor shall provide a mitigation plan for all reported deficiencies. Major and critical deficiencies must be corrected within forty (40) calendar days of the report submission to the State.

· Use of personally identifiable information (PII) and a description of the types of data that will be collected

· Sources of PII, populations, and transfer and disclosure mechanisms

· Legal environment (legal authorities and state privacy laws)

· Details about the entities with which the collected information will be shared

· Privacy and security standards for its business partners and other third parties and the agreements that bind these entities

· Incident handling procedures

· Privacy and/or security awareness programs and materials for its workforce

Table 3-05: Operations and Maintenance Deliverable Requirements Operations and Maintenance / SLA Deliverable Requirements

· Architecture/hosting operations.

· Monitoring daily operations performance.

· Performing routine maintenance.

· Maintaining user documentation.

· Online help approach and documentation, as appropriate.

· Configuration and change management.

· Approach to enhancements and other new requirements.

· Maintaining system documentation.

· Maintaining training documentation.

· Reporting status against relevant service level agreements (SLA)s.

· Schedule of major and minor releases.

· Processes and procedures needed for day-to-day system operations, including:

· System troubleshooting and system tuning procedures and features.

· Processes and procedures for implementing common types of system enhancements (e.g., adding a workflow, building a new notice template, changing the valid values for a lookup, adding document types, and changing database objects).

· Software management functions, such as building code and code management.

· System interface processing, including API documentation and data exchanges with other systems.

· Online and batch processing procedures.

· System backup and recovery procedures.

· Security procedures, scans, logs, and automated security tools.

· Setting and changing system password and user ID.

· Managing user permissions and roles.

· System processing procedures.

· System menu structures and system command mode operations.

· Job scheduling.

· Job cycles (daily, weekly, monthly, quarterly, annually, and special).

· Database maintenance and performance optimization management.

· Log management.

· Third-party software upgrades.

· Error recording, reporting, and troubleshooting procedures.

· The process for maintaining and updating security documents to reflect new requirements from federal partners.

· The process to maintain the software at a release level no older than one release prior to the current production release.

· Batch job standards and online technical support standards

· Tasks necessary to establish the technical support team for equipment and data communications problem solving

· Vendor’s help desk management plan, including coordination, ticket and incident management, and reporting system

· Necessary tools to capture and report on SLAs and facilitate tracing/observability of the health of the system

· Security management plan, with a comprehensive overview of the approach to system and data security (specifying the standards and methodology for securing access to the system, the software, and the data)

· Status of SLAs and performance standards

· Status of operational activities

· Help desk reporting

· Status of tasks, staff assignments, and schedule of work for the upcoming month

· Status of the work underway

· List of tasks completed in the prior month

· List of system operation problems

· Approach to system transition

· Resource requirements, roles, and responsibilities

· Phases,…