Transit Agency Operations Software Problems: The 7 That Cost Overtime and Grievances, and How to Avoid Them

Why does the labour agreement get treated as a detail instead of the specification?

Nearly every transit operations project is scoped from the visible artefacts: the runcut, the vehicle assignments, the daily board, the reports. Those are all real and they are all downstream. The document that actually determines what your operation costs each day is the collective bargaining agreement, and it is rarely read by anyone technical before a number is quoted.

This is specific to transit because the agreement is not policy, it is arithmetic. Spread time penalties, the guarantee, report and travel allowances, the rules on who may be held over and for how long, the sequence in which the extraboard is offered open work, and what happens when nobody accepts. Every one of those converts directly into money on a given morning, every one is negotiated locally, and every one changes on a contract cycle. A developer who has not read the work rules articles is quoting a scheduling application and will meet transit halfway through your budget.

The fix is procedural and it costs nothing. Send the agreement before you take quotes and require the questions back in writing. A team that has done this returns asking about spread penalty calculation, guarantee mechanics and the offer sequence for open work. Then require work rules to be held as versioned configuration with effective dates, and require the ability to run a proposed new agreement against last month's real assignments to see the cost difference before it takes effect. That single capability is worth more at the next negotiation than any dashboard.

What goes wrong when you migrate runcuts, seniority and leave balances?

The data that has to move is spread across systems that were never designed to agree. The runcut lives in your scheduling product. The seniority list lives in human resources (HR), usually in a spreadsheet maintained by one person, and it carries exceptions: operators who transferred divisions, operators who broke service and were reinstated, operators whose seniority date was adjusted by a settlement years ago. Leave balances live somewhere else again, often in payroll, and they reconcile to the day only at period end.

The migration failure is not technical, it is that these three sources disagree and nobody has ever been forced to resolve them. Load them as found and the pick engine will offer work to the wrong operator in the wrong order, which is the one error transit software cannot survive politically. Operators will trust the system exactly as far as the first seniority mistake.

Reconcile before you load, with the union in the room. Publish the seniority list the system will use, in order, and let it be challenged before go live rather than during a pick. Do the same with qualifications and licence expiry, since a system that offers work an operator is not qualified to hold creates a safety problem rather than an inconvenience. Treat leave balances as read from payroll rather than owned by the new system for the first year, because two systems computing the same balance differently is a dispute generator you do not need while everything else is new.

Why do the vehicle, farebox and payroll integrations break after launch?

Vehicle location, passenger counters and fareboxes are three different problems, from three different suppliers, on a moving vehicle. The failure modes are not the ones a developer sees in a lab: a bus sitting in a yard with no cellular coverage, a unit that logs on with the wrong operator identifier because the driver typed a digit wrong, a vehicle swapped mid day so the location feed reports the wrong run, a device that stops reporting after a battery disconnect during maintenance and comes back weeks later.

Payroll breaks differently and matters more. Agencies commonly run older payroll systems that need file based interfaces, and the interface works until a pay code changes, a new premium is added by the contract, or a period boundary lands awkwardly. When payroll export goes wrong, operators are paid incorrectly, and operator trust in the whole system is gone in one pay period regardless of how good dispatch has become.

Build the reconciliation before the integration is considered done. Payroll export needs a line by line reconciliation report your payroll team runs each period against their own totals, not a file that is assumed to be right. Vehicle feeds need an expected reporting interval per unit with alerting when a vehicle goes quiet, and a clear rule for what happens to adherence and delivered service data when the feed is absent. Never let a missing feed silently become an on time trip or a zero.

What happens when federal reporting definitions are not covered at capture?

Formula funding depends on data reported to the National Transit Database, and the definitions are specific. Revenue hours and revenue miles are not pull out to pull in. Deadhead is not revenue service. Passenger miles carry sampling requirements. A dropped trip changes the service actually delivered and should change the number.

