As Seattle’s transit advocates, we often like to brainstorm about transit infrastructure because it generates discussions. It helps define what the region wants, and these discussions often drive politics. Light rail connections, BRT, and a second downtown tunnel are just some highlights of an ever-growing wish-list.
However, our focus on modes and infrastructure also leads us to overlook the actual objectives of these transit investments. We ask ourselves whether we want light rail and BRT, but rarely do we emphasize, “How quick and reliable should the system to be?” or “What is this system trying to accomplish?”
As a result, transit advocates are often surprised by operational deficiencies late in the process, leading to reactions like this:
“We have supported RapidRide and BRT from the beginning but Metro and the Council have let ‘BRT creep’ and politics take over, not what is best for riders. When RapidRide C and D lines open on October 1st we’ll have a glorified shiny new bus that is slower than existing service.” – STB
Part of the reason is because specific objectives are not clearly defined before transit is built. There were never defined travel times or reliability requirements from the beginning. We simply said “Build BRT” and assumed that everything would work out. As a result, decision makers have leeway to push for more infill stations to satisfy a few constituents, because why not? There was no legal requirement for what the actual travel time between A and B should have been. It’s easy to backtrack and modify service objectives that were never well-defined in the first place.
On the other hand, if we had defined our objectives as, “The BRT system shall travel between Aurora Village and Downtown Seattle in 35 minutes, at 90% punctuality within 10 minutes of the scheduled time”, and made them project requirements from the beginning, the results may have been different.
I can’t speak for all engineers and planners, but I would suspect that most (myself included) would not only prefer clear objectives to accomplish, but also more defense against backtracking due to political pressure. If decision makers want to satisfy a few constituents with an infill station, clearly-defined project requirements would provide more leverage to say, “Adding this infill station would breach the project conditions, unless there was more funding for a bus-only lane.”
I’ve been using BRT examples, but this applies to rail as well. If we had defined that we wanted a regional rail network with a 40-minute connection between Everett and Seattle, we could say that the currently proposed half hour travel time between Lynnwood and Everett is far too slow. However, we specified little more than the fact that we wanted a train. In the end, we got light rail, which takes 7 minutes to travel 1.3 miles through Downtown Seattle and is proposed to spend an hour between Westlake and Everett (28 minutes to Lynnwood and 30 more to Everett).
This pattern needs to change, and we can start by modifying our planning process: Define specific and realistic service objectives, reach a consensus with agencies, and make the objectives part of the project requirements.
Including specific preconditions into the discussion process, enforcing them and defending them against negative political interests will make the outcomes of our transit investments more predictable. After all, transit should be built to achieve mobility goals, not just for the sake of building it. Let’s take a look at how we can add these objectives to our discussions.
A few examples for defining objectives
Service objectives should be defined before the infrastructure. These should be specific, measurable and realistic, rather than general descriptions such as “improve reliability”.
Here are examples of what specific objectives could look like (with fictitious numbers):
- Travel times (e.g. West Seattle to Ballard within 30 minutes)
- Reliability (e.g. 95% punctuality between West Seattle and Ballard, where a vehicle is on-time when it arrives within 5 minutes of scheduled time)
- Frequency (e.g. Provide the capability to run trains at 90-second frequencies)
By specifying these objectives in our discussions, we can begin a dialogue with agencies to determine whether they are realistic. Once a consensus has been reached and the objectives determined, there should be a method to enforce these objectives, giving agencies more leverage to ask for funding or defend against political interests. Service objectives would then determine the infrastructure, such as whether surface options would even be worth considering.
We would then hopefully be presented with several alternatives that, more or less, satisfy our objectives, rather than receiving a smorgasbord of varying options with questionable operational effectiveness and then collectively wailing. In the end, we may also save ourselves from wondering what the infrastructure is actually capable of.
Moving forward with our discussions
Setting clear quantifiable objectives in cooperation with our agencies will help them better determine what people really want from transit investments. Providing means to enforce these objectives will give agencies more leverage to push back against political influence. With potentially billions in transit investments around the corner and discussions about to begin, we need to refine how we plan transit. After all, why vote for and throw money at projects without fully knowing what they’re trying to accomplish?
As we move forward, discuss and define the travel times that regional rail or urban rail should provide, not whether we should build light rail. Discuss and define the reliability that BRT should provide, not whether we should have bus lanes. The infrastructure (and funding) should be decided only after it is known what will be accomplished. By setting service objectives earlier in the process with agencies and turning those objectives into requirements, we may actually get the system that we expected to get.