Benjamin Kabak

A few weeks ago, I first linked to The Atlantic’s lengthy piece on New York City Transit’s technological woes. At the time, I examined the trial and tribulations of bringing communications-based train control online and highlighted how the MTA’s current approach is both impossible to sustain and inefficient in its execution. It is the classic story of a large and conservative bureaucracy unable to adapt to technological change, let alone a fast pace of adaption.

Let’s dive back into the piece and explore the countdown clock conundrum. As you may recall, James Somers initially set out to write about why only the A Division subway lines — the numbered routes — have countdown clocks while the B Division trains — the lettered lines — do not and will not for the foreseeable future. He also wants to understand why the A Division countdown clocks arrived years late. It is, he writes, “the story of a large organization’s first encounter with a large software project.” As you can imagine, it hasn’t gone particularly well for the MTA.

First, Somers notes that Automatic Train Supervision, the project that allowed the MTA to introduce countdown clocks on the A Division, is a subset of CBTC, and had the agency better coordinated and understood technology, they wouldn’t have spent 14 years installing an interim solution. The story goes south from there:

A post-mortem by the Federal Highway Administration details how from the start, an agency which had had little experience with large “systems” projects tried to wing it. For instance, the consulting firm tasked with developing the project plan never made a list of requirements, didn’t talk to the workers who would be maintaining the system until after it was designed, and left vague instructions for large chunks of work—specifying, for instance, “similar functionality to what is currently available”—that later became the focus of drawn-out contract disputes.

The MTA thought that they could buy a software solution more or less off the shelf, when in fact the city’s vast signaling system demanded careful dissection and reams of custom code. But the two sides didn’t work together. The MTA thought the contractor should have the technical expertise to figure it out on their own. They didn’t. The contractor’s signal engineer gave their software developers a one-size-fits-all description of New York’s interlockings, and the software they wrote on the basis of that description—lacking, as it did, essential details about each interlocking—didn’t work.

Gaffes like this weren’t caught early in part because the MTA “remained unconvinced of the usefulness of what seemed to them an endless review process in the early requirements and design stages. They had the perception that this activity was holding up their job.” They avoided visiting the contractor’s office, which, to make things worse, was overseas. In all, they made one trip. “MTA did not feel it was necessary to closely monitor and audit the contractor’s software-development progress.”

The list goes on: Software prototypes were reviewed exclusively in PowerPoint, leading to interfaces that were hard to use. Instead of bringing on outside experts to oversee construction, the MTA tried to use its own people, who didn’t know how to work with the new equipment. Testing schedules kept falling apart, causing delays. The training documentation provided by the contractor was so vague as to be unusable.

The MTA’s attempts at bringing the ATS system to the larger B Division faltered three times during the first decade of the 21st Century, and instead of trying to speed up the pace of installation of the CBTC system which would, as an ancillary benefit, introduce countdown clocks systemwide, Transit is again looking at a piecemeal solution. Again, it’s not working.

As we now know, the MTA doesn’t anticipate completed the installation of the Integrated Service Information and Management system on the B Division before 2020. An original deadline of 2017 was deemed unrealistic, and the delay in capital funding pushed this project back to the next five-year plan. And here’s the rub:

The problem is that the project has slowly taken on a bigger and bigger scope. The minutes of a 2012 Capital Program Oversight Committee meeting reveal that initially, the project’s focus “was to provide Train Arrival Information in stations.” Several service incidents, including a winter storm, drove the MTA to “re-focus project priority to provide centralized service-monitoring and information… followed closely by customer information.”

It is growing to look more and more like ATS. A request for proposal as recent as six months ago—back when funding looked more secure—called for a 77-month software contract to build out a sophisticated Rail Traffic Management System as part of ISIM-B. That piece of the project is envisioned as a complex centralized “expert system” that would allow operators to quickly diagnose service problems and would intelligently suggest ways to work around the disruption. It is, in a word, ambitious. And ambition is the death knell for big software projects. It’s what made ATS such a quagmire in the first place. It is, one suspects, why funding for countdown clocks has been cut from the latest capital plan: The rest of ISIM-B costs too much. It costs too much because it is trying to do too much. The consequence being that for five or six years, customers will hardly see anything get done at all.

At this point, Somers comes up short on a solution. He properly cites to BusTime, the MTA’s greatest software success story, as an example that the agency has had a few people at various times with the ability and trust to do something in-house. But those involved in the original creation and implementation of BusTime have long left the MTA, and Jay Walder, the CEO who was willing to give BusTime a shot, was forced out over his apparent lack of political savviness in dealing with both Albany and the TWU.

So what comes next? Certainly not countdown clocks on the B Division trains any time soon, and certainly not much faith that the MTA can execute complex technology upgrades in a timely or efficient manner. The MetroCard replace is on tap and could suffer from the same fate. Meanwhile, everything is years late and millions of budget. When it’s going to take the better part of a century to bring CBTC to the entire subway line, in the end, do we have any real hope that, without a top-to-bottom organizational overhaul, the MTA can execute on projects that are standard throughout the world? I’m not sure anyone really likes the answer to that question.