Oddly, however, BART’s Web Services Manager Tim Moore remembers the day — at least from a Web standpoint — being fairly calm. Moore said records show that on Nov. 22, between 7 a.m. and 8 a.m., BART.gov handled more than 20,000 unique visitors due to a major service delay in transit operations. The number represented an impact to the site that was roughly 11 times greater than normal for the hour, a time that typically averages only 1,800 visitors.
This success, which Moore describes as a “trial by fire,” led to a quiet celebration that day as the news media focused their attention on commuter delay updates and the ongoing union dispute. The website’s strong showing and the secret behind its speedy development strategy is noteworthy, not simply within the framework of organizational accolades, but also in the way of lessons learned — lessons that began on day one.
A Surprise Announcement
At the beginning of January 2013, Moore said BART received a startling notice from Adobe, the site’s content management system provider. BART’s Web team was told that by the end of 2013, Adobe Publish, the site’s former content management system, would be phased out entirely.“That meant that we’d lose all of our Web site publishing capabilities, our editing capabilities and maintenance capabilities in less than a year,” Moore said. “So effectively, that’s when the stopwatch started.”
The tight time frame to launch a new website gave BART’s team one month to get through the process of internal evaluation on site design, budgeting, procurement and contracting, then just four months for actual Web development.
“It was no small task getting a public agency like this moving,” Moore said, and credited Ravindra Misra, BART’s CIO, for his quick response, as tasks were immediately delegated and stakeholders called in for feedback.
One of the most game-changing decisions made during the first month, Moore said, was choosing a new content management system, one that was easy to use and yet customizable enough to accommodate BART’s enterprise-level needs. Tasked by Misra to spearhead site development, Moore set about evaluating content management platforms, conducting user interviews, and reaching out to like-sized transit agencies for advice.
Like this story? If so, subscribe to Government Technology's daily newsletter.
In the end, Moore said, “Drupal emerged at the top of the list,” for it’s ability to be managed in-house, its estimated longevity and the backing of a large open source developer community behind it — and BART opted for many sources for future maintenance and support.
'One Throat to Choke'
If there was one thing to be avoided under BART’s strict deadline, it was finger pointing and accountability shirking. In the often labyrinthian workings of large-scale Web development projects, Moore said it's common to see one team of developers pointing to the other when problems arise from compatibility issues, site feature requests and hosting snags.Based on BART’s decision to choose Drupal, Moore said, Acquia — a commercial open-source software company providing products, services, and technical support for Drupal — appeared the most logical choice to avoid this challenge.
“That’s your classic one-throat-to-choke method,” Moore said jokingly. “On a project like this, we really wanted to minimize the number of project partners, or integrators, we were working with.”
Similarly, Moore said, he was that “throat” for Acquia’s developers. He said that considering the looming deadline, it was important that there be one point man for decision-making tasks versus a variety of stakeholders with varying levels of approvals.
“We were really trying to focus on the important thing of launching the new site and getting something that we could use going forward,” Moore said.
This tactic was also included within the initial month BART had for site collaboration. Moore explained that all suggestions for site features had to be finalized within the first month so the scope of the project could be maintained. Anything that the team determined to be a “launch blocker,” a feature or process that may prevent meeting the deadline, was cut from the scope of the project.
Hard Things First
The last big lesson learned from the experience, Moore said, was doing the hard things first, including those objectives that may require more time. Many of these tasks relate to integration issues, such as allowing BART’s trip planner connected to Google Maps to be compatible with the new site.Jessica Richmond, senior director of government professional services at Acquia, said this and the many other difficult tasks were done through resourcing them simultaneously into multiple teams.
“We have a lot of expert talent both internally and through our partner network that we could tap into," she said. "So we we’re very, very diligent in determining the right roles to play from a development standpoint."
Worst case scenarios were also run, such as high volume traffic spikes scenarios, to ensure preventative measures were in place.
“For BART, one of the examples we used was what would happen if there was a strike and people needed to know what was going on with the trains,” Richmond said. “We prepared so much for that situation, even on the short timeline, and the infrastructure of the applications were so high performance that there were absolutely no issues. The most exciting thing about that day was that there was no excitement at all.”
