WMATA to bidders: don’t innovate with real-time signs

Last week, I asked if WMATA would entertain the idea of using a modern, open-architecture, open source system to power real-time signs at Metrobus stops. Unfortunately, I can now conclusively say that that will not be the case. When I first read the RFP, WMATA had yet to post the complete technical specifications. They’ve now updated the RFP with the complete technical specifications (albeit in an inaccessible, untagged PDF which is itself a scan of a printout).

The specifications state, in part:

Because of the criticality of meeting the firm deadlines, WMATA wants only to procure standard, proven products, from a Vendor with successful existing and fully operational implementations, in multiple transit agencies.

WMATA specifically does not want to assist a Vendor in developing new products for its product line for this RFP.

Furthermore, WMATA wants to select a Vendor that has clearly made a long-term commitment to providing contemporary customer information systems to the transit industry.

So, that’s that. I could go on at great length about how MTA New York City Transit’s success with OneBusAway, and how we could do the same for real-time signs, but I’ve already made that argument.

I’ve long known that WMATA is an agency which is deeply suspicious of change and innovation, and it pains me to see the agency continue to behave in ways that are manifestly counterproductive and which will in all likelihood only deepen the agency’s budget deficit.

The RFP requires delivery 90 days after the contract is awarded. MTA New York City Transit spent a lot longer than that on the OneBusAway pilot which lead to the present BusTime implementation. Naturally, I’m curious as to why the timeline is so tight. Considering the interjurisdictional coordination required to install things at bus stops, the testing required by WMATA, etc., I wonder if it’s even feasible for a major vendor to meet that timeframe. It might take longer than 90 days to productize something like the Mobility Lab’s existing work, but I sincerely think the payoff is there, in terms of up-front cost, long-term maintainability, innovation and quality.

We’ve already seen what happens when you choose the established vendor with a “long-term commitment”: you get a mess, like Montgomery County did with its bus passenger information system (more on that here). It’s time for a different approach.

7 thoughts on “WMATA to bidders: don’t innovate with real-time signs”

  1. I think you might be overly critical on them. There are off-the-shelf signs that can pull down XML and display it. In the transit context, going that route IS innovative– you don’t have to build it up from the circuit board level to get something up and running. The open API will allow the vendor to bring in their COTS product and demo it straight away.


    1. Well, being critical of WMATA is the fashion around here. But, in all seriousness, I agree with you that a COTS product that uses open APIs is better than one that uses proprietary protocols. Of course, the use of open APIs says nothing about the product’s overall quality; just because there’s an open API, the product may still be the usual half-baked stuff WMATA gets stuck with.

  2. I suspect the short timeline might be due to the fact that the money for the project is from a federal grant. Many federal grants have deadlines by which the money must be spent.

    1. If that’s true, then that’s a real shame. Riders shouldn’t have to suffer with something that is rushed out the door just to meet bureaucratic requirements.

      Take the time to do it right the first time, and everyone will benefit in the long run.

  3. I disagree.

    Given how little WMATA is actually able to innovate and make things work the way they should, I think it is best if they can actually use a system that has already been implemented, that is good, and provides what people need instead of a half baked system that has major issues working and that cost a hell of a lot more to implement properly!

    1. In case I have not made myself clear, it is not my intention that WMATA do the innovating itself—that is not something I would trust them with. But I would like to see them enable innovation.

      Your implication that a system that has already been implemented will necessarily work properly is not borne out by experience. It is quite common for a transit authority to procure (for example) a passenger information system from a large, supposedly reliable vendor, and find that the system is launched months, or even years late, and only after many, often expensive, change orders. Meanwhile, the agency’s budget deficit grows as the agency pays for consultants to report on the vendor’s progress, and then consultants to audit the first round of consultants, and so on and so on…

      This is how these companies operate: they are slow to adapt and slow to deliver, but they know that the present contracting model enables them to (more or less) behave that way with impunity. The worst that happens is that they are sued for breach of contract, which tends to be seen as part of the cost of doing business.

      So, when a startup comes along—a startup that is actually passionate about changing how things work and genuinely improving the experience of the riding public—with a modern product and agile development practices which make it feasible for them to adapt and improve their product in a matter of weeks or months, not years, policies like WMATA’s end up hurting everyone.

      Buying the expensive, stiff, inflexible product (that probably looks like it’s stuck in the 1990s) just because it has a proven track record isn’t sound contracting practice; it’s indicative of the agency’s usual fear of innovation, the future, and anything that might actually help riders.

Comments are closed.