Technology Advisory & Systems Engineering for Transit & Transportation
Technology Advisory and Systems Engineering for Transit and Transportation Agencies
Requirements, architecture, procurement, and oversight support for agencies buying fare, scheduling, and traffic systems under federal rules.
A transit agency may replace its fare collection system once in a working career. The vendors bidding on that work have delivered dozens. The same asymmetry appears on the roadway side, where a traffic engineering division upgrades central signal management software and several hundred field controllers on a cycle measured in decades. In both cases the agency's project manager is usually an operations, planning, or engineering professional carrying the procurement alongside a full time job, and the decisions that will be hardest to reverse get made early, before anyone has written a requirement down.
Federal funding raises the stakes. Grant money from the Federal Transit Administration carries the federal uniform grant procurement rules and FTA's third party contracting guidance, which shape how specifications may be written, how competition must be conducted, and what cost or price analysis the agency has to document. Deployments of intelligent transportation systems using federal highway funds fall under FHWA rules calling for a systems engineering analysis and consistency with the applicable regional ITS architecture. Those requirements are not paperwork layered on top of good engineering. They describe good engineering. The practical problem is that agencies are asked to produce the artifacts without systems engineering capacity on staff.
What these environments look like
- Fare collection moving from magnetic and smart card media toward account based systems, contactless bank card acceptance, and mobile ticketing, with vending machines, onboard validators, and payment card industry scope attached
- Scheduling, runcutting, computer aided dispatch, and vehicle location systems supplied by a small number of specialized vendors, each with its own data model and integration terms
- Central traffic management software and field devices communicating over NTCIP standards, in cabinets of widely varying age, across a network that mixes agency fiber, leased circuits, and cellular
- Regional interoperability expectations: a fare instrument that has to work across neighboring operators, or signal coordination along a corridor that crosses several jurisdictions
- Federal grant conditions covering full and open competition, Buy America, disadvantaged business enterprise participation, and thresholds that determine which procurement method applies
- Capital programs tied to grant obligation and expenditure schedules, so procurement delay carries budget consequences, not just schedule consequences
- A small internal technology group focused on keeping the agency running day to day, with nobody assigned to write specifications or oversee a vendor delivering a multi year system
Where HQT helps
- Concept of operations and requirements development with operations, maintenance, finance, and customer service staff, written so that each requirement can be tested and traced through to acceptance
- Systems engineering documentation for ITS projects, structured to support the analysis federal rules expect and to reflect the regional architecture, rather than assembled after the design decisions are already made
- Architecture and integration design across fare, scheduling, vehicle location, traffic, financial, and reporting systems, including the interfaces and data standards each connection uses
- Solicitation development: statements of work, functional specifications that avoid unduly restrictive or brand locked language, evaluation criteria, scoring guidance, and demonstration scripts built from the agency's own service scenarios
- Vendor evaluation support, including technical scoring, structured reference checks, clarification questions, and analysis of proposal assumptions that otherwise reappear as change orders
- Owner's technical representative services during implementation: design and deliverable review, factory and site acceptance test witnessing, and technical analysis of change requests before they are priced
- Independent verification and validation, with test cases traced to requirements, findings reported by severity, and go live readiness measured against criteria agreed before the schedule came under pressure
How an engagement usually starts
Work of this kind usually begins at one of three moments. A fare system reaches end of vendor support and the agency has to decide between an upgrade path and an open procurement. A grant award arrives with an obligation deadline and a scope that was written at the application stage in a single paragraph. Or an implementation is underway and the agency has no independent read on whether the vendor's deliverables meet what the contract requires.
The first step is the same in each case: read what already exists. That means the current contracts and their acceptance terms, the interface documentation for the systems the new one has to touch, the regional ITS architecture if the project is on the roadway side, and the grant conditions attached to the funding. Interviews with dispatchers, operators, maintenance staff, and the finance team follow, because the requirements that get missed are almost always operational rather than technical. From there the work takes the shape the situation calls for, whether that is a concept of operations, a set of requirements and a draft solicitation, or a verification plan for a project already in flight. HQT does not resell the platforms it helps agencies evaluate, and does not bid as an implementer on solicitations it helped write. That separation is stated in the engagement agreement, because in a federally funded procurement an organizational conflict of interest is not only an ethical question, it is a protest risk the agency has to be able to answer.