RFP 48401_DOT0003111 _ Statewide ITS Maintena.pdf

Page 1 RFP Document Version 0.5

Georgia Department of Transportation

Request for Proposals

To Provide

Statewide Intelligent Transportation System

Maintenance

RFP: 48401-DOT0003111

RFP Closing Date: 10/23/2024

Georgia Department of Transportation One Georgia Center

600 West Peachtree Street, NW Atlanta, Georgia 30308

Page 2 RFP Document Version 0.5

Table of Contents

1. General Project Information

1.1. Overview

1.2. Important – A Restriction of Communication is in Effect for this Project

1.3. Purchase Orders

1.4. Contract Term and Type

1.5. Contract Amount

1.6. Performance and Payment Bonds

1.7. Organizational Conflict of Interest

2. Schedule of RFP Events

3. Scope of Services

3.1. Project Description

3.2. Maintenance Manuals, Standards, Guidelines, and Procedures

3.2.1. ITS Maintenance Standard Operating Procedure

3.2.2. Other Manuals, Standards, and Guidelines

3.2.3. Location of Work

3.2.4. Travel

3.3. General Services

3.3.1. Project Management Services

3.3.2. ITS Asset Management System

3.3.3. IT Policies and Procedures

3.4. Maintenance Services

3.4.1. Inventory Management

3.4.2. Pay-for-Performance

3.4.3. Preventative Maintenance

3.4.4. Corrective Maintenance

3.4.5. Testing and Acceptance of ITS Assets

3.4.6. Traffic Control and Lane Closures

3.4.7. Replacement and Upgrades

3.4.8. Optional Services

3.4.9. Locate Services

3.4.10. Emergency Services

3.4.11. Third Party Claims

3.5. Transition of Services

3.6. Closure Protocol

4. Instructions to the Offerors

4.1. Submittal of Questions and Request for Clarification and Extensions

4.2. Preparing the Technical and Cost Proposals

4.2.1. Preparing Technical Proposals

Page 3 RFP Document Version 0.5

4.2.2. Preparing Cost Proposals

4.3. Submittal of the Technical and Cost Proposals

4.3.1. Technical Proposal – Electronic Proposal Submittal

4.3.2. Cost Proposal – Electronic Submittal

5. Selection Criteria

5.1. Technical Proposal – 700 Points

5.2. Cost Proposal – 300 Points

5.3. Final Evaluation

5.3.1. Technical Score Adjustment Formula

5.3.2. Cost Score Adjustment Formula

5.4. Basis for Award

6. Additional Terms and Conditions

6.1. Award Conditions

6.2. Joint-Venture Proposals

6.3. Small and Minority Business Enterprise

6.4. Statement of Agreement

6.5. Bid Substitutions, Alternates, Exceptions, and Extensions

6.6. Sexual Harassment Prevention Policy

Page 4 RFP Document Version 0.5

1. General Project Information This section includes a concise overview of this Request for Proposals (RFP) and provides Offerors with a foundational understanding of the forthcoming information.

1.1. Overview

The Georgia Department of Transportation (Department) is issuing this RFP from experienced firms to enter an agreement to provide Statewide Intelligent Transportation System (ITS) Maintenance. The services include those related and pertaining to maintenance, repair, replacement, installation, and management of the Department’s ITS devices, related hardware, and infrastructure. This RFP seeks to obtain technical and cost proposals from such qualified teams. All respondents to this RFP are subject to instructions communicated in this document and are cautioned to completely review the entire RFP and follow instructions carefully. The Department reserves the right to modify existing provisions or include additional provisions, which are not addressed herein. The Department reserves the right to reject any or all proposals, and to waive technicalities and informalities at its discretion. This solicitation is being conducted by the Department under its authority to procure services ancillary to the construction and maintenance of a public road, as defined in O.C.G.A § 32-1-3, as provided for in O.C.G.A § 32-2-64 and § 32-2-69.

The Scope of Services is included in Section 3 of this RFP. In addition to the Scope of Services, the Department has provided the following informational exhibits:

Exhibit A – Acronyms, Terms, and Descriptions Exhibit B – Area Definitions Exhibit C – Statewide ITS Maintenance Standard Operating Procedures Exhibit D – Statewide ITS Maintenance Obsolescence Plan Exhibit E – ITS Asset Inventory Summary Exhibit F – Traffic Interruption Request (TIR) Guidance Document Exhibit G – Technology Terms and Conditions Exhibit H – Sample Contract Exhibit I – State of Georgia Sexual Harassment Prevention Policy Exhibit J – Disadvantaged Business Enterprise Program Criteria for Acceptability Exhibit J-1 – DBE Goals Exhibit K – FHWA 1273 Exhibit L – SP404 Performance and Payment Bonds

In addition to the informational exhibits, the following attachments must be returned as part of the response by the Offeror:

Attachment A – Certification Form Attachment B – Georgia Security and Immigration Compliance Act Affidavit Attachment C – Mandatory Pass/Fail Questions Attachment D – Mandatory Scored Questions Attachment E – Cost Proposal Spreadsheet Attachment F – Price Acknowledgment Form

Failure to complete and submit all requested attachments will deem the Offeror as non-responsive.

Instructions on how to complete these attachments are included herein.

1.2. Important – A Restriction of Communication is in Effect for this Project From the advertisement date of the solicitation through contract award and the selection is announced, Offerors are not allowed to communicate about this solicitation or scope with any staff of the Department, including the Commissioner and Board Members, except for submission of questions as instructed in the RFP or as provided by any existing work agreement(s). For violation of this provision, the Department reserves the right to reject the submittal of the offending Offeror.

