SmarTrip office didn’t communicate “use it or lose it,” delays, or contract changes

Metro will put a band-aid on the problem of SmartBenefits going back to the employer at the end of the month by letting employers opt out of the new SmartBenefits arrangement and stick with the current system.

Under the current system, an employee “claims” SmartBenefits by downloading them onto the SmarTrip card at a fare machine. Any unclaimed benefits will go back to the employer at the end of the month, but if the employee has downloaded it all and not used every dollar, they can roll over the rest to the following month. Starting January 1st, riders will no longer have to download SmartBenefits, but any unused (not just unclaimed) benefits will go back to the employer.

For federal employees, that’s the desired behavior. According to RAC members who work for the federal government, it’s considered fraud to use even a dollar of “October” benefits in November, for example. Since federal employees get free transit, it’s also not a big deal if the benefits go back at the end of the month; an employee who uses more or less transit from month to month could simply request an amount on the high side and give back whatever doesn’t get used.

The problem arises for employees who make a pretax deduction. If unused benefits go back to the employer, the employer has to make sure that money gets back to the employee, which could be very complex. Therefore, Metro has decided to let employers opt out of the new system, retaining the rollover capability while also requiring employees to still claim SmartBenefits at machines as they do today and not using the “bins” at all. In the longer term, they plan to modify the SmartTrip system to accommodate both non-rollover and rollover options.

This issue seems to have caught SmartTrip staff by surprise. In fact, even at last night’s RAC meeting they didn’t quite seem to grasp the issue. Cyndi Zieman of the Office of SmarTrip kept saying that this “use it or lose it” simply continued current practice. That’s true from the SmartTrip system’s point of view and the employer’s point of view, since it just treats all claimed benefits as having been spent, but it’s not true from the rider’s point of view, and Zieman didn’t seem to be focusing on the rider experience.

If the SmarTrip team had shared their plans with the Board, the RAC, or the public earlier, someone might have noticed this problem. This has been in the works since January, when they modified the SmarTrip contract to divert some of the efforts on NextFare (passes, autoload, peak of the peak fares, and more) to this SmartBenefits project. But there was no Board presentation at that time, no RAC presentation, and no announcement explaining the details of the plans. Zieman told the RAC that their designs weren’t secret, but it seems simply not to have occurred to them to ask anyone outside the group if this design was a workable one.

Nor did they communicate changes that put the NextFare upgrade timeline at risk. They announced a timeline last November, which specified passes and a website to check your balance by September 2009, and autoload along with the IRS compliance in December. But they never updated the timeline, even though, according to Zieman, they modified the contract in January. Zieman said that they knew by August or September that the NextFare upgrades were not going to happen this year after all, but still didn’t tell anyone until October. And now, the best Zieman could tell us was that NextFare could come by next summer “at the earliest.” She could give no specifics about what they could do, only what they could not do.

Finally, it’s not clear that they had to put the bins ahead of NextFare at all. Zieman told the RAC that there would be no penalty from the IRS if Metro did not make this change now. It was simply an effort to help employers better comply with IRS rules. But it also comes at a cost: we don’t have passes on SmarTrip, don’t have autoload, and can’t try out better fare options like “peak of the peak” pricing or even a basic SmarTrip discount on rail as there is on bus. The SmarTrip team made a decision to push those features back at the expense of the SmartBenefits upgrade. They should have consulted with the Board first, and announced it at the time, rather than ten months later.

Things happen that slow down development schedules. Engineering teams have to make tradeoffs. We still don’t whether they could have done both. But as a former technical product manager, I know that there’s a lot of complexity under the hood of systems and more work than meets the eye. Zieman noted that they have to coordinate with all of the regional systems, like Ride-On, The Bus, ART, CUE, Fairfax Connector, and so on. However, what good product managers do is communicate. They discuss plans and designs proactively with stakeholders. They set a timeline, and then keep the customer updated about any slips in that timeline. Zieman and the Office of SmarTrip quite simply didn’t do that, not when they modified the contract in January, not when they definitively slipped the schedule in August, and as long as they don’t announce a new schedule, not now.