Attachment A_ Mandatory and Desirables_eBids RFP.xlsx
XLSX spreadsheet 2 MB Posted
- Attached to
- eBIDS Electronic Letting/Bidding Software RFP
- Solicitation number
- 24-494DOT-FINAD-B-38479
- Issued by
- St. Clair County, Illinois
About this file
This document is an attachment related to a State and Local Contract Opportunity for the Illinois Department of Transportation (IDOT) to procure a commercial off-the-shelf Software as a Service (SaaS) hosted electronic bidding solution. The attachment outlines the mandatory and desirable requirements for the proposed solution, including administration, application, reporting, infrastructure, interface/integration, project deliverables, data conversion, security, audit, and bidding functionality requirements. The solution must provide dashboard/home pages for letting and bidding activities, allow approved contractors to view and modify bid components electronically, utilize eForms, and integrate with external applications to import and export bidding data. Desirable requirements cover additional administrative, usability, and reporting functionality.
The attachment also requires the vendor to provide detailed project plan, implementation approach, testing methodology, training plan, and staff qualifications. Vendors must provide evidence to demonstrate compliance with the mandatory requirements and describe how they will meet the desirable requirements. The contract resulting from this solicitation will include the mandatory and desirable requirements outlined in this attachment.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Attachment B_PricingDetail_eBids RFP~1.xlsx | XLSX spreadsheet | |
| Attachment E_Customer Reference Questionnaire_eBids RFP.docx | DOCX document | |
| U-Plan V.24.1~2.pdf | ||
| Vendor Disclosures Formerly Forms A v 24.1~1.docx | DOCX document | |
| Attachment C-Mandatory Reports Matrix_eBids RFP.xlsx | XLSX spreadsheet | |
| Attachment F_Service Level Agreements_eBids RFP.docx | DOCX document | |
| C2D Vendor Answer Form eBIDS RFP~1.pdf | ||
| State of Illinois Offer v24.1 eBIDS RFP~1.pdf | ||
| eBids RFP~1.docx | DOCX document | |
| Attachment D_ Demo Script_ eBids RPF.docx | DOCX document | |
| Attachment G - Context Diagram.pdf | ||
| IPG Active Registered Vendor Disclosures~7.docx | DOCX document | |
| Vendor Questions with IDOT Responses Amendment 1 4 1 24.docx | DOCX document | |
| Vendor Questions with IDOT Responses Amendment 2~1.docx | DOCX document |
Show all 14
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
Response Code Descriptions
| eBids RFP | ||
| Response Code Descriptions | ||
| Response Code for ‘Indicator' | Response | Description |
| Y | Yes | Requirement will be met by proposed software; proposed software is operational in production use at other clients; can be demonstrated in base software. |
| N | No | Requirement is not available or will not be met by proposed software. |
| C1 | Customization 1 | Requirement will be met by customizing existing software or through the use of software tools provided in base product at no cost to the agency. |
| Note the following information in the narrative column next to this response: | ||
| - Description of customization/configuration required | ||
| - Estimated level of complexity (small, medium, large) | ||
| - Estimated duration of effort | ||
| C2 | Customization 2 | Requirement will be met by customizing existing software for an additional cost to the agency. |
| Note the following information in the narrative column next to this response: | ||
| - Description of customization/configuration required | ||
| - Estimated level of complexity (small, medium, large) | ||
| - Estimated duration of effort | ||
| - Estimated associated costs (must be included in RFP pricing details) | ||
| P | Planned | Requirement will not be met/provided, but is planned for a future release. Please specify target date for future release. |
| D | In Development | Requirement will be met by proposed software that is currently in development, in beta, or planned for release in the next 6 months. Please specify planned release date. |
| 3 | Supplied by Third Party | Requirement will be met by third-party software included in proposed solution. Please specify third party software and integration requirement being proposed. |
Mandatory without Evidence
| Attachment A - Mandatory and Desirable Qualifications |
| Mandatory Requirements without Evidence: |
Please read each item below carefully and check “Agree” indicating acceptance for each requirement. An Offeror that does not check “Agree” will be disqualified and the rest of the proposal will not be scored. These Mandatory Requirements shall be included in any contract resulting from this solicitation.
| Mandatory Requirements | |||
| ID | Category | Requirement Detail | Agree/Met |
| 1 | Administration | The application must allow system administrators to inactivate user access upon termination of employment or based on other user-defined criteria. | |
| 2 | Administration | IDOT Administrators must be able to configure/modify multiple levels of internal and external user access (roles). Users are limited to viewing/editing/reporting only data relevant to their assigned role. | |
| 3 | Application | The application must function on a Microsoft Windows Operating System (Windows 10 and higher) and should be accessible through modern web browser technologies available in the general marketplace. | |
| 4 | Application | All screens of the application must be in accordance with the Illinois Information Technology Accessibility Act (IITAA)(http://www.dhs.state.il.us/page.aspx?item=32765) | |
| 5 | Application | The application must be accessible over the Internet. | |
| 6 | Application | The application must provide ability to search historical data | |
| 7 | Application | The system must be designed with validations, errors and warnings to improve the user experience. | |
| 8 | Application | The solution must allow administrators and end-users the ability to upload and download documents to satisfy various business cases. | |
| 9 | Application | The system must be capable of sending notifications to users. | |
| 10 | Reporting | The system must include the reports specified in Attachment C - Mandatory Reporting Matrix. | |
| 11 | Infrastructure | The Agency must have access to the following environments: Test, QA, and Production when initially testing the SaaS and when testing new functionality or bug fixes. | |
| 12 | Interface/Integration | The application must have the ability to exchange data with other systems via secure data transfer methods approved by the Illinois Department of Transportation. |
Approved methods include connection to REST API secured with TLS1.2+, or data transfer into MS SQL Server databases over a secure connection encrypted with TLS1.2+.
13 Interface/Integration The system must have the ability to push/pull data to/from multiple internal and external sources (i.e. API, web services, data marts, other applications, etc.) for real-time analysis and reporting
Approved methods include REST API or web service secured with TLS1.2+, or data transfer into MS SQL Server databases over a secure connection encrypted with TLS1.2+.
IDOT uses Microsoft Azure SQL Server databases, and any solutions provided under this requirement must be compatible with these technologies (data pushed into IDOT databases).
| 14 | Project Deliverables | The vendor must provide the department with a data dictionary which clearly describes the location, structure, meaning and usage of all data elements within the vendor's database. |
| 15 | Project Deliverables | The vendor must conduct thorough testing including but not limited to unit, integration, and regression before releasing any code to the department's test environment. Documentation of vendor testing must be provided at the department's request. |
| 16 | Project Deliverables | The vendor must allow the department dedicated time and support to conduct user acceptance testing (UAT) at each project milestone, phase, deliverable or sprint. The duration of the UAT period should be in proportion to the functionality being delivered. |
| 17 | Project Deliverables | The vendor must provide a system rollout plan to coordinate parallel processing and go-live activities. The plan should include a check-list or calendar with daily/weekly tasks required to ensure a smooth cutover as well as agreed upon criteria for go-live (no critical defects, etc.). |
| 18 | Project Deliverables | The vendor must conduct performance testing prior to go-live/cutover to ensure response times, load speeds and transaction processing speeds are acceptable to the department based on the number of expected concurrent users. |
| 22 | Data Conversion | The offeror must be able to convert data from legacy systems. |
| 23 | Security | The application must allow for configurable system timeout which would require a user to re-authenticate after the timeout is exceeded. |
| 24 | Security | The solution must have the ability to securely store bids according to agency specifications. |
| 25 | Audit | The application must provide audit features for all transactions in the solution including, but not limited to all historical changes, i.e. created by, last modified by, last modified date, change details, etc. |
| 26 | Audit | The application must prevent deletion or alteration of audit records, except as part of a system administered archival process. |
| 27 | Bidding Functionality | The solution must provide dashboard/home pages for both letting and bidding activities per agency specifications. |
| 28 | Bidding Functionality | The solution must include a vendor home screen, which includes company related data and financial forms. |
| 29 | Bidding Functionality | The solution must allow approved contractors the ability to view and modify all components of a proposal/bid electronically. |
| 30 | Bidding Functionality | The solution must utilize eForms to be configured based on IDOT specifications for all proposal components. |
| 31 | Bidding Functionality | The solution must include functionality for users to complete pay item data for bids, including additive and alternate pay items. |
| 32 | Bidding Functionality | The solution must be able to receive addendums to proposals/bids in any status. |
| 33 | Bidding Functionality | The solution must allow approved contractors the ability to submit, re-submit and withdrawal bids electronically. |
| 34 | Bidding Functionality | The solution must allow approved contractors to submit combination bids. |
Mandatory with Evidence
| Attachment A - Mandatory and Desirable Qualifications |
| Mandatory Requirements with Evidence: |
Please check “Met” to each of the mandatory requirements for the proposed solution. An Offeror that does not provide substantiating evidence for each requirement will be disqualified and the rest of the proposal will not be scored. These Mandatory Requirements shall be included in any contract resulting from this solicitation. Please provide substantiating evidence in your Proposed Technical Solution. Use the column on the right to provide an answer and/or indicate the section and page number where your evidence/response to each item may be found. The State will evaluate Offeror’s evidence/response to verify the mandatory requirement is met.
| Mandatory Requirements | |||||
| ID | Category | Requirement Detail | Agree/Met | Vendor Response | IT Selection Committee Members Reviewed and Approve |
| 1 | Reporting | The application must have an integrated ad-hoc reporting and must provide ability to perform complex queries and calculations. |
This requirement can be fulfilled via custom ad-hoc reporting solution, or by a vendor-hosted standalone reporting platform such as Power BI (preferred). All data elements should be available to the users for ad-hoc reporting, exceptions made for configuration and technical implementation data that is unrelated to the business need.
| 2 | Infrastructure | The Offeror must identify proposed server and storage solutions that best meet the needs of proposed solution. Offeror must allow for at least but not limited to ten (10) years of storage capabilities. |
| 3 | Interface/Integration | The application must be integrated with external applications to import data including but not limited to the following: |
-Letting details -Proposal details (pay items, certifications, user specified special provisions, etc.)
-Addendums -Bid authorizations -Combination bids -Vendor company information -Notification recipients and details -User roles -Authentication
| 4 | Interface/Integration | The application must be integrated with external applications to export completed bidding data and associated documents. |
| 5 | Interface/Integration | The solution must integrate with electronic bid bond providers for bond validation purposes. |
| 6 | Interface/Integration | The application must integrate with the department’s internal application for authentication management across all modules of the solution. This integrated password management will adhere to State security policies such as minimum password length, password complexity, etc. |
| 7 | Project Deliverables | The offeror must provide Administrator training, including all training materials and documentation. Training must be conducted in a suitable environment (not production). Training documentation must include both online (in application) help as well as PowerPoint presentation materials, lecture notes, video tutorials and follow-up question and answer content. |
Provide Train-the-Trainer (Power user) training . Training must be conducted in a suitable environment (not production), using real, converted IDOT data. Train the trainer documentation must include PowerPoint or Portable Document Format (PDF) presentation materials, lecture notes, and follow-up question and answer content to enable IDOT trainers to replicate the end user training process.
Provide examples of both with proposal.
| 8 | Project Deliverables | Provide documentation demonstrating what is included in the warranty by the Offeror to ensure the solution is free from defects after the implementation is complete. |
| 9 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 1 (Support Management) of the Department's Service Level Agreement (Attachment F). |
| 10 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 2 (Service Availability) of the Department's Service Level Agreement (Attachment F). |
| 11 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 3 (Incident Response) of the Department's Service Level Agreement (Attachment F). |
| 12 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 5 (Service Maintenance) of the Department's Service Level Agreement (Attachment F). |
| 13 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 6 (Data Management) of the Department's Service Level Agreement (Attachment F). |
| 14 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 7 (Information Security) of the Department's Service Level Agreement (Attachment F). |
| 15 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 8 (Service Reliability) of the Department's Service Level Agreement (Attachment F). |
| 16 | SLA | Provide documentation which demonstrates compliance with the mandatory requirements specified in Section 9 (Audits & Compliance) of the Department's Service Level Agreement (Attachment F). |
Desirables
| eBids RFP |
| Attachment A - Mandatory and Desirable Qualifications |
Desirable Requirement Responsive Elements:
Please explain if your organization meets or will meet each of the desirable elements within Attachment A using the appropriate response code from the “Response Code Description” tab of Attachment A. Use the Vendor Response column to provide a narrative of how the solution meets the requirement and/or indicate the section and page number of your proposal where your response to each item may be found. The Desirable Requirements and the Offeror’s responses shall be included in any contract resulting from this solicitation.
| Desirable Requirement Responsive Elements | ||||
| ID | Category | Requirement Detail | Response Code | Vendor Response |
| 1 | Administrative Functionality | Describe how the solution allows administrative users to upload contract specific documents to be viewed on the bidding screens for approved vendors. Administrators can also remove uploaded documents. | ||
| 2 | Administrative Functionality | Describe how the solution allows IDOT Admin users the capability to determine which bid components are viewable based on bid authorization status. | ||
| 3 | Administrative Functionality | Describe how the solution provides a method for Administrators to configure (create, modify and delete) proposal eForms with no coding required. | ||
| 4 | Administrative Functionality | Describe how the solution allows administrators the ability to execute jobs which transfer bidding data and documents to internal systems (in real time) per IDOT specifications. | ||
| 5 | Administrative Functionality | The Offeror should describe the agency's ability to configure or customize the solution including the tools, software and skills/training required. | ||
| 6 | Administrative Functionality | Describe how the solution provides the ability to configure validation rules, without programming, applicable to all forms of data entry. Include the ability to customize messages for validation rules. (E.g. Validation rules can include field validations within ranges, requirement for adding comments on certain statuses, valid values, response types, number of days to wait for a response, etc.) | ||
| 7 | General Application/Usability/User Interface | Describe how the application provides the ability to do a keyword search which returns matching proposals from the current letting. | ||
| 8 | General Application/Usability/User Interface | Describe how the solution includes a workflow engine/process which will route workflows based on roles within the solution. | ||
| 9 | General Application/Usability/User Interface | Describe how the solution is designed with agency defined validations within all components of the proposal to help eliminate incomplete or incorrect bid submission. | ||
| 10 | General Application/Usability/User Interface | Describe how the solution has the capability to display errors and warnings within all bid components based on business rules defined by IDOT. | ||
| 11 | General Application/Usability/User Interface | Describe how the solution has the ability to access all historical records without degrading system response times to other users. | ||
| 12 | General Application/Usability/User Interface | Describe how the application has a similar look and feel between modules providing for a uniform solution. | ||
| 13 | General Application/Usability/User Interface | Describe how the solution is designed for a profile-based user experience ( Home page, role-oriented menus and reports, etc.). | ||
| 14 | General Application/Usability/User Interface | Describe how drop-down boxes within the solution utilize type ahead (auto complete) functionality. | ||
| 15 | General Application/Usability/User Interface | Describe how the solution automatically saves data as it's entered when navigating through the proposal. | ||
| 16 | General Application/Usability/User Interface | Describe how the solution provides users with hyperlinks to other documents/screens, as determined by IDOT, for easier system navigation. | ||
| 17 | General Application/Usability/User Interface | Describe how the solution utilizes standard windows keyboard functions and shortcuts (tab, copy, paste, etc.) for navigation and data entry within all areas of the application. | ||
| 18 | General Application/Usability/User Interface | Describe how the solution utilizes responsive web design. | ||
| 19 | General Application/Usability/User Interface | Describe how the solution allows users to upload or import documents (in various formats) when required to complete various components of the proposal (Certifications, special provisions, pay items, etc.) | ||
| 20 | General Application/Usability/User Interface | Describe how the solution is designed to validate uploaded or imported file types according to agency requirements. | ||
| 21 | General Application/Usability/User Interface | Describe how the solution provides the ability to send notifications to users based on different actions taking place within the system, including but not limited to: bid submission, bid withdrawal, proposal withdrawal, addendums, and approval to bid. | ||
| 22 | General Application/Usability/User Interface | Describe how the solution provides online help functionality for both system admins and end-users. The help should be customizable, built into every screen; and is indexed, searchable, and context sensitive. The online help will be updated as customizations are made to the system. | ||
| 23 | General Application/Usability/User Interface | Describe how the solution includes video tutorials within the application, targeted at end-users/contractors, which cover all areas of system functionality. | ||
| 24 | Reporting | Describe how the system includes intuitive and easy to use reporting capabilities, including the ability to export reports into various agency specified formats. | ||
| 25 | Bidding Functionality | Describe how the solution manages all activities related to a single proposal using a clear method and provide the user with a visual cue to track progress through the bidding process. | ||
| 26 | Bidding Functionality | Describe how the solution provides the user with a letting dashboard including available to bid proposals with a status of each bid component (Pay Items, Addendum, Special Provisions, etc.). | ||
| 27 | Bidding Functionality | Describe how the letting dashboard provides users the ability to search and view lettings from the previous two years and link to submitted bid documentation. | ||
| 28 | Bidding Functionality | Describe how the letting dashboard has sort, filter and search capabilities as determined by IDOT. Demonstrate the default filter applied and how the user is able to configure default settings. | ||
| 29 | Bidding Functionality | Describe how the letting dashboard distinguishes available-to-bid proposals from other proposals. | ||
| 30 | Bidding Functionality | Describe how the letting dashboard includes hyperlinks as specified by IDOT to other screens and documents. | ||
| 31 | Bidding Functionality | Describe how the letting dashboard provides the user a method to request authorization to bid on proposals in the current letting. | ||
| 32 | Bidding Functionality | Describe how the letting dashboard indicates when a proposal can also be submitted as a combination bid. | ||
| 33 | Bidding Functionality | Describe how the vendor home screen includes information such as demographic data, users and roles. This information will be read-only. | ||
| 34 | Bidding Functionality | Describe how the vendor home screen provides users with the capability to manage financial forms at a company level to be included with each bid submission. | ||
| 35 | Bidding Functionality | Describe how the solution provides the user with a proposal dashboard inclusive of specific proposal information and other identified bid information as specified by IDOT. | ||
| 36 | Bidding Functionality | Describe how the proposal dashboard contains a static header with specific proposal information as specified by IDOT. The header is always displayed while working through the associated bid components. | ||
| 37 | Bidding Functionality | Describe how the proposal dashboard displays both the letting and current date/time (HH:MM:SS)/time zone for each proposal. | ||
| 38 | Bidding Functionality | Describe how the proposal dashboard includes a listing of all bid components including proposal specific eForms (Certifications, Special Provisions, etc.) to be completed by the user. The content of the eForms will be provided by IDOT. | ||
| 39 | Bidding Functionality | Describe how the proposal dashboard displays historical bid submission information as specified by IDOT including but not limited to unique confirmation number, action, date and time, submitter, and bid amount. | ||
| 40 | Bidding Functionality | Describe how the proposal dashboard displays a listing of all uploaded documents with a description indicating the bid component the document satisfies. | ||
| 41 | Bidding Functionality | Describe how the proposal dashboard provides the ability to display bid amount summaries per IDOT specification to include base pay items, additive, alternate and combination bid amounts. | ||
| 42 | Bidding Functionality | Describe how the proposal dashboard provides the ability to enter a combination bid total, as specified by IDOT, for bids flagged as combination bids. | ||
| 43 | Bidding Functionality | Describe how the proposal dashboard provides the user with the ability to view, submit or withdraw bids. | ||
| 44 | Bidding Functionality | Describe how the solution provides the capability to share and validate data with electronic bid bonds (such as SurePath and Surety2000) according to Agency specifications. | ||
| 45 | Bidding Functionality | Describe how the solution provides a dynamic based bid guaranty feature based upon the type of proposal. | ||
| 46 | Bidding Functionality | Describe how the solution provides the users with a drop-down of acceptable Surety Types within Bid Guaranty. | ||
| 47 | Bidding Functionality | Describe how the solution requires Bond # for designated Surety Types. | ||
| 48 | Bidding Functionality | Describe how the solution provides users the ability to view, edit, and/or submit IDOT specified bid components in the current letting based on their bid authorization status. | ||
| 49 | Bidding Functionality | Within bid components, describe how the solution utilizes eForms when user response is required. | ||
| 50 | Bidding Functionality | Describe how the solution provides the capability for eForms to include free-form text boxes, radio buttons, checkboxes, drop-down menus, and grids based on IDOT specifications. | ||
| 51 | Bidding Functionality | Describe how the solution provides users the ability to upload documents within an eForm based on IDOT specifications. | ||
| 52 | Bidding Functionality | Describe how the solution provides users the ability to electronically sign/acknowledge bid components and entire bids based on IDOT specifications. | ||
| 53 | Bidding Functionality | Describe how the solution provides the capability for eForms to include hyperlinks to additional documents based on IDOT specifications. | ||
| 54 | Bidding Functionality | Describe how the solution provides users with an interface to view, sort, and modify pay item data. | ||
| 55 | Bidding Functionality | Describe how the solution allows users to download/export pay item data to be completed outside of the application using IDOT accepted formats (such as Excel, HCSS, Bid2Win and Hard Dollar) | ||
| 56 | Bidding Functionality | Describe how the solution allows users to import completed pay item data in IDOT approved formats | ||
| 57 | Bidding Functionality | Describe how the solution provides functionality to filter on incomplete pay items. | ||
| 58 | Bidding Functionality | Describe how the solution provides the capability to receive and display pay item alternates where contractors must complete the base pay items plus one of the alternate options. | ||
| 59 | Bidding Functionality | Describe how the solution provides the capability to receive and display pay item additives where contractors must complete the base pay items plus each additive option. | ||
| 60 | Bidding Functionality | Describe how the solution allows for changes to the proposal to be received from an outside application and acknowledged by the user at any point during the bidding process. | ||
| 61 | Bidding Functionality | Describe how the solution requires users be a signature authority in order to Submit a Bid. | ||
| 62 | Bidding Functionality | Describe how the solution provides the capability to email the vendor's signature authority when the bid is ready for submission. | ||
| 63 | Bidding Functionality | Describe how the solution notifies the user when resubmission is required if changes are made to the bid component responses after the bid has been submitted. | ||
| 64 | Bidding Functionality | Describe how the solution allows users to submit completed bids up until the user defined letting date/time. | ||
| 65 | Bidding Functionality | Describe how the solution allows users the ability to update and re-submit bid details until the letting date/time. | ||
| 66 | Bidding Functionality | Describe how the solution overwrites existing bid details each time the bid submission process is completed. | ||
| 67 | Bidding Functionality | Describe how the solution allows users the ability to view/preview/export/print a bid regardless of status. | ||
| 68 | Bidding Functionality | Describe how the solution includes bid history with a date/time stamp with each bid submission. | ||
| 69 | Bidding Functionality | Describe how the solution allows users to withdraw submitted bids up until the defined letting date/time. | ||
| 70 | Bidding Functionality | When submitting a bid, describe how the solution notifies the user if the proposal is part of a combination bid opportunity. | ||
| 71 | Bidding Functionality | Describe how the solution requires that, In order to submit a combination bid, both individual proposals must be submitted. | ||
| 72 | Infrastructure | The Offeror should provide a high level architecture model/diagram representative of the solution. This should include all the environments within the solution (production, QA, test, etc.). | ||
| 73 | Infrastructure | The Vendor should provide a data warehouse or replication of OLTP solution database(s) containing all IDOT data housed by system. This must include all IDOT data, ancillary data (e.g. code tables), and schema required to produce reports (e.g. views). At any time the data provided should be no more than 24 hours out of sync with the data source's current state. | ||
| 74 | Audit | Describe how the application has the ability to export audit data. | ||
| 75 | Audit | Describe how the application provides archive and restoration processes for audit logs. | ||
| 76 | Audit | Describe how the Offeror will help facilitate State of Illinois Internal Auditors (or external auditors selected by the Agency) to audit the application processes, data, and documentation on a periodic basis. The audits will be coordinated between the Offeror and the Agency. | ||
| 77 | Audit | Describe how the solution includes auditable logs on all system edits, deletes, and additions. Log should include: |
a. The date and time an auditable event occurs.
b. The objects affected.
c. The identity and role of the actor performing the activity. If an identity can be assigned multiple roles, or multiple roles can authorize the same activity, this would mean the role used to authorize the activity in this case.
d. The outcome (success or failure) of the activity.
e. The audit history of a particular record (original data retained).
| 78 | Security | The Offeror should describe the solutions authentication and application (security) mangement capabilities, including how role based permissions are administered within the application. |
| 79 | Security | Describe how the solution will not allow unauthorized users to access or update submitted bid data until designated letting date/time. |
| 80 | Security | Describe how the solution will only allows authorized users to modify or submit bids up until the designated letting date/time. |
| 81 | Project Deliverables | The Offeror should provide a detailed project plan broken into phases/deliverables including project initiation (discovery, fit gap, and design), development (configuration and build), data conversion and interfaces, vendor and user acceptance testing, training and Department readiness, implementation/go-live, warranty and support. The project plan should include all required Department project team resources (by role) including estimated time commitments (in percentage). The project plan should include milestones and deliverables with dates. The project plan should take into consideration availability of department subject matter experts and avoid department deliverables during their peak working times. |
| 82 | Project Deliverables | The Offeror should describe their implementation plan, including: |
a. The approach and project methodology used in Offeror’s implementations, both initial deployment and upgrades during implementation of solution
b. The steps required to implement the proposed solution, including acceptance criteria for each milestone/deliverable
c. The Department resources, skills, and personnel recommended for implementation
d. The Offeror’s process, methodology, and frequency of software enhancements and upgrades (during the implementation and in support)
e. The type of system documentation provided to reflect the base system and department's customizations (provide examples)
f. The Offeror should include at least two case studies with critical path timelines of recent customer implementations.
| 83 | Project Deliverables | Explain how a requirement traceability matrix (RTM) to track the department's requirements throughout the life-cycle of the project. |
| 84 | Project Deliverables | The Offeror should describe their change management process and/or tools used to request, gain approval and track changes. |
| 85 | Project Deliverables | Describe the type of secure platform the offeror and department can use during the project for communication, document sharing, defect reporting, etc. (i.e. Teams or SharePoint). |
| 86 | Project Deliverables | The Offeror should describe the risk and issue management process and/or tools used to report and track risks, issues and problems reported by clients, including average time for resolution of an issue and escalation procedures. Include descriptions of the most common challenges encountered during implementation and how each has been resolved. |
| 87 | Data Conversion/Migration | The Offeror should describe their approach, methodology, plan and tools used in data conversion/migration activities to populate the proposed solution including data validation practices and criteria for acceptance/sign-off. It is assumed the Offeror will have the ability to validate and audit migrated data. |
| 88 | Training | The Offeror should describe their training methodology during the implementation including: |
a. Types of training provided (administrative, power user, end user, etc.)
b. Examples of training materials and documentation provided
c. How training will be conducted throughout the implementation (when, in which environment, and by whom)
| 89 | Testing | The Offeror should describe their testing methodology, including including types of testing conducted by both the vendor and department staff (unit, integration, user acceptance, etc.) and examples of test plans and test result tracking tools used during the implementation. |
| 90 | Testing | The Offeror should describe the types of test cases/scenarios/scripts provided to the department for use during user acceptance testing. |
| 91 | Testing | The Offeror should describe their defect tracking management process and/or tool used to report and track defects reported by clients during the implementation and when in support, including average times for resolution of a confirmed defects by severity. |
| 92 | Vendor Information | The Offeror should describe their company profile and history including but not limited to the following: |
a. Company startup date, State of incorporation and number of years, company headquarters location, data center location, customer support (help desk) location(s)
b. Company organizational structure (management, implementation, product development, support, etc.), total employee head count and total contractor head count (if applicable)
c. Approach to support once the implementation is complete
d. Company philosophy, leadership vision, account and customer relationship management procedures
e. What makes the company and solution distinguishable from the competition
f. Include any relative published articles, awards, rankings, etc. about company and/or proposed solution
g. Brief financial profile 93 Vendor Information The Offeror should describe their experience in this software space (electronic bidding software) including but not limited to the following:
a. Number of years of experience in this specific solution space
b. Date of very first software application release
c. The total number of software versions released to date for proposed solution
d. Describe any implementation partners 94 Vendor Information The Offeror should document statistics on their client base, including:
a. Number of clients who have installed and are currently using the proposed solution in production
b. Percentage of clients by sector (e.g. private, federal, state, county)
c. Percentage of clients by size (e.g. small, medium, large – provide description or scale of sizes)
d. Average life cycle for project implementation from start to finish for current client base
e. Percentage of clients on current release of proposed solution
f. A description of any non-performing or canceled contracts 95 Vendor Information The Offeror should describe the skills and experience of the proposed implementation team who will be assigned to the department, including:
a. Resumes/curriculum vitae for all
b. For each proposed team member, include their skills by role such as project management, business analysis, technical capabilities, training, interfaces, conversions, architecture, testing, quality assurance, technical writing, reporting.
c. For each proposed team member, include prior customer account experience within the last three (3) years similar to requested supplies and services
d. For each proposed team member, indicate if member is an employee or subcontractor
e. Describe the actions Offeror will take if an employee or contractor is unable to perform to the requirements outlined in the contract
| 96 | Vendor Information | The implementation team assigned to the department in Offeror’s proposal should be the same personnel who continue working on this solution. Member(s) of the implementation team should not be removed or replaced by the Offeror without written review and approval of a Department representative. If a member of the implementation team is removed or replaced, they should have equivalent skills and experience to the person being replaced. |
| 97 | References | The Offeror should provide all requested client references information detailed in Sections F.4 of the RFP. |
File details come from the government source that posted it. Updated .