Page 5 RFP Document Version 0.5

1.3. Purchase Orders

Once the awarded contract is executed, the Department anticipates issuing the following set of Purchase Orders for the Offeror:

• ITS Asset Management System

• Emergency Services

• Optional Services

• Pay-for-Performance

• Locate Services All other Purchase Orders specific to an event response would be issued as a necessitating event is identified. There is no guaranteed number of events, and the Department reserves the right to issue as many or as few Purchase Orders as deemed necessary.

1.4. Contract Term and Type

The Department anticipates one five (5) year contract utilized on an "as needed" basis. Purchase Orders will be executed and a Notice to Proceed (NTP) issued for each Purchase Order before services may commence, unless directed otherwise by the Department under emergency procedures. Purchase Orders will be paid on a firm-fixed price basis. Purchase Orders for specific services will be paid in accordance with specific rates of compensation as bid via the awarded Offeror’s cost proposal.

1.5. Contract Amount

There is no contract maximum for this Open Agency Contract. The items and quantities listed in Attachment E – Cost Proposal Spreadsheet may be adjusted, as determined by the Department, during the term of the contract as items and specific quantities of each item are realized. The compensation to the Offeror shall be subject to the terms and conditions of the contract. Such payment shall be full compensation for work performed or services rendered and for all labor, materials, supplies, and equipment necessary to complete the work specified in and within each Purchase Order. The cost of such services shall be paid in accordance with each Purchase Order.

1.6. Performance and Payment Bonds

Performance and payment bonds are required when purchasing equipment for optional services, emergency services, and bulk replacements. Bonds are not needed for Pay-for-Performance; corrective maintenance; or for optional services and emergency services that do not include new equipment installations. Purchase Orders that require a performance and payment bond will be in the amount of one hundred percent (100%) of the Purchase Order amount.

The Offeror shall provide performance and payment bonds within ten (10) days of the execution of a purchase order covering one (1) year of the purchase order. A new bond for the subsequent year shall be provided by the Offeror within ten (10) days of the anniversary date of the purchase order execution. The bonds shall be a duly executed Standard Performance and Payment Bond payable to the State of Georgia in the amounts specified below and will be a guarantee for the faithful performance of and payment to vendors and sub-consultants providing products and/or services under the contract. The surety of the bond shall be a surety company approved to transact business in the State of Georgia. No purchase order shall be deemed to be in effect until such bonds have been approved by the State of Georgia.

Requirements for the bond amounts are as follows:

1. Repairs of assets and replacement of non-operational and outdated assets purchase orders – performance and payment bond shall be in the amount of one hundred percent (100%) of the purchase order amount.

2. Emergency and optional service Purchase Orders – performance and payment bond shall be in the amount of one hundred percent (100%) of the Purchase Order amount.

Page 6 RFP Document Version 0.5

1.7. Organizational Conflict of Interest

For the Offeror to be considered eligible for selection, the Offeror cannot hold the following contract as the Prime consultant with the Department's Office of Traffic Operations:

Contract ID: 48400-265-TOOTO2100291 (ITS Operations and Support Statewide)

Contract ID: 48400-265-TOOTO2201015 (Traffic Operations Engineering Support Services)

If the Offeror is a Sub to the prime consultant for the listed contract or if the Offeror holds another contract with the Department’s Office of Traffic Operations, the Offeror must provide an attachment detailing the Offeror's role in that contract. The attachment shall be included in the combined single technical proposal document, and it may be used to determine eligibility for selection.

2. Schedule of RFP Events Table 2-1 represents the Department’s best estimate of the schedule that will be followed. All times indicated are Eastern Time (ET). The Department reserves the right to adjust the schedule as deemed necessary.

TABLE 2-1: SCHEDULE OF RFP EVENTS

Event Date Time (ET)

Posting date of RFP by the Department 09/09/2024 As per the GPR

Pre-Bid Meeting (Optional) – Hosted via Teams 09/30/2024 10:30 AM

Deadline for submission of written questions and request for clarifications

10/09/2024 2:00 PM

Technical and Cost Proposals due/close date and time 10/23/2024 2:00 PM

3. Scope of Services The subsequent sections include a detailed scope of services to guide potential offerors in understand the requirements and expectations of the Department. This comprehensive scope delineates the specific needs, objectives, and standards that Offerors should address in their proposals, ensuring a clear and aligned understanding of the desired outcomes.

3.1. Project Description

The Department operates a statewide Advanced Transportation Management System (ATMS). The ATMS receives data from and interacts with Intelligent Transportation System (ITS) devices deployed in the field.

This allows the Department to monitor and control the ITS devices from the ATMS for the benefit of the traveling public. It is imperative that the ITS devices and related components (hereinafter known as the “Assets”) be maintained and operational.

The Department currently outsources the maintenance of its Assets. The services include those related and pertaining directly or indirectly to maintenance, repair, replacement, installation, and management of the Assets, hereinafter known as “ITS Maintenance.” The Department intends to resolicit the ITS Maintenance for a period of five (5) years to a qualified ITS Maintenance provider, hereinafter known as the “Offeror”.

The Offeror shall be responsible for maintaining and assessing operational performance levels of the Assets for the duration of the contract. The work to be performed by the Offeror under this contract shall encompass and include all work, services, materials, equipment, and supplies necessary to provide ITS Maintenance.

