Certainly they should have followed basic best-practice steps for creating and implementing any large software project, regardless of whether it's a fare system, automated supermarket checkout, whatever. Some general principles that SEPTA appears to have ignored or minimized:ChesterValley wrote:This leads me to a question I have had for the past two years watching this system develop, What would have been a better way to implement the Key?
- Determine what the new system should do, but be very conscious of falling into the "we've always done it that way" tar pit when analyzing.
- Study the existing system to understand what works and what doesn't work. In particular, determine what its most popular and/or heavily-used features are.
- Look at similar operations elsewhere to learn how they handle those same good and bad points, AND whether they offer additional functionality that could be part of the new system (the "oh heck, why didn't we think of that?" moment). Similarly, if there's something proposed for the new system that doesn't exist elsewhere, ask both why and whether it's really needed. (As the confusing Travel Wallet shows, there are reasons that some supposed innovations have never been innovated...)
- Synthesize the prior 3 points to create a high-level functional spec; i.e. one describing what the new system should do and why, NOT how it should do it. Open that document for both internal and public input and where practical, modify it accordingly.
(glossing over vendor selection here ...)
- Build prototypes of client-facing parts of the system and test them on real end-users, NOT just with in-house people . Even if a TVM mockup has a Potemkin Village interface with an engineer & developer responding behind the scenes to user inputs, you'll at least see how the interface works with "real" people, not just internal types who already have a tech bent. If they stumble, find out why and address it!
- Allow a shakeout period during which the old system co-exists with the new one where possible, instead of pulling the plug as soon as new functionality becomes available. Case in point: removing token machines as soon as the first Quick Trip TVMs were installed.
As far as specifics go, I agree by and large with your suggestions.
- The purchase fee could perhaps be kept as an incentive to register the card, but with fewer hoops for users to jump through. I haven't had to deal with it (one of the few advantages of being over 65, haha!) but my understanding is the rebate involves a couple of steps to transfer funds to the $&@! Wallet, then converting them to trips, not sure here ...
- Multi-tap functionality is needed. It's ridiculous to force a group of people like a family, students, tourists, etc. to have to buy separate cards for what may be very limited-term use. (Again, sharability was one of those core functions available with tokens that SEPTA perversely decided to do away with.)
- The reload fee should be reduced. Five bucks may be convenient for bookkeeping on SEPTA's end, but it doesn't correspond to a whole number of trips with or without transfers. At a minimum make it $4 and allow $1 increments. Heck, DC Metro allows increments of a nickel or dime!
- GET RID OF TRANSFER FEES. A trip's cost, whether paid for via the Key, cash, whatever, shouldn't depend on the number of vehicles needed. At a bare minimum, start by allowing free transfers between the five transit rail lines (MFSE, BSS, NHSL, 101, 102) and connecting buses to encourage their use as feeders.
- At least until transfer fees are abolished, relax the 90-minute transfer window for riders connecting to or from long routes. It's all too easy, esp. in the 'burbs, to need more than 90 minutes to make a connection, e.g. the 12X routes from CC to K of P followed by a transfer to a suburban bus that only runs every 30-60 minutes.
- TVMs at ALL Regional Rail stations, and/or elimination of the universally-hated onboard surcharge. Riders shouldn't be charged more just because the agency's incapable of offering reasonable sales options.