Att F - Technical Proposal AFIS Modernization.docx
DOCX document 67 KB Posted
- Attached to
- Automated Fingerprint Identification SystemBid Documents State and local contract opportunity
- Solicitation number
- 27-85295
- Issued by
- Marion County, Indiana
About this file
This is a Technical Proposal attachment for RFP #27-85295, a solicitation issued by the State of Indiana for AFIS (Automated Fingerprint Identification System) Modernization. The RFP invites organizations to compete in a formal evaluation process to modernize Indiana's AFIS infrastructure. Respondents must provide comprehensive technical proposals addressing minimum requirements including workflow coverage for NIST Tenprint, Non-NIST Tenprint, Criminal Arrest Events, applicant workflows, latent workflows, and optional mobile two-finger search capabilities. The solution must maintain all existing AFIS interfaces with criminal history, FBI NGI, and multi-jurisdictional MBIS connections while supporting uninterrupted statewide operations during migration. Key requirements include scalability from approximately 27 TB at implementation to 35 TB within five years, enhanced data validation, improved exception handling, strengthened system monitoring, and support for legacy and new reporting capabilities throughout the contract term.
Respondents must demonstrate comparable project experience, maintenance and operational support expertise, organizational change management capabilities, CJIS/CJI and AFIS domain experience, and large-scale biometric migration experience with datasets of 15 million items and 25-30 TB. The proposal must include detailed descriptions of the proposed solution architecture, whether commercial off-the-shelf or transfer-based, along with specific mapping of out-of-the-box capabilities versus configuration and customization requirements. Respondents must address system development life cycle methodology, comprehensive testing strategies including automated and user acceptance testing, data migration and conversion approaches, security compliance with Indiana Information Security Framework standards, WCAG 2.1 AA accessibility requirements, and adherence to CJIS security provisions. The proposal must confirm commitment to 99.9% system availability, defined incident response service levels for Priority 1-4 incidents, and acceptance of liquidated damages frameworks for missed milestones and SLA violations. Complete staffing plans with vital personnel resumes, subcontractor roles, training approaches, post-deployment warranty obligations, and contract transition and turnover procedures must be included.
View the file
Other files for this state and local contract opportunity
Show all 29
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
RFP # 27-85295 – ISP AFIS Modernization Attachment F – Technical Proposal
Respondent:
Instructions:
Request for Proposal (RFP) 27-85295 is a solicitation by the State of Indiana in which organizations are invited to compete for contract amongst other respondents in a formal evaluation process. The evaluation of a proposal can only be based upon the information provided by the Respondent in its proposal submission. Therefore, a competitive proposal shall thoroughly answer the questions listed. The Respondent is expected to provide the complete details of its proposed operations, processes, and staffing for the AFIS Statement of Work detailed in the RFP document and supplemental attachments.
Please review the requirements outlined in AFIS Statement of Work carefully. For all areas in which subcontractors will be performing a portion of the work, clearly describe their roles and responsibilities, related qualifications and experience, and how you will maintain oversight of the subcontractors’ activities.
Respondents must organize their proposal in the exact order of questions provided in this document followed by their answers. A completed Technical Proposal is a requirement for proposal submission. Failure to complete and submit this form may impact your proposal’s responsiveness.
1. Minimum Requirements (AFIS Statement of Work, §II, §III.b–c)
All workflow coverage, interface compatibility, and operational performance commitments in this proposal directly correspond to the requirements in SOW §III.b–c and the workflow descriptions in SOW Background.
The Respondent shall describe how the proposed solution meets all future‑state functions and workflows defined in SOW §III.b (Functional and Technical Requirements) and §III.c (Desired Future State). The solution must support all workflows documented in SOW §II (Current State) and remain fully interoperable throughout migration.
1. Workflow Coverage Confirm that the solution fully supports all AFIS workflows outlined in the SOW, including:
· NIST Tenprint
· Non‑NIST Tenprint
· Criminal Arrest Event (CAR)
· Applicant workflows (NFUF, MAP, SMAP)
· Latent workflows (ULW inbound/outbound, latent combo, palm combo)
· Optional Mobile 2‑finger search
Provide a clear mapping of out‑of‑the‑box capabilities versus configuration and customization requirements for each workflow.
2. Interface Compatibility Confirm the ability to maintain all existing AFIS interfaces, including CCH, ULW to FBI NGI, and MBIS connections for Marion/IMPD, Fort Wayne/Allen, South Bend/St. Joseph, and other participating agencies.
Identify any additional adapters, middleware or configuration the solution will require to sustain these interfaces.
External Partner Dependencies Document assumptions regarding external partners (jails, livescans, courts, FBI NGI) and describe how those assumptions will be validated early.
Confirm uninterrupted support for statewide AFIS operations during migration.
3. Operational Performance and Automation Describe how the solution delivers lights‑out processing, enhanced data validation, improved exception handling, and strengthened system monitoring, as required in the SOW.
4. Scalability Requirements Confirm the ability to scale from approximately 27 TB at implementation to approximately 35 TB within five years.
Explain the architectural elements (IOPS, tiering, storage design) that will enable this scalability.
5. Reporting and Analytics Support Confirm that the proposed solution will:
· Maintain existing legacy reports
· Provide new and required reporting
· Support statewide ODS, data warehouse, and data‑mart analytical workloads throughout the contract term
2. Executive Summary (AFIS Statement of Work, §I, §III.d, §VI.a)
The Respondent shall provide an executive summary describing the overall approach to delivering the AFIS Statement of Work in alignment with SOW §I (Executive Summary), §III.a (Objectives of the Engagement), and §III.b (Technical Requirements).
The summary must include:
1. Solution Delivery Approach An overview of the Respondent’s approach to delivering the solution, including the roles of any subcontractors engaged for this Contract.
2. Alignment to State Objectives Explain how the proposed approach supports the State’s goals for performance, reliability, interoperability, security, maintainability, and transparency, as articulated in the SOW Executive Summary and Objectives.
3. Background and Experience (AFIS Statement of Work, §III.b, §VI)
The Respondent shall describe its organizational background, relevant project experience, and qualifications in accordance with SOW §II (Background and Current State) and the domain‑specific integration, security, and CJIS requirements in SOW §III.b and §VI.
1. Comparable Project Experience Provide a list of organizations for which similar solution(s) and services have been delivered. For each project, include:
· Client name
· Project description and goals
· Solution and functionality provided
· Hosting model used
· Respondent’s role and duration
· Deliverables and project results
· Continued usage status (whether the solution is still in operation) Also:
· Explain relevance to the current RFP scope and how the experience will benefit the State.
· Describe any issues encountered, how they were resolved, and lessons learned.
2. Maintenance and Operational Support Experience Describe M&O experience for similar systems, including incident and problem management, maintenance cycles, and upgrade activities.
3. OCM Experience Describe the Respondent’s experience delivering Organizational Change Management (OCM) activities for similar projects.
4. Corrective Action History Identify any formal corrective actions the Respondent has received under prior contracts.
5. CJIS/CJI and AFIS Domain Experience Provide prior CJIS/CJI program experience, latent/tenprint AFIS implementation history, and MBIS/NGI integration experience, with emphasis on scale comparable to Indiana’s volumes and interfaces.
6. Large‑Scale Biometric Migration Experience Describe experience migrating large biometric datasets (≥15M items / ≥25–30 TB), including reconciliation methods.
7. Incident and Problem Management for Government Clients Describe prior experience performing incident and problem management under government governance models.
8. Best Practices Based on prior engagements, provide best practices relevant to the RFP scope that the State should consider.
4. General Understanding (AFIS Statement of Work, §I, §II, §III.a-§III.c)
The Respondent shall describe its understanding of the State’s vision and requirements for AFIS modernization as outlined in SOW §I (Executive Summary), §II (Current State), §III.a (Objectives), §III.b (Functional Requirements), and §III.c (Desired Future State).
1. Understanding of State Needs and AFIS Modernization Goals Describe the Respondent’s understanding of the State’s desired AFIS modernization outcomes, including workflow improvements, operational efficiency, interoperability, security and scalability.
2. Data Scale and Growth Expectations Acknowledge the current AFIS data volume (approximately 27 TB) and projected growth (approximately 35 TB within five years).
Explain how the proposed system design, storage architecture, IOPS performance, tiering strategy, image optimization, will support this scale, drawing on evidence from prior reference clients.
3. Understanding AFIS’s Role in the Criminal History Ecosystem Explain the Respondent’s understanding of AFIS as the “front door” to Indiana’s criminal history process and how the proposed solution reduces downstream impacts, such as reject rates and manual interventions.
4. Understanding of AFIS Integrations Describe how AFIS interacts with statewide systems, CCH, NGI, MBIS, RMS, jail systems, and livescan platforms, and emphasize the importance of seamless, uninterrupted interoperability.
5. Alignment with Desired Future State Demonstrate understanding of the Desired Future State AFIS as outlined in the SOW and explain how the proposed solution aligns across workflows, interfaces, security, hosting, and operational improvements.
5. System Requirements (AFIS Statement of Work, §III.b-d, §VI)
The Respondent shall describe how the proposed solution meets all system, functional, technical, interoperability, and hosting requirements defined in SOW §III.b–d and all compliance expectations in SOW §VI (Security, AI, Accessibility, Data Exchange, Authentication).
1. The Respondent shall describe how the proposed solution meets all system requirements.
2. Solution Description and Architecture
· Indicate whether the proposal is based on a commercial off‑the‑shelf (COTS) product or a transfer solution. If a transfer solution is proposed, identify the originating state, version, and relevant details.
· If the solution includes components from multiple sources, explain how the components integrate, including their type (COTS/Transfer), functionality, and where they have been implemented. For each example, include implementation date, hosting model, role, deliverables, results, and whether the system remains in active use.
c. Summarize out‑of‑the‑box capabilities and describe the configuration and customization required to meet the State’s mandatory requirements. Estimate the percentage of customization expected.
· Propose a hosting model consistent with SOW §III.b–d.
3. Administrative Module Capabilities Describe how the administrative module in the proposed solution will enable the State to manage, monitor, and configure the system. Include details regarding user and role management, system configuration capabilities, reporting and analytics functions, auditing and logging tools, data management features, security and compliance controls, maintenance functions, administrative support tools, training resources, and documentation.
4. Authentication and Identity Management Explain whether the solution can integrate with the State’s local Active Directory or Azure AD for single sign‑on.
Confirm integration with Access Indiana SSO and outline any internal identity provider (IdP) requirements.
5. Data Exchange Standards Confirm support for Indiana’s data exchange standards, MuleSoft API Management and GoAnywhere MFT, and describe how the solution supports secure APIs and managed file transfer.
6. AI/ML Components Disclose any AI/ML components used in matching, enhancement, or quality assurance. Confirm whether these capabilities can be disabled and affirm readiness to participate in the State’s AI Readiness Assessment process. Respondent must explicitly describe readiness to comply with the State’s AI Readiness Assessment requirements in SOW §VI.
7. Functional Requirements Matrix Provide an Attachment P Requirements Matrix specifying OOTB, configuration, customization, or not‑possible statuses.
Indicate whether customizations are planned for productization in future releases.
8. Reporting Requirements Describe how the solution will support all State and Federal reporting requirements and maintain both legacy and new reporting capabilities throughout the contract term.
9. Interface and Data-Sharing Support Explain how legacy interfaces and data‑sharing mechanisms will be supported and how new or updated interfaces will be incorporated during the engagement.
Confirm support for the ODS, data warehouse, and data mart analytical needs.
10. Analytical Workloads Describe how the solution supports analytical workloads, including summarized data sets and secure, role‑based access to operational subsets.
11. New Interface Support Explain how new interfaces introduced during implementation will be supported long‑term within the platform’s integration framework.
6 . System Development, Support and Reporting (AFIS Statement of Work, §III.f-g, §IV, §V)
The Respondent shall describe its approach to system development, testing, documentation, quality assurance, and reporting in full alignment with SOW §III.f (Deliverables and Deadlines), §III.g (Payment Milestones), §IV (Project Management Standards), and applicable IV&V interactions described in SOW §V.
1. Project Schedule Compliance Provide a proposed Project Schedule that satisfies the timelines in §IV of the AFIS Statement of Work.
2. SDLC Approach and Delivery Processes
· Describe the Respondent’s Systems Development Life Cycle (SDLC) approach, including agile or hybrid‑agile methodologies for DDI activities.
· Explain how incremental progress will be demonstrated (sprint cadence, demos, dashboards, burn‑ups/burn‑downs in ADO/Jira, per‑sprint UAT participation by ISP).
· Describe how configuration‑over‑customization decisioning is documented and escalated to the Project Steering Committee.
3. Requirements Validation Describe how requirements will be validated.
Confirm the use of a Requirements Traceability Matrix (RTM) in an ALM tool and provide a sample.
4. Development Framework and Tools Describe the software application development framework, including standard agile planning and delivery tools.
5. User Interface and Accessibility Explain how UI/UX considerations will be incorporated throughout DDI work.
Confirm conformance with Assistive Technology Standards and WCAG 2.1 AA requirements.
Describe how accessibility compliance will be verified during design and testing.
6. Testing Strategy Explain the approach to testing activities including:
· Levels of automated testing and tools used
· Integration practices for unit, system, regression, UAT, performance, security, and conversion testing
· Coordination with a third‑party testing vendor for UAT per sprint
· Adoption of SOW defect severity/priority definitions and pre/post‑go‑live resolution timelines
· Maintenance of automated test assets
7. Data Conversion and Migration Describe the proposed data migration strategy (phased or one‑time), including:
· Data sets to be converted
· Migration execution plan
· Automation used for transformation or migration
· Testing and validation of migrated data
· Experience with large‑scale biometric data migrations
8. Implementation and Deployment Describe the approach for implementation, including:
· Pre‑deployment readiness activities
· Day Zero execution
· Post‑deployment warranty support
9. Operational Support and Enhancements Explain the approach to providing ongoing operational support and enhancements, including understanding of non‑billable charge.
10. SOW Deliverable Describe the approach for delivering all required SOW deliverables (Kickoff Package, Requirements, RTM, Architecture Package, Technical Specs, Master Test Plan, Data Migration Package, Training Materials, Deployment Plan, Handover Package, Final Report, Warranty/Transition Documents).
Confirm agreement with the SOW delivery timelines and explain any related schedule assumptions.
11. Milestone‑Based Payments Confirm understanding that payments are tied to milestone acceptance and that no payment is issued until deliverables are approved by the State and, when applicable, IV&V.
12. Post‑Migration Validation Describe the Respondent’s approach to validating migrated data, workflows, interfaces, and system integrity prior to go‑live.
13. Entry and Exit Criteria Provide proposed entry and exit criteria for unit, system, integration, performance, security, and UAT test cycles.
7. Security (AFIS Statement of Work, §VI.a-e, §VI)
The Respondent shall describe its plan to fully comply with all security, privacy, regulatory, and CJIS requirements defined in SOW §VI.a–e, including ISF compliance, RAMP P.05 requirements, AI readiness, WCAG 2.1 AA accessibility, data exchange standards, and Access Indiana authentication.
1. Compliance with State Security Requirements Confirm that the Respondent shall comply with, and support the State in complying with, all security requirements and standards.
2. Privacy and PII Protections Confirm adherence to all law enforcement privacy practices associated with Criminal Justice Information (CJI) and Personally Identifiable Information (PII).
Describe the practices, controls, and safeguards in place to meet these obligations.
3. Compliance with Security Provisions Confirm that the Respondent shall comply with all security provisions.
Describe the processes, controls, and technical measures used to ensure continued compliance.
4. CJIS Requirements Confirm that the Respondent will sign the CJIS Security Addendum (corporate and individual, as applicable) and ensure that all personnel complete annual CJIS Awareness Training.
5. Incident Response Describe the Respondent’s incident response plan, including response timelines, escalation procedures, root‑cause analysis processes, notification requirements, and reporting expectations aligned to SOW requirements.
6. Security Framework, Accessibility, and AI Compliance Confirm compliance with the following State standards:
· Indiana Information Security Framework (ISF)
· WCAG 2.1 AA accessibility requirements
· State Agency Artificial Intelligence Systems Standard
Describe any limitations, dependencies, or prerequisites needed to maintain compliance.
8. Project Management (AFIS Statement of Work, §IV)
The Respondent shall describe its project management approach, schedule management, documentation processes, communications, and governance in accordance with SOW §IV.a–e (Project Management Plan, Key Persons, Staffing, Document Management, Status Reporting).
1. Project Management Standards Confirm acceptance of, and alignment with, the Project Management Standards.
2. Project Documentation Approach Describe the Respondent’s documentation practices and confirm compliance, including the structure and components of the required Project Plan.
3. Project Schedule Provide a proposed Project Schedule based on the RFP and Attachment K – Statement of Work.
4. Communication Plan Provide a Communication Plan that aligns with SOW expectations, including:
· Weekly status reports
· Monthly reviews
· Quarterly business reviews
· Ad hoc meeting support
5. Documentation Management Describe how all project documentation will be maintained in State repositories, including SharePoint and ALM tools, with appropriate naming and versioning standards.
6. Schedule Maintenance Confirm that the Respondent will update the project schedule at least weekly and provide visibility into critical path items as required by the SOW.
9. Quality and Defect Management (AFIS Statement of Work, §III.f, §X)
The Respondent shall describe its processes for quality assurance and defect management, including adherence to the Master Test Plan criteria defined in SOW §III.f and all defect response and resolution timelines defined in SOW §X.c (Defect Resolution Requirements).
1. Quality and Defect Management Approach Describe how quality assurance and defect management will integrate with the software delivery processes.
2. Defect Management Plan Provide an overview of the Respondent’s defect management plan, including intake, prioritization, tracking, escalation, and resolution processes.
3. Defect Tracking Tools Identify the defect tracking tool(s) to be used.
4. Severity/Priority Alignment Confirm adoption of the SOW’s severity and priority definitions, and agreement to the pre‑ and post‑go‑live defect resolution timelines.
5. Integration with State Reporting Describe how defect management activities and statuses will integrate with State reporting expectations, including weekly status reports, monthly reviews, and quarterly business reviews.
10. Risk Management (AFIS Statement of Work, §III.f, §IV)
The Respondent shall describe its approach to risk and issue identification, tracking, mitigation, and escalation in alignment with SOW §IV (Project Management – Risk and Issue Management) and deliverable requirements in SOW §III.f.
1. Risk and Issue Management Approach Describe the Respondent’s methodology for identifying, assessing, prioritizing, and mitigating risks and issues throughout the project lifecycle.
2. Risk Management Tools Identify the tool(s) the Respondent will use to manage risks and issues (ALM tools, project management software).
3. SOW‑Required Deliverables Confirm delivery of:
· The Risk Management and Mitigation Plan within 60 days of contract execution
· An initial risk log within 15 days
4. Ongoing Risk Monitoring and Reporting Describe how risks will be monitored, updated, escalated, and communicated in alignment with SOW requirements and the State’s reporting cadence.
11. Organizational Change Management (OCM) (AFIS Statement of Work, §IV)
The Respondent shall describe its OCM methodology, stakeholder engagement strategy, communication plan, and transition readiness activities as required under SOW §IV (OCM Requirements within Project Management)
1. OCM Methodology and Approach Describe the Respondent’s proposed OCM methodology and how it will meet the State’s requirements while minimizing organizational disruption.
2. Stakeholder Communication Explain how the Respondent will ensure that all stakeholders receive timely and accurate project information.
3. OCM Experience, Lessons Learned, and Best Practices Summarize the Respondent’s prior OCM experience on similar projects and identify lessons learned and best practices that will be applied to this engagement.
4. Stakeholder Coordination Describe how OCM activities will be coordinated with stakeholders across ISP, local criminal justice partners, and all statutory user groups.
12. Training (AFIS Statement of Work, §III.f, §VI.c)
The Respondent shall describe its user training approach, training materials, delivery methods, and competency verification in accordance with SOW §III.f (Training Deliverables) and accessibility requirements in SOW §VI.c (Accessibility Standards).
1. Training Approach Describe the Respondent’s proposed approach to meeting the State’s training requirements.
2. Training Channels and Media Identify the training channels and media that will be used and explain the rationale for these choices.
3. UX‑Informed Training Design Describe how the Respondent’s training methodology and materials will incorporate user experience (UX) considerations.
4. Pre–Go‑Live Training and Competency Sign‑Off Confirm agreement to provide training and knowledge transfer before go‑live, including ensuring competency sign‑off as part of the acceptance criteria.
5. Recorded Training and Competency Verification Confirm the Respondent’s ability to provide recorded training sessions and obtain competency sign‑off from designated user groups, as required by the SOW.
13. Status Reporting and Meetings (AFIS Statement of Work, §IV.e)
The Respondent shall describe its approach to ongoing communications, weekly status reporting, monthly reviews, quarterly business reviews, and dashboard‑driven updates as defined in SOW §IV.e (Status Updates and Reporting) and SOW §VII (KPIs).
1. Communication and Reporting Approach Describe the Respondent’s methodology for providing consistent and transparent project communications, including status reporting, risk and issue updates, and executive briefings.
2. Dashboard‑Driven Reviews Explain how dashboards will be used to support monthly review meetings and quarterly business reviews, including the visualization of trends in:
· Incidents
· Defects
· Schedule performance
· Key performance indicators (KPIs)
3. Meeting Participation Requirements Confirm the Respondent’s participation in the following recurring and ad‑hoc sessions:
· Weekly status meetings
· Monthly reviews
· Quarterly business reviews
· Additional meetings as requested by the State
14. Change Request/Change Management Process (AFIS Statement of Work, §IV, §III.f)
The Respondent shall describe its change management methodology, including use of Change Impact Analyses (CIAs) and adherence to the State’s approval procedures, in accordance with the Change Control requirements embedded in SOW §IV and applicable deliverable updates in SOW §III.f.
1. Change Management Approach Describe the Respondent’s change management methodology, including intake, evaluation, approval, prioritization, and communication of changes.
2. Alignment with SOW Change Control Process Confirm adherence to the SOW’s Change Control Process, including:
· Submission of a formal Change Impact Analysis (CIA) before work begins on any change
· Identification of scope, schedule, cost, technical, and operational impacts
· Compliance with State review and approval procedures prior to implementation
15. Project Staffing and Key Personnel (AFIS Statement of Work, §IV.b-c, §VI, §VIII)
The Respondent shall describe its proposed staffing model, Key Personnel qualifications, subcontractor roles, and staffing continuity plans according to SOW §IV.b–c (Key Persons and Other Staff), the CJIS personnel requirements in SOW §VI, and the operational staffing requirements in SOW §VIII (M&O).
1. Overall Staffing Plan The Respondent shall describe its comprehensive staffing plan to fulfill all roles and responsibilities. The proposal must include an organizational chart for the proposed project team that clearly distinguishes Respondent staff from subcontractor staff.
2. Resource Allocation Using Attachment Q – Resource Usage Matrix, the Respondent shall identify the number of full‑time‑equivalent (FTE) resources, by role, required to deliver and support the proposed solution. The Respondent must also document any assumptions regarding State‑provided staff, including FTEs by role.
3. Resumes for Vital Personnel The Respondent shall provide resumes for all proposed Vital Personnel.
4. Qualifications of Vital Personnel For each individual designated as Vital Personnel, the Respondent shall demonstrate how the proposed individual meets the requirements.
5. Subcontractors
· Describe the role of each subcontractor proposed for this Contract, including how that role may evolve over the course of the engagement.
· Identify the Respondent’s prior experience working with each subcontractor
· Describe each subcontractor’s relevant experience and expertise in supporting the scope of this Contract.
6. Location Requirements Confirm that all personnel performing services under this Contract will be based within the United States unless the State grants written approval for an exception.
7. Turnover and Knowledge Continuity
· Describe the Respondent’s plans to maintain low turnover and ensure continuity of knowledge throughout the life of the Contract.
· Provide the vendor’s method for verifying workflow continuity during cutover to avoid statewide operational interruption.
8. Staffing Stability Confirm the Respondent’s ability to maintain required staffing levels and provide timely replacements in accordance with SOW staffing replacement timelines.
9. CJIS Compliance Confirm that all staff requiring access to Criminal Justice Information will comply with the CJIS Addendum and complete the required annual CJIS Awareness Training.
16. Contract Transition and Turnover (AFIS Statement of Work, §IX)
The Respondent shall describe its approach to contract transition and structured turnover activities as outlined in SOW §IX (End of Contract Transition and Turnover), including 12, 9, 5, and 2‑month milestone deliverables and staffing continuity requirements.
The Respondent shall provide a detailed plan addressing the SOW defined structured turnover deliverables due at 12, 9, 5, and 2 months prior to contract end, including:
· Turnover Plan development and updates
· Transfer of all required artifacts and documentation
· Staffing transition and knowledge transfer
· Shadowing and reverse‑shadowing activities
· Operational handoff to the successor Vendor or the State
The Respondent shall also describe the controls, processes, and oversight mechanisms it will use to ensure no staffing reductions occur during the turnover period without prior State approval, as required by the SOW.
17. Software Warranty (AFIS Statement of Work, §III.f, §VIII)
The Respondent shall confirm acceptance of all warranty terms defined in SOW §III.f (Warranty Deliverables) and describe how warranty obligations, stabilization, and non‑billable compliance updates will be managed in alignment with SOW §VIII (M&O).
1. Required Confirmations The proposal must explicitly affirm:
· Acceptance of the 30–52 week warranty and maintenance transition period.
· Acceptance that routine maintenance and compliance updates, as defined in the SOW, are non‑billable.
2. Warranty Management Approach The Respondent shall describe its methodology for tracking, managing, and fulfilling all warranty obligations throughout both the initial stabilization period and the maintenance transition phase. This description should address the Respondent’s processes, tools, staffing, reporting, and oversight mechanisms used to ensure compliance with warranty requirements.
18. KPIs (AFIS Statement of Work, §VII)
The Respondent shall describe its support for the development, tracking, and reporting of Key Performance Indicators (KPIs) in compliance with SOW §VII, including modified Net Promoter Score (NPS) metrics and corrective action planning.
19. Maintenance and Operation (M&O) (AFIS Statement of Work, §VIII, §X)
The Respondent shall describe its proposed M&O plan, including monitoring, incident handling, access management, data warehouse support, batch operations, routine maintenance, and hypercare, in full alignment with SOW §VIII (Maintenance and Operations) and the SLA requirements of SOW §X.
1. System Monitoring Describe the tools, processes, thresholds, and staffing model the Respondent will use for proactive system and application monitoring.
2. Incident Management Provide the proposed incident intake, triage, prioritization, escalation, resolution, and communication processes. Include target response and resolution times.
3. Access Management Explain procedures for provisioning, modifying, and deprovisioning user access, including role-based access controls and audit practices.
4. Data Warehouse Support Detail how the Respondent will support data warehouse operations, including data ingestion, transformation, quality checks, and optimization activities.
5. Batch Processing Describe the monitoring, scheduling, error handling, and recovery procedures for batch jobs and related dependencies.
6. Routine Maintenance (Non‑Billable) Identify recurring operational tasks that will be performed as part of the base M&O services and not billed separately (log reviews, patches within standard scope, environment housekeeping).
7. Hypercare Support Outline the Respondent’s post‑deployment hypercare model, including staffing, issue resolution processes, duration, and success criteria.
All items listed above are explicitly required as part of the SOW, and the Respondent’s proposal must address each area in full.
20. Services Levels and Performance Remedies (AFIS Statement of Work, §X)
The Respondent shall confirm acceptance of all service levels and performance remedies defined in SOW §X, including system availability requirements, incident response and resolution timelines, defect resolution expectations, reporting requirements, and liquidated damages.
1. System Availability Requirement The Respondent shall commit to maintaining 99.9% system uptime, measured monthly.
2. Incident Response and Resolution Service Levels (P1–P4) The Respondent shall confirm adherence to the SOW-defined incident categories, response times, and resolution timelines for all Priority 1 through Priority 4 incidents.
3. Fix Timelines The Respondent shall document its ability to meet the required fix timelines for defects, remediation items, and corrective actions.
4. Reporting Requirements The Respondent shall provide all required operational and performance reporting, including availability reports, SLA performance, incident trends, and any other reporting required under the SOW.
5. Liquidated Damages and Performance Remedies The Respondent shall acknowledge and accept the SOW’s liquidated damages (LD) framework, including but not limited to:
· Availability credits
· Missed milestone penalties
· Remedies for repeated SLA violations
· Remedies related to staffing non‑compliance
All items listed above are explicitly required in the SOW, and the Respondent’s proposal must confirm compliance with each requirement.
File details come from the government source that posted it. Updated .