Project limits for this procurement shall be defined as the borders of the State of Georgia divided into four

(4) distinct Areas. The four (4) Areas are defined in Exhibit B – Area Definitions. The Offeror shall be

Page 7 RFP Document Version 0.5 responsible for ITS Maintenance in all four (4) Areas. The Department shall notify the Offeror if the counties associated with each Area change for any reason.

For simplicity in referencing the Department’s Assets in this contract, the following asset hierarchy and associated definitions shall apply:

Level 1 – Site: A site is a location or area where technologies are implemented. It is used as the highest level in the Department’s asset hierarchy. The site is often referred to as the "parent" and assets are considered the "children."

Level 2 – Asset Class: Asset class is the second classification level of the Department’s assets. The asset classes to be maintained under this contract shall include, but shall not be limited to, the following:

1. Closed-Circuit Television Camera (CCTV)

2. Communication Network Building (HUB)

3. Connected Autonomous Vehicle (CAV)

4. Emergency Access Gate (EAG)

5. Environmental Sensor Station (ESS)

6. Gate Lift/Swinging System (GLSS)

7. Message Sign (MS)

8. Other (OTHER) for Non-Billable Components

9. Ramp Meter System (RMS)

10. Roadside Access Control System (RACS)

11. Vehicle Detection Device (VDD)

12. Wrong Way Vehicle Detection (WWVD) Level 3 – Asset Type and Component: Asset type is used to divide asset classes based upon the type of the asset. For example, the asset class “MS” may be comprised of asset types such as Dynamic Message Sign (DMS), Variable Speed Limit Sign (VSLS), and Dynamic Lane Control Sign (DLCS).

Related hardware, electronic components, auxiliary and equipment, necessary for the operation of the asset type shall be listed as an asset component. For example, the “DMS” asset type may be comprised of asset components such as the sign controllers, network switch, enclosures, etc.

The asset types to be maintained under this contract shall include, but shall not be limited to, the following:

1. Acoustic Sensing Unit (ASU)

2. Automatic Incident Detection Camera (AID)

3. Barrier Gate (BG)

4. Blank-out Sign (BS)

5. Blank-out Sign associated with Express Lane Access Control System (BSACS)

6. Closed-Circuit Television Camera (CCTV)

7. Communication Network Building (HUB)

8. Continuous Count Station (CCS)

9. Dynamic Lane Control Sign (DLCS)

10. Dynamic Message Sign (DMS)

11. Dynamic Message Sign associated with Express Lane Access Control System (DMSACS)

12. Emergency Access Gate (EAG)

13. Environmental Sensor Station (ESS)

14. Infrared Closed-Circuit Television Camera (IRCCTV)

15. Infrared Detection System (IRDS)

16. Loop Detection System (LDS)

17. Magnetometer Detection System (MDS)

18. Presence Detection System/Fixed CCTV Detection System (PDS)

19. Roadside Access Control System (RACS)

20. Radar/Microwave Detection System (RDS)

21. Ramp Meter System (RMS)

Page 8 RFP Document Version 0.5

22. Roadside Unit (RSU)

23. Variable Speed Limit Sign (VSLS)

24. Video Detection System (VDS)

25. Warning Gate (WG)

26. Wrong Way Vehicle Detection (WWVD) The asset components to be maintained under this contract shall include, but shall not be limited to, the following:

1. Battery Backup System/Uninterruptable Power Supply (UPS)

2. Cellular Router (CR)

3. Decoder (DEC)

4. Dynamic Lane Control Sign Controller (DLCSCTRL)

5. Dynamic Message Sign Controller (DMSCTRL)

6. Data Management Unit (DMU)

7. Encoder (ENC)

8. Human Machine Interface (HMI)

9. Layer 2 Network Switch (L2SW)

10. Layer 3 Network Switch (L3SW)

11. Media Converter (MCONV)

12. Power Distribution Unit (PDU)

13. Remote Lock Controller (REMLCK)

14. Terminal Server (TERMS)

15. Ramp Meter Controller (RMC)

16. Ramp Meter Traffic Signal (RMTS)

17. Ramp Meter Detector (RMD)

18. Variable Speed Limit Sign Controller (VSLSCTRL)

19. Wireless Device (WIRELESS)

20. Wrong Way Detector (WWD)

21. Wrong Way Sign (WWS)

3.2. Maintenance Manuals, Standards, Guidelines, and Procedures The Offeror shall comply with all Manuals, Standards, and Procedures applicable to the project as outlined in this section for the term of the contract. Any variance by the contractor from the manuals, standards, and procedures specified in this section must be corrected through the issuance of an amendment.

3.2.1. ITS Maintenance Standard Operating Procedure

Before Notice to Proceed (NTP) of the first Purchase Order for ITS Maintenance, the Department, external stakeholders, and the Offeror (hereinafter known as the “Parties”) may enter negotiations to come to an agreement on the SOPs for ITS Maintenance. The SOP negotiations will ensure that the Parties have a mutual understanding of the Offeror’s roles and responsibilities; ITS Maintenance operational standards and procedures; and Department and external stakeholder rules and expectations. The SOPs included in Exhibit C – Statewide ITS Maintenance Standard Operating Procedures shall be used as the baseline operational standards and procedures until the Parties come to an agreement. If no agreement is achieved, the SOPs provided in Exhibit C will become the agreed upon SOPs for the contract and NTP may be issued for the first Purchase Order at the Department’s discretion. The Department reserves the right to postpone NTP on the first Purchase Order until a resolution is achieved.