If the system records assignments but not actual pull out, pull in and trips operated, then the federal figures are reconstructed afterwards from a scheduled runcut, an odometer report and a counter feed nobody fully trusts, adjusted by a person who understands the definitions. That reconstruction is where agencies quietly under report delivered service, and it is the point at which you can no longer defend your own numbers in a review. The reporting module is not the problem. The capture is.

Capture at source and treat the definitions as a reporting layer over a clean event log. Dispatch records the actual assignment, the actual pull out and pull in, and the trips actually operated, including dropped and short turned trips as operational events rather than as corrections. Revenue hours then become a derived value with a lineage back to individual trips, so when a reviewer asks how a figure was produced you show the trail rather than a spreadsheet. Do this in the first release. Retrofitting capture into a system that only recorded plans means rebuilding the core.

Should you build custom or configure what you already own?

If your problem is that your schedule is inefficient, buy Optibus and stop. It is genuinely strong at generating an efficient runcut and no custom build will beat it at that. If you operate under roughly 50 peak vehicles on fixed route only, with a simple bargaining unit or none, and no complementary paratransit obligation of any scale, a scheduling product plus a modest dispatch tool is the right spend and a custom build would consume capital that belongs in service hours.

Trapeze Group, Init and Clever Devices are all real products with real strengths, and Init and Clever Devices in particular know vehicle systems and passenger counting better than a bespoke team will. The gap in all of them is the same and it is structural: none can express your specific labour agreement, because that agreement is local and changes every cycle, so the plan the software produces still gets turned into reality by a human applying rules the software does not hold.

The pattern that works for most agencies is not replacement. Keep your scheduling product, import the runcut from it, and build the operations layer around it: eligibility ordered coverage, projected premium per option, reason coded deviations, clean capture of delivered service. That is the $90,000 to $180,000 first release over 12 to 18 weeks, and most of the recoverable daily premium leak is inside it. Build the pick engine, real time adherence and the operator portal afterwards, once dispatch is proven at 4am.

How do hidden costs get into the quote?

Bargaining units are first. Two unions means two rule sets, two picks and two sets of edge cases, and a quote written for one does not scale linearly to two. Say how many you have on the first call, including maintenance and supervisory units if they touch the same operator or work records.

On vehicle hardware, the hidden cost is not the integration, it is the field validation. Reading a location feed in a test environment takes days; proving it against real buses in real dead zones, with mid day vehicle swaps and mistyped operator logons, takes weeks and needs someone from operations riding along. Budget that as real cost. Paratransit is the third: complementary service under the Americans with Disabilities Act is a genuine scheduling optimisation problem, not a variation on fixed route, and folding it in mid project is where timelines double.

The fourth is the parallel run. Two to three weeks of running the new process alongside the old one is where the unwritten rules surface, and it needs supervisory time that nobody put in the plan. Name the bargaining units, price each vehicle system separately, keep paratransit out of phase one unless it is the reason you are building, and put the parallel period in the schedule as a funded activity.

What separates a build that works from one that fails here?

The builds that work start at the dispatch window at 4am and work outward. The ones that fail start at a management dashboard and work down, and they get abandoned because the dispatcher never adopted them and everything upstream depended on the dispatcher's data.

Ask a candidate developer how they will handle a contract change mid build, because you will have one. The right answer involves effective dated rule versions and the ability to replay last month's actual assignments under the new rules to see what changes before the agreement starts. Ask what they have integrated on an actual vehicle, by supplier and protocol, and ask what broke. Ask how the system behaves when a vehicle feed is missing, because the wrong answer quietly corrupts your federal numbers. Ask how payroll reconciliation works, since that is the integration that decides whether operators trust anything.

Settle ownership in the contract rather than in a conversation: the repository, the cloud infrastructure accounts and the unrestricted right to hire another firm. For a public agency running a system that produces federally reported figures, your board will reasonably expect that in writing. Then do the homework that sizes the problem honestly: take last week's coverage decisions, price each one against the cheapest legal alternative, and total the difference. That number, annualised, is your business case, and it is usually larger than the build.