RFP_2200_GTG3007_ATT_9_v1.xlsx
XLSX spreadsheet 75 KB Posted
- Attached to
- Enterprise Asset Management (EAM) Solutions
- Solicitation number
- RFP 2200 GTG3007
- Issued by
- Texas
About this file
This is a vendor instructions workbook for the City of Austin's RFP 2200 GTG3007, which seeks an Enterprise Asset Management (EAM) / Computerized Maintenance Management System (CMMS) solution for the Austin Water Department. Vendors must complete all tabs in the provided Excel workbook and submit it with their proposal response by August 18, 2026 at 2:00 PM CT, with a mandatory pre-offer conference scheduled for July 13, 2026 at 12:00 PM CT via Microsoft Teams. The implementation scope covers a cloud-based, scalable system serving both horizontal and vertical infrastructure, requiring support for 500+ concurrent users with 99.9% uptime SLA. Proposals must be valid for 180 calendar days following the RFP closing date, and the contract commences upon execution with no fixed initial term, giving the City sole discretionary extension rights.
Vendors must provide comprehensive implementation plans addressing project governance, requirements validation, configuration, integrations, data migration, testing, training, organizational change management, go-live strategy, and post-go-live support across approximately 11 implementation phases spanning up to 17 months. The workbook requires detailed responses on implementation methodology, proposed delivery model, go-live strategy (Big Bang/Phased/Pilot), key success factors, risks and mitigation approaches, and resource needs. Major deliverables include project charter, requirements traceability matrix, solution design documentation, integration architecture diagrams, data conversion plans, test plans, training materials, organizational change management plans, and final acceptance packages. Vendors must also complete a 450+ functional-requirement matrix and data migration scope documentation, demonstrate compliance with 105 mandatory security requirements and 24 privacy overlay requirements including NIST standards and FIPS 140 encryption, and certify that their implementation plan is realistic, achievable, and aligned to the Scope of Work.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFP_2200_GTG3007_ATT_6_v1.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_2_v2.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_2_v1.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_6_v3.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_4_v1.pdf | ||
| RFP_2200_GTG3007_ATT_7_v1.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_14_v1.pdf | ||
| RFP_2200_GTG3007_ATT_15_v1.pdf | ||
| IFB_6100_CLMC971_PLANS_1_v1.pdf | ||
| RFP_2200_GTG3007_ATT_3_v1.docx | DOCX document | |
| RFP_2200_GTG3007_ATT_13_v1.pdf | ||
| RFP_2200_GTG3007_ATT_5_v1.pdf | ||
| RFP_2200_GTG3007_ATT_10_v1.docx | DOCX document | |
| RFP_2200_GTG3007_ATT_16_v1.pdf | ||
| RFP_2200_GTG3007_ATT_17_v1.pdf | ||
| RFP_2200_GTG3007_ATT_7_v2.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_1_v1.pdf | ||
| RFP_2200_GTG3007_ATT_1_v9.pdf | ||
| RFP_2200_GTG3007_ATT_11_v1.pdf | ||
| RFP_2200_GTG3007_ATT_12_v1.pdf | ||
| IFB_6100_CLMC971_PLANS_2_v1.pdf | ||
| RFP_2200_GTG3007_ATT_8_v1.xlsx | XLSX spreadsheet |
Show all 22
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
City of Austin
Vendor Instructions
Offeror shall complete each tab in this workbook and submit the completed workbook with its proposal response.
Responses should be concise, specific, and directly aligned to the Scope of Work for RFP 2200 GTG3007. The implementation plan should describe how the Offeror will deliver the proposed Enterprise Asset Management / CMMS solution, including project governance, requirements validation, configuration, integrations, data migration approach, testing, training, organizational change management, go-live, post go live support, resource needs, risks, and deliverables.
Offerors shall not modify the tab names, column headings, or required response structure. Supplemental materials may be provided separately; however, the primary implementation response must be completed in this workbook.
&G &"-,Bold"&18Instructions City of Austin
Implementation Summary
| Offeror shall provide a high level summary of its proposed implementation approach. | |
| Item | Vendor Response |
| Proposed Implementation Methodology | |
| Delivery Model | |
| Estimated Total Implementation Duration | |
| Proposed Number of Releases / Phases | |
| Proposed Go-Live Strategy | Big Bang / Phased / Pilot / Other |
| Proposed Implementation Start Assumption | |
| Key Success Factors | |
| Key Risks and Mitigation Approach | |
| Major Assumptions | |
| Austin Water Resource Dependency Summary | |
| Summary of Post-Go-Live Support Approach | |
| Narrative Response | |
| Provide a concise summary of the proposed implementation approach and why it is appropriate for Austin Water. |
Insert vendor response here:
Implementation Phases
| Proposed Implementation Phases (Sample) |
| Offeror shall describe the proposed implementation phases, estimated duration, responsibilities, and major deliverables. |
The phase descriptions below are samples and may be altered.
| Phase | Description | Estimated Duration | |
| (Working Days) | Key Offeror Responsibilities | Key Austin Water Responsibilities | Major Deliverables |
| 1 | Project Initiation / Planning | ||
| 2 | Discovery / Requirements Validation | ||
| 3 | Solution Design | ||
| 4 | Configuration / Build | ||
| 5 | Integrations | ||
| 6 | Data Migration Implementation | ||
| 7 | Testing / UAT | ||
| 8 | Training / Change Readiness | ||
| 9 | Go-Live / Cutover | ||
| 10 | Stabilization / Post-Go-Live Support | ||
| 11 | Final Acceptance / Closeout |
Implementation Timeline Proposed Implementation Timeline (Sample)
Offeror shall describe the proposed implementation phases, estimated duration, responsibilities, and major deliverables.
The timeline below is a sample and may be altered.
| Phase # | Phase / Workstream | Major Activities | Start Month | End Month | Estimated Duration | Key Deliverables | AW Responsibilities | Vendor Responsibilities | Dependencies / Assumptions | Payment Milestone, if applicable |
| 1 | Project Initiation / Planning | Kickoff, governance setup, Agile team structure, project roadmap, sprint cadence | 1 | 1 | 4 weeks | Project Plan, Governance Plan, Sprint Cadence, Initial Roadmap | Confirm project team, product owners, SMEs, decision makers | Facilitate kickoff, establish Agile delivery model, define ceremonies and reporting | Contract executed; project team assigned | Milestone 1 – Project Kickoff and Plan Approval |
| 2 | Discovery / Backlog Development | Requirements workshops, use case review, current-state review, backlog creation, prioritization | 1 | 3 | 8 weeks | Product Backlog, Prioritized User Stories, RTM, Workshop Notes | Provide SMEs, validate requirements, prioritize backlog | Facilitate workshops, document stories, define acceptance criteria, maintain RTM | SME availability; access to current documentation | Milestone 2 – Initial Backlog and Requirements Validation |
| 3 | Future-State Design / Solution Architecture | Future state process design, solution architecture, integration architecture, data migration planning | 2 | 4 | 8 weeks | Future-State Process Flows, Solution Design, Technical Architecture, Integration Approach | Review and approve future-state process and architecture | Develop design artifacts, align solution architecture to backlog and roadmap | Initial backlog established | Milestone 3 – Design and Architecture Approval |
| 4 | Sprint-Based Configuration / Build | Iterative configuration, workflow setup, roles, forms, reports, sprint demos, backlog refinement | 4 | 10 | 24 weeks | Configured Features, Sprint Demos, Updated Backlog, Configuration Documentation | Attend demos, provide feedback, approve sprint outcomes | Configure solution in sprints, demo working functionality, refine backlog | Approved initial design; environments available | Milestone 4 – Sprint Build Releases / Configured Capability |
| 5 | Integration Design & Build | Iterative API/interface design, build, unit testing, integration demos, error handling | 4 | 11 | 28 weeks | Integration Specs, Built Interfaces, Unit Test Results, Integration Documentation | Provide system access, integration SMEs, test data | Design, build, unit test, and document integrations by sprint/release | API access; source system availability; security approvals | Milestone 5 – Integration Build Complete |
| 6 | Data Migration | Data assessment, mapping, mock loads, validation cycles, final conversion planning | 3 | 12 | 36 weeks | Data Conversion Plan, Mapping, Mock Load Results, Reconciliation Reports | Provide extracts, data owners, validation support | Assess, map, transform, load, reconcile, and support validation | Data quality; access to IPS/EAM extracts | Milestone 6 – Data Migration Readiness |
| 7 | Iterative Testing / UAT | Sprint testing, system testing, integration testing, regression testing, UAT by release | 5 | 12 | 32 weeks | Test Plan, Test Scripts, Defect Log, Test Execution Reports, UAT Sign-Off | Execute UAT, validate acceptance criteria, approve release readiness | Support testing, resolve defects, provide test evidence | Configured features and test data available | Milestone 7 – Testing and UAT Complete |
| 8 | Training / Change Readiness | Role-based training, job aids, change communications, readiness tracking, train-the-trainer | 8 | 13 | 20 weeks | Training Plan, Job Aids, Training Materials, OCM Plan, Readiness Report | Identify trainees, support communication, attend training | Develop and deliver training, support adoption, prepare users for release | Stable release candidate; role definitions finalized | Milestone 8 – Training and Readiness Complete |
| 9 | Release / Go-Live / Cutover | Production deployment, final migration, go/no-go, rollback plan, release communication | 13 | 13 | 4 weeks | Cutover Plan, Rollback Plan, Go/No-Go Checklist, Production Release | Approve go/no-go, coordinate business readiness | Execute release, final migration, deployment, and validation | UAT sign-off; business readiness approval | Milestone 9 – Go-Live Complete |
| 10 | Stabilization / Hypercare | Post-go-live support, defect resolution, user adoption support, release stabilization | 14 | 16 | 90 days | Hypercare Plan, Issue Log, Stabilization Report | Report issues, validate fixes, participate in stabilization reviews | Provide hypercare, resolve issues, support adoption | Production go-live completed | Milestone 10 – Stabilization Complete |
| 11 | Final Acceptance / Closeout | Final documentation, knowledge transfer, support transition, backlog for future releases | 16 | 17 | 4 weeks | Final Acceptance Package, KT Materials, Closeout Report, Future Backlog | Review deliverables, approve final acceptance | Complete documentation, transition support, close project | Stabilization complete; critical defects resolved | Final Milestone – Final Acceptance |
Project Governance
| Project Governance Approach | |
| Offeror shall describe the proposed project governance structure, meeting cadence, reporting, escalation, and control processes. | |
| Governance Area | Vendor Response |
| Project Governance Structure | |
| Executive Steering Committee Approach | |
| Core Project Team Structure | |
| Decision-Making Process | |
| Project Team Meeting Cadence | |
| Status Reporting Approach | |
| Risk and Issue Management Approach | |
| Decision Log Management | |
| Action Item Tracking Approach | |
| Change Control Process | |
| Escalation Process | |
| Quality Assurance Approach | |
| Communication Management Approach | |
| Vendor / Subcontractor Governance Approach |
Requirements & Design
| Requirements Validation and Future-State Design | |
| Offeror shall describe how it will validate Austin Water’s requirements, business use cases, workflows, and future-state processes. | |
| Area | Vendor Response |
| Requirements Validation Approach | |
| Discovery Workshop Approach | |
| Stakeholder Engagement Approach | |
| Business Process Review Approach | |
| Future-State Workflow Design Approach | |
| Requirements Traceability Matrix Approach | |
| User Story / Use Case Approach, if applicable | |
| Prototype / Demonstration Approach | |
| Business Design Documentation Approach | |
| Technical Design Documentation Approach | |
| Approval Process for Requirements and Design |
Integration Implementation
| Integration Implementation Approach | |
| Offeror shall summarize how integrations will be planned, designed, built, tested, monitored, and supported. | |
| Area | Vendor Response |
| Integration Design Approach | |
| API / Interface Development Approach | |
| Real-Time vs. Batch Integration Approach | |
| Middleware Assumptions | |
| Error Handling and Reconciliation Approach | |
| Integration Monitoring Approach | |
| Security / Authentication Approach | |
| Integration Testing Approach | |
| Integration Documentation Approach | |
| Austin Water Responsibilities | |
| Third-Party Responsibilities / Dependencies |
Data Migration Approach
| Data Migration Implementation Approach | |
| Offeror shall summarize how legacy data migration will be planned, executed, validated, reconciled, and supported. | |
| Note: Offeror shall complete the detailed Data Migration Scope Matrix included in Appendix D – Technical Requirements. This tab should provide the implementation approach for managing the data migration workstream and should not duplicate the detailed Appendix D matrix. | |
| Area | Vendor Response |
| Data Migration Methodology | |
| Legacy Data Assessment Approach | |
| Data Quality Assessment Approach | |
| Data Cleansing Assumptions | |
| Source-to-Target Mapping Approach | |
| Mock Migration / Trial Load Approach | |
| Attachment and Document Migration Approach | |
| Data Validation and Reconciliation Approach | |
| Cutover Migration Approach | |
| Austin Water Responsibilities | |
| Key Assumptions / Dependencies | |
| Reference to Appendix D Data Migration Scope Matrix | Offeror shall complete the Data Migration Scope Matrix in Appendix D. |
Testing & UAT
| Testing and UAT Approach | |
| Offeror shall describe its proposed approach for planning, executing, documenting, and supporting testing and UAT. | |
| Testing Area | Vendor Response |
| Overall Testing Methodology | |
| Test Plan Approach | |
| Test Script Development Approach | |
| Unit Testing Approach | |
| System Testing Approach | |
| Integration Testing Approach | |
| Regression Testing Approach | |
| Performance / Load Testing Approach | |
| Security Testing Support | |
| UAT Support Approach | |
| Defect Management Approach | |
| Test Execution Reporting Approach | |
| Entry / Exit Criteria |
Training & OCM
| Training and Organizational Change Management Approach | |
| Offeror shall describe how it will train Austin Water users, administrators, and support staff, and how it will support organizational readiness and adoption. | |
| Area | Vendor Response |
| Training Strategy | |
| Role-Based Training Approach | |
| Administrator Training Approach | |
| End-User Training Approach | |
| Field / Mobile User Training Approach | |
| Training Material Development Approach | |
| Training Delivery Method | Onsite / Remote / Hybrid |
| Knowledge Transfer Approach | |
| User Manual / Job Aid Approach | |
| Training Effectiveness Measurement | |
| Organizational Readiness Assessment Approach | |
| OCM Strategy | |
| Stakeholder Impact Assessment | |
| Communication Plan Approach | |
| Change Champion / Change Agent Support | |
| Business Process Adoption Approach | |
| Resistance Management Approach | |
| OCM Effectiveness Assessment | |
| Austin Water Responsibilities |
Go-Live & Support
| Go-Live, Cutover, and Post-Go-Live Support Approach | |
| Offeror shall describe its proposed go-live, deployment, cutover, rollback, stabilization, and post-go-live support approach. | |
| Area | Vendor Response |
| Go-Live Strategy | |
| Deployment Approach | |
| Cutover Planning Approach | |
| Rollback Strategy | |
| Production Readiness Criteria | |
| Final Data Load Approach | |
| User Readiness Approach | |
| Support Readiness Approach | |
| Go / No-Go Decision Process | |
| Post-Go-Live Issue Management | |
| Stabilization / Hypercare Period | |
| Post Go Live Support Model | |
| Support Hours | |
| Support Channels | |
| Severity Levels | |
| Response and Resolution Targets | |
| Enhancement Request Process | |
| Knowledge Transfer to Support Team | |
| Ongoing Maintenance Transition | |
| Third Party Support Responsibilities | |
| Disaster Recovery / Business Continuity Approach | |
| RPO / RTO Validation Approach | |
| Disaster Recovery Testing Approach |
AW Resource Needs
| Austin Water Resource Needs (Sample) | |||
| Offeror shall identify the expected Austin Water resources needed to support the implementation. | |||
| AW Role / Resource Type | Estimated Time Commitment | Project Phase Needed | Responsibilities / Activities |
| Executive Sponsor | |||
| Project Manager | |||
| Business Product Owner(s) | |||
| Business SMEs | |||
| IT Technical Lead | |||
| Integration / API Resources | |||
| Data / Reporting Resources | |||
| GIS Resources | |||
| Security / Privacy Resources | |||
| Testing / UAT Participants | |||
| Training Participants | |||
| Change Management / Communications Resources | |||
| Other |
Risk Register
| Risk Register | ||||||
| Implementation Risk Register | ||||||
| Offeror shall identify the major implementation risks, assumptions, dependencies, and mitigation strategies. | ||||||
| # | Risk / Dependency | Impact Area | Probability | Impact | Mitigation Strategy | Owner |
| 1 | ||||||
| 2 | ||||||
| 3 | ||||||
| 4 | ||||||
| 5 | ||||||
| 6 | ||||||
| 7 | ||||||
| 8 | ||||||
| 9 | ||||||
| 10 | ||||||
| 11 | ||||||
| 12 | ||||||
| 13 | ||||||
| 14 | ||||||
| 15 | ||||||
| 16 | ||||||
| 17 | ||||||
| 18 | ||||||
| 19 | ||||||
| 20 | ||||||
| 21 | ||||||
| 22 | ||||||
| 23 |
Proposed Deliverables
| Proposed Deliverables | ||||
| Proposed Deliverables | ||||
| Offeror shall list the major deliverables that will be produced during the implementation and the proposed format for submitting these deliverables. | ||||
| Deliverable | Project Phase | Description | Format | City Review / Approval Required? |
| Project Charter / Project Plan | Initiation | |||
| Project Schedule | Initiation | |||
| Resource Plan | Initiation | |||
| Requirements Traceability Matrix | Requirements / Design | |||
| Future State Business Process Documentation | Requirements / Design | |||
| Solution Design Documentation | Design | |||
| Technical Design Documentation | Design | |||
| Integration Architecture Diagram | Integration | |||
| Data Conversion Plan | Data Migration | |||
| Test Plan | Testing | |||
| Test Scripts | Testing | |||
| System Test Execution Report | Testing | |||
| Training Plan | Training | |||
| Training Materials / User Guides | Training | |||
| OCM Plan | OCM | |||
| Deployment / Cutover Plan | Go-Live | |||
| Post-Go-Live Support Plan | Stabilization | |||
| Final Acceptance Package | Closeout | |||
| Other |
Vendor Certification
| Vendor Certification | |
| Vendor Certification | |
| Offeror shall certify that the proposed implementation plan is realistic, achievable, and aligned to the Scope of Work. | |
| Certification Statement | Vendor Response |
| Offeror has reviewed the Scope of Work and understands Austin Water’s implementation objectives. | |
| Offeror’s proposed implementation plan includes all major workstreams required to deliver the solution. | |
| Offeror has identified known assumptions, dependencies, and risks. | |
| Offeror understands that the final project schedule and deliverables will be subject to Austin Water review and approval. | |
| Offeror understands that implementation deliverables must meet City acceptance criteria before final acceptance. |
| Authorized Offeror Representative | Vendor Response |
| Name | |
| Title | |
| Company | |
| Date |
image1.png image2.png
File details come from the government source that posted it. Updated .