The SOPs will be updated periodically throughout the term of the contract as the Parties’ needs change.

Any changes made to the SOPs shall be mutually agreed to by all Parties. If the Parties cannot come to an agreement on updates to the SOPs, the Department may postpone NTP on any future Purchase Orders.

Page 9 RFP Document Version 0.5

3.2.2. Other Manuals, Standards, and Guidelines

The Offeror is required to conduct all tasks in compliance with the specified manuals, standards, and guidelines, at a minimum, and any subsequent revisions to these documents for the life of the contract:

1. Manual on Uniform Traffic Control Devices

2. AASHTO Publications

3. State and Federal Laws, Mandates, and Regulations

4. GDOT Special Provisions

5. GDOT Standards and Construction Details

6. GDOT Supplemental Specifications

7. GDOT Standard Specifications

8. GDOT ITS Design Guidelines

9. GDOT ITS Asset Standard Naming Guidelines

10. GDOT Site and Fiber Naming Guidelines

11. GDOT Qualified Products List

12. GDOT IT Policies and Procedures

3.2.3. Location of Work

All work and services shall be performed by staff and using computing infrastructure physically located within the Continental United States of America (CONUS).

Maintenance Services work is expected to be performed at roadside locations throughout the State of Georgia.

Department hosted software and system installations will be deployed to hardware residing in Department facilities in Atlanta. The primary facility will be the Statewide Transportation Management Center (TMC) located at 935 United Avenue SE, Atlanta, Georgia 30316.

In person meetings and on-site support are expected to take place at the TMC.

Day to day program support; data maintenance and upkeep; and on-line meetings are expected to be primarily conducted remotely at the Offeror’s facilities or worksites using the Offeror’s equipment and resources. Offeror shall have suitable Internet connection and environment to support remote work.

3.2.4. Travel

All Costs related to travel and subsistence will be the responsibility of the Offeror. The Department will not provide reimbursement to the Offeror for costs related to travel and subsistence.

3.3. General Services

The Offeror shall provide the general services as described in this section. Unless otherwise specified, the Offeror shall include the pricing of the general services in the Offeror’s pricing for Maintenance Services.

3.3.1. Project Management Services

The Offeror shall provide project management services as described in this section. These services include, but are not limited to, reporting, scheduling, executing, and managing the day-to-day activities being performed under this contract as well as coordinating with the Department.

3.3.1.1. Project Kick-Off Meeting

The Offeror shall attend a project kick-off meeting with the Department. The project kick-off meeting will ensure that all parties have a mutual understanding of the contract requirements and Department expectations. The project kick-off meeting will be scheduled by the Department and will be held at the Department’s Transportation Management Center (TMC) located at 935 United Avenue SE, Building 24, Atlanta, GA 30316. The kick-off meeting will be scheduled within twenty (20) calendar days after NTP. The Offeror shall bring, at a minimum, their Project Manager (PM), Deputy Project Manager (DPM), ITS Maintenance Lead (IML), and Information Technology Lead (ITL) to the kick-off meeting. The Department

Page 10 RFP Document Version 0.5 will prepare the agenda and provide meeting notes. All travel and subsistence costs for the Offeror’s attendance at the project kick-off meeting shall be the responsibility of the Offeror.

3.3.1.2. IT Kick-Off Meeting

The Offeror shall attend an IT kick-off meeting with the Department in addition to the project kick-off meeting. The IT kick-off meeting will ensure that all technical parties have a mutual understanding of the contract requirements and Department expectations. The IT kick-off meeting will be hosted as an online meeting and will be scheduled by the Department within twenty (20) calendar days after NTP. The Offeror shall bring, at a minimum, their PM, DPM, and ITL to the kick-off meeting. The Department will prepare the agenda and provide meeting notes. All travel and subsistence costs for the Offeror’s attendance at the kick-off meeting shall be the responsibility of the Offeror.

3.3.1.3. Project Schedule

The Offeror shall submit a baseline project schedule outlining the initial development, testing, training, integration, and deployment tasks as defined in this contract. The Offeror shall submit the baseline project schedule to the Department within twenty (20) calendar days after the kick-off meeting. The baseline project schedule shall include the following:

1. Name of work activity as well as projected start and end dates.

2. Work Breakdown Structure (WBS) to subdivide the project scope to indicate the tasks, deliverables and work packages that are needed to complete the project from start to finish.

3. Dependencies (predecessors and successors) with other work activities in the project schedule.

4. Deliverable drafting and stakeholder review periods.

5. Design, development, deployment, testing, training, and acceptance milestones.

The baseline project schedule shall be delivered in draft to the Department. After receiving the Department’s comments and resolving them, the Offeror shall provide a revised version of the baseline project schedule within fifteen (15) calendar days from receipt of the Department’s comments. The Department must approve and accept all comment resolutions before the baseline schedule is considered approved.

This single baseline schedule shall be updated and delivered to the Department each month, as part of progress reporting against the baseline date, to reflect the percent complete for every work activity, deliverable, and milestone as part of this contract. Any changes to due dates must be approved in writing by the Department.

3.3.1.4. Project Management Plan

The Offeror shall develop a Project Management Plan (PMP). The PMP shall be developed as a draft and delivered to the Department for review and comment. The PMP shall, at a minimum, address the following requirements:

1. Performance Monitoring: The Offeror shall monitor its own performance to ensure that the performance criteria and outcomes are achieved. The PMP shall include procedures to ensure that all work meets or exceeds the performance criteria contained within this scope, attachments, exhibits, and the subsequent contract.

2. Quality Control: The Offeror shall develop and implement a Quality Assurance and Quality Control (QA/QC) process that will allow the Offeror to achieve quality deliverables and work products that meet the Department’s needs. The PMP shall include the QA/QC process that the Offeror will follow for all work products and deliverables.

3. Staffing Plan: The Offeror shall provide designated and appropriate staff throughout the life of the contract. This staffing will include four (4) positions which will be dedicated full time positions under this contract. These four (4) positions shall be:

a. PM

b. DPM

c. IML

d. ITL

Page 11 RFP Document Version 0.5

The PMP shall include a staffing plan that includes staffing levels and an organizational chart depicting the structure, reporting hierarchy, roles, and responsibilities. The Offeror shall ensure that any employee replacement meets or exceeds the qualifications set forth in this staffing plan. For the four

(4) full time positions listed above, the Offeror shall submit a letter requesting approval of the proposed employee replacement and the Department must approve. Field staff shall have relevant licensing and certifications required to complete the work defined herein (e.g., Master Electrician License, OSHA 10- Hour Certification, and OSHA 30-Hour Certification).

4. Communications Management: The Offeror shall develop a communications management plan to be included in the PMP that will define the communication requirements for this project and how information will be disseminated.

5. Additional Project Management Duties: The Offeror shall include the following additional project management duties in the PMP:

a. Document control (i.e., document distribution, change control, approval process, and storage)

b. Human resource management

c. Scope management

d. Contract administration and management (i.e., the management and administration of purchase orders, supplemental agreements, and invoicing)

e. Risk Management

The PMP shall be delivered in draft to the Department no later than twenty (20) calendar days after the kick-off meeting. After receiving the Department’s comments and resolving them, the Offeror shall provide a revised version of the PMP. The revised PMP shall be delivered to the Department within fifteen (15) calendar days from receipt of the Department’s comments. The Department must approve and accept all comment resolutions before the revised PMP is considered approved.

3.3.1.5. Project Update Meetings

The Offeror shall conduct monthly project update meetings. The monthly project update meetings shall be held in person at the TMC. The Offeror’s IML, PM, and DPM shall attend the monthly project update meetings in person. The Offeror may include key personnel and staff in the monthly project update meetings as deemed necessary to provide additional information or explanation for the agenda items. Key personnel and staff may choose to participate remotely.

In addition to the monthly project update meeting, the Offeror’s IML, PM, and DPM shall host a weekly project update meeting (at minimum at the discretion of the Department) via teleconference or in person at the TMC. The Offeror may include key personnel and staff in the bi-weekly project update meetings, as necessary.

The Offeror shall host a teleconference for the project update meetings (both monthly and weekly) so that the Offeror’s key personnel and Department support staff may participate from remote locations. All travel and subsistence costs for the Offeror’s attendance at the project update meetings shall be the responsibility of the Offeror. The Offeror shall arrange the agenda, provide materials one (1) business day prior to the project update meetings, and provide meeting notes within two (2) business days after each meeting.

3.3.1.6. IT Stand-Up Meetings

The Offeror shall participate in IT deployment coordination meetings (hereinafter referred to as “stand-up meetings”). Stand-up meetings are intended to be short meetings (15-30 minutes) for technical team members to report on development/deployment progress, identify potential roadblocks, and facilitate any necessary collaboration. The stand-up meetings will be hosted weekly, at a minimum, via teleconference.

The Offeror’s ITL and technical support staff shall attend the stand-up meetings. The Offeror’s PM, DPM, and other key personnel and staff may attend the stand-up meetings as necessary, but the stand-up meetings are strictly intended to be focused around the highly technical aspects of the project. The Department will facilitate the meeting, but the Offeror is expected to also take notes and coordinate action items.

Page 12 RFP Document Version 0.5

During the software development, deployment, and configuration stages of the project, the Offeror shall utilize the stand-up meetings to coordinate and schedule additional IT meetings and deployment support requests. One such meeting shall be a preliminary architecture discussion to be held after confirmation that the IAMS meets Department requirements.

After the software development, deployment, and configuration stages of the project and during the software operations and maintenance stage, the Offeror shall submit IT support request via email to the Department’s Solution Center (solutionscenter@dot.ga.gov) and copy the Department PM.

3.3.2. ITS Asset Management System

The Offeror shall provide an ITS asset management system (hereinafter referred to as “System” or “IAMS”) through a phased approach. A baseline IAMS shall be delivered by the Offeror and deployed into the GDOT production environment within 120 calendar days from the NTP of the IAMS PO (known hereinafter as “IAMS Phase 1”). The baseline IAMS shall meet, at a minimum, all the IT Policies and Procedures in Section

3.3.3 and shall include the basic functionality necessary for the transition of maintenance services. The basic functionality for IAMS Phase 1 shall include, at a minimum, the ability to configure the asset inventory, the ability to monitor asset performance, and the ability to report for Pay-for-Performance.

Subsequently, the Offeror shall complete the entire IAMS, encompassing all required systems, applications, and components as defined herein (known hereinafter as “IAMS Phase 2”), within 240 calendar days from the NTP date. This phased structure ensures a progressive development process, delivering an initial functional baseline within the first 120 calendar days, preceding the expiration of the previous contractor’s contract, and the fully realized IAMS within the specified 240 calendar day period.

If deemed necessary by the Department, the Department may require the Offeror to utilize the existing IAMS during the contract transition period or for the life of the contract. In such instances, the Department will license and pay for the incumbent contractor’s application separately.

The IAMS shall have an open license with the ability to add unlimited users, including other agencies, departments, consultants, contractors, and other applications/integrations, with no additional licensing fees.

The Department anticipates approximately 100 users including 50 concurrent users at the NTP date of this contract. The Offeror’s staff is not included in the number of anticipated users. The Department shall have full access to all data and privileges within the System provided by the Offeror and the ability to grant this level of access at the Department’s discretion.

The Offeror shall grant the Department a non-transferable, non-exclusive license to use any documentation and graphics during the term of the contract for the Department’s business purposes.

At the end of the contract, the Department shall own the rights to fully use the software instances that are providing IAMS services (including all software enhancements and modifications made to the IAMS during this contract). The Department may choose to license this software publicly, allowing broader utilization beyond the contract's scope. All data, workflows, reports, and records shall be the exclusive property of the Department.

The following sub sections provide the minimum functional, non-functional, and other system requirements for the IAMS. These requirements are not meant to be all inclusive but are the minimum requirements that must be satisfied for the system deployment and acceptance.

3.3.2.1. IAMS Functional Requirements

Table 3-1 lists the functional requirements for the System.

TABLE 3-1: IAMS FUNCTIONAL REQUIREMENTS

Requirement ID Requirement

User Interface (UI)

UI-01 The System shall have the ability to deliver content via a standard web browser (i.e., Google Chrome, Microsoft Edge) mailto:solutionscenter@dot.ga.gov

Page 13 RFP Document Version 0.5

Requirement ID Requirement

UI-02 The System shall provide the ability to display, query, sort, and filter assets and sites statewide in a list.

UI-03 The System shall provide the ability to display, query, sort, and filter geolocated assets and sites along with all their associated data attributes on a map.

UI-04 The System map shall represent each displayed asset and site with an icon/symbol unique for each Asset Type, Asset component, and Site.

UI-05 The System map shall be GIS based, using standard GIS files to render a geographically accurate, to scale map (e.g., shape files, file geodatabases and enterprise geodatabases).

UI-06 The System shall provide the ability to configure GIS layers within the System (e.g., configure Asset Area layers) and display GIS layers from third-party systems (e.g., pull and display County, GDOT District, Congressional District layers from GDOT’s Esri ArcGIS) on the System map.

UI-07 The System shall clearly identify the network environment (e.g., color coding the user interface uniquely for the deployment in the Sandbox, QA, Training, Production, etc.

environments) and version control information.

Asset Management (AM) Supplemental AM requirement information is included in Section 3.3.2.2

AM-01 The System shall utilize a primary key (i.e., Database ID) for each asset and site.

AM-02 The System shall provide the ability to add, exchange, modify, archive, and delete asset and site records.

AM-03 The System shall provide the ability to add, exchange, modify, archive, and delete all data attributes for assets and sites while retaining the record for the modified asset and site.

AM-04 The System shall provide the ability to create an asset hierarchy (i.e., parent, child, and grandchild structure) for sites, asset classes, asset types, and asset components.

AM-05 The System shall provide the ability to manage (add, delete, modify) asset classes, types, and components.

AM-06 The System shall provide a service request (i.e., issue/trouble ticketing) component where users with permission can initiate and track service requests and work orders for all assets.

AM-07 The service request system shall capture the user ID, date, and time stamp of the initial service request.

AM-08 The System shall provide a work order component where users with permission process submitted service requests, generate work orders for assets, modify asset statuses, and record work performed against an asset.

AM-09 The System shall provide the ability for the Department to view, define, edit, and delete workflows for service request and work orders.

Page 14 RFP Document Version 0.5

AM-10 The System shall provide the ability to view and track all active and completed service request and work orders against an asset.

AM-11 The System shall capture the date, time stamp, and user ID for service requests, work orders, and asset status changes (e.g., ticket creation date/time, in service date/time, out of service date/time, disposal date/time, assigned to, ticket closed date/time).

AM-12 The System shall have the ability to link work orders to assets.

AM-13 The System shall have the ability to capture the technician/contractor assigned to the work order and service request.

AM-14 The System shall have a preventative maintenance component where users with permission can track and schedule preventative maintenance activities.

AM-15 The System shall have the ability for technician/contractor to provide a list of parts used for work order.

AM-16 The System shall have the ability to track asset performance data.

AM-17 The System shall have the ability to track the usage of components needed for repairs.

AM-18 The System shall have the ability to track an asset sent for repairs.

AM-19 The System shall provide the ability to utilize tag reading technology (e.g., barcode, QR code, RFID) for asset and site tracking, including tags with serial numbers and other information. Currently, barcodes are used for asset and site tracking.

AM-20 The System shall provide the ability to develop and maintain a spare asset inventory.

AM-21 The System shall have the ability to provide asset status, asset performance data, and the log of work performed against assets on a near real-time basis.

AM-22 The System shall provide a sortable and filterable list of all assets in the System with their asset data attributes.

AM-23 The System shall provide a sortable and filterable list of all sites in the System with their site data attributes.

AM-24 The System shall provide the ability to create and reserve asset names with incomplete asset data attributes for future use.

Change Management (CM)

CM-01 The System shall have the ability for users with permission to manage, update, and track asset statuses.

CM-02 The System shall have the ability for the Department to review (i.e., approve, reject) and edit asset status change requests.

CM-03 The System shall automatically change the asset status if the Department approves the asset status change request.

Page 15 RFP Document Version 0.5

CM-04 The System shall have the ability to manage (i.e., create, update, configure, delete) workflows for the Department to review asset status change requests based on user defined criteria.

Reports and Dashboards (RD)

Supplemental RD requirement information is included in Section 3.3.2.2.2.

RD-01 The System shall have the ability to generate reports based on user-enterable parameters.

RD-02 The System shall have the ability to automatically generate and distribute pre-defined reports to specific users.

RD-03 The System shall provide the capability of generating and exporting the results of dashboards, reports, and queries in different formats including CSV, PDF, TXT, and/or KML/KMZ.

RD-04 The System shall display dynamic graphical and tabular reports as a “dashboard.”

RD-05 The System shall allow the user to filter what data are displayed on reports and dashboards.

RD-06 The System shall allow the user to select the time-period over which the data is displayed on reports and dashboards.

RD-07 The System shall be capable of displaying near real-time data on reports and dashboards.

RD-08 The System shall have the ability for users with permission to build and save ad-hoc queries to report on assets and sites in in the System using one or a combination of different criteria.

RD-09 The System shall allow the user to sort, filter, and modify (e.g., add, move, remove) columns on ad-hoc reports.

RD-10 The System shall support the integration of data stored and managed within the System, allowing users to consolidate information seamlessly.

RD-11 The System shall include the reports and dashboards listed in Section 3.3.2.2.2.

Data Storage (DS)

DS-01 The System shall retain any current and historical data when adding, modifying, or deleting assets, sites, users, or any other configurated information.

DS-02 The System shall collect all user interaction, system collected, and system generated data.

Third Party Interface (TP) Supplemental TP requirement information is included in Section 3.3.2.2.2.

TP-01 The System shall utilize non-proprietary industry standard protocols and data structures to allow other Department systems to interface with the System.

Page 16 RFP Document Version 0.5

TP-02 All data and messages exchanged between the Department systems listed in Section

3.3.2.2.2 and the System shall utilize an open application programming interface

(API).

TP-03 The API shall utilize a robust authentication mechanism to ensure that only authorized systems can make request (i.e., use API keys, Bearer Tokens, OAuth tokens, or other secure methods to authenticate and authorize incoming request).

TP-04 The API utilize a standard request and response format to ensure consistency.

TP-05 The API shall have clear and informative error handling to help other systems understand and troubleshoot issues.

TP-06 The API shall include a logging mechanism to keep a record of incoming requests, responses, and any relevant information.

TP-07 The API shall include rate limiting to prevent abuse or unintended heavy usage.

TP-08 All data exchanges between the System and other Department system shall take place within the same type of network environment (e.g., IAMS Sandbox to ATMS Sandbox; IAMS QA to ATMS QA; IAMS Production to ATMS Production).

TP-09 The System shall notify administrators (i.e., Department users with administrative level permissions) when an interface fails to successfully exchange data.

TP-10 The API shall use Transport Layer Security (TLS) version 1.2 or later as secure API-based methods for encrypting data in transit to accommodate data exchanges.

TP-11 The API shall make all the asset and site data attributes defined in Section 3.3.2.2 available to the Department systems through the System interface.

TP-12 The API shall maintain the nomenclature and data formats during data exchanges with the Department systems.

TP-13 The System shall interface and exchange data with the Department systems listed in Section 3.3.2.2.3.

User Permissions (UP)

UP-01 The System shall have pre-defined user roles (e.g., operator, administrator, view-only) with preconfigured permissions.

UP-02 The System shall allow administrators to manage (i.e., create, delete, suspend, restore, configure) user accounts from the Department’s Directory Services (e.g., Microsoft Entra ID).

UP-03 The System shall allow administrators to assign system roles to system users through the Department’s Directory Services.

UP-04 The System shall allow administrators to manage (i.e., add, edit, remove) individual user's permissions.

UP-05 The System shall provide a mechanism to identify inactive users of the System.

Page 17 RFP Document Version 0.5

3.3.2.2. IAMS Functional Requirement Supplemental Information The following subsections provide supplemental requirement information to provide additional context to the System functional requirements.

3.3.2.2.1. IAMS Asset and Site Data Attributes

The following list captures the asset data attributes required to be tracked, at a minimum, by the IAMS:

1. Asset primary key

2. Asset name

3. Asset class

4. Asset criticality classification

5. Asset area

6. Asset type/component

7. Asset owner

8. Asset maintainer

9. Asset status

10. Asset manufacturer

11. Asset model

12. Asset location data (including, at a minimum, route, mile marker, latitude, longitude, nearest travel lane direction, county, district, relation to reference cross street, reference cross street, street address)

13. Asset location description

14. GIS data (including, at a minimum, route ID, direction, measures, route mile point, reference post, county, GDOT district, congressional district)

15. IP address

16. Software Port

17. Other communication and control parameters

18. Associated asset connections and physical port (e.g., Camera GDOT-CCTV-0001 is connected to

Switch GDOT-L2SW-0001 in Port 1)

19. Photos of the asset

20. Asset installation date

21. Asset serial number

22. Service request number, status, details, and history

23. Work order number, status, details, and history

24. Preventative maintenance history

25. Asset type specific data attributes (e.g., camera stream description).

26. Documentation associated to the asset (e.g., warranty information; service terms; provider and contact information; manuals; as-built drawing for asset and site installations; list of standard tests and specifications by type of asset including the testing device to be used and acceptable test tolerances)

27. Warranty Expiration Date The following list captures the site data attributes required to be tracked, at a minimum, by the IAMS:

1. Site primary key

2. Site identification name

3. Site infrastructure type

4. Site infrastructure attributes

5. Site infrastructure ID

6. Site location (including, at a minimum, route, mile marker, latitude, longitude, nearest travel lane direction, county, district, relation to reference cross street, reference cross street, street address)

7. Communication connection(s) (e.g., fiber, copper, wireless)

8. Power source

9. Power type

10. Power company

Page 18 RFP Document Version 0.5

11. Power company account

12. Power meter number

13. Power point of service

14. Power point of service latitude

15. Power point of service longitude

16. Power pole ID

3.3.2.2.2. IAMS Reports and Dashboards

The Offeror shall closely collaborate on the design and development of the reports and dashboards. The Department expects the Offeror to produce report and dashboard mockups that provide a comprehensive overview of the report or dashboard and describes the tables, configuration, parameters, functions, and output formats that are used for the report or dashboard prior to development for Department approval.

The Reporting module within IAMS shall, at a minimum, offer the following reports, which will be further specified during the collaborative design and development phase:

1. Asset Inventory

2. Site Inventory

3. CCTV Inventory for Video System Configuration

4. Daily Asset Availability

5. Monthly Asset Availability

6. Current Asset Status Summary

7. Historical Asset Status

8. Work Order History

9. Preventative Maintenance History

10. Active Work Order Status

11. Problem Asset Inventory

12. User Activity The Dashboard module within IAMS shall, at a minimum, offer the following visualizations, which will be further specified during the collaborative design and development phase:

1. Work Order Summary

2. Asset Status

3. Asset Availability

4. Asset Manufacturer and Model

5. Asset Alerts

6. Work Order History

7. Preventative Maintenance History All data attributes tracked and stored in the IAMS shall be available for ad-hoc reporting including, but not limited to, current and historical:

1. Asset data attributes.

2. Site data attributes.

3. User interactions.

4. Configuration information.

5. System collected data.

6. System generated data.

3.3.2.3. IAMS Third Party Interfaces

The Offeror shall clearly design and document an IAMS API for integration with Department systems. The Department prefers that the Offeror utilize the latest OpenAPI Specification (Version 3.0.3 or later) to define and document the IAMS API. If the OpenAPI Specification is used, the IAMS API documentation will be subject to validation checks for compliance with OpenAPI Specification (Version 3.0.3 or later). The Offeror shall ensure that their documentation passes validation using standard OpenAPI validation tools. If the

Page 19 RFP Document Version 0.5

OpenAPI Specification is not used, the Offeror shall provide an Interface Control Document as specified in Section 3.3.2.4.4.

IAMS shall be required to interface and efficiently exchange data with the following Department systems, at a minimum:

3.3.2.3.1. Advanced Transportation Management System

The Department’s ATMS, currently Parson’s iNET, is used by the Office of Traffic Operations (OTO) to manage the impact of roadway events on Georgia’s roadway network using ITS assets. The IAMS API shall allow the ATMS to retrieve and sync ITS asset data attributes with IAMS; monitor IAMS for ITS asset data attribute changes; and provide the ability to view and generate service requests on ITS assets from the

ATMS.

It is anticipated that both IAMS and the ATMS will use the same primary key for each asset, or they will be linked. The ATMS will only consume ITS asset data attributes from IAMS for the ITS assets configured in the ATMS (i.e., the ATMS will not gather or display information for ITS asset components such as encoders, terminal servers, or layer 2 switches). The following list captures the asset data attributes required to be made available to the ATMS, at a minimum, by IAMS:

1. Asset primary key

2. Asset name

3. Asset type

4. Asset owner

5. Asset maintainer

6. Asset status

7. Asset manufacturer

8. Asset model

9. Asset location data (including, at a minimum, route, mile marker, latitude, longitude, nearest travel lane direction, county, district, relation to reference cross street, reference cross street, street address)

10. Asset location description

11. IP address

12. Port

13. Other communication and control parameters

14. Service request number, status, details, and history

15. Asset type specific data attributes (e.g., camera stream description)

16. Other properties to be determined during interface development.

The ATMS will be able to initiate a service request to the System through the interface. The ATMS will populate the service request with Username, Asset Database ID, Asset Name, and Note. The System will return a Service Request Number, Service Request Status, Date/Time Service Request Opened, Number of Days Down, and Notes.

3.3.2.3.2. Fiber Asset Management System

The Department’s Fiber Asset Management System (FAMS), currently NexusWorx, maintains a detailed inventory of all the Department’s fiber and power asset and site information and stores documentation related to the Department’s fiber optic and power networks. FAMS is used for network design, planning, and maintenance of the fiber optic and power networks.

It is expected that FAMS will exchange ITS asset and site data attributes with IAMS. It is expected that both IAMS and FAMS will use the same primary keys for each asset and site. The following list captures the asset data attributes required to be made available to the FAMS, at a minimum, through the IAMS API using the asset primary key (database ID):

1. Asset name

2. Asset type/component

3. Asset owner

4. Asset maintainer

Page 20 RFP Document Version 0.5

5. Asset manufacturer

6. Asset model

7. Asset location data…