Somewhere, yet another big organization is working on yet another big computer system.  Legions of stakeholders are fussing about what the system needs to have if they’re going to get their real work done.

Few of them, alas, are making the case for a robust, easy, and safe way to practice.  A shame, considering the universal desire to have people learn such systems.

Instead, people are mired in situations like a financial services project I worked on.  Its banking module, used by the people at a branch, enabled them to electronically open accounts for a customer, transfer funds, and handle loan applications.

But there was no way to practice those tasks.  If you wanted to get skilled at, say, processing an auto loan, you had to process an actual one–preferably for yourself, so you wouldn’t need someone else’s Social Security number.  You couldn’t complete the transaction.  Well, you could if you were actually getting a car loan.  Seemed like a mighty rigorous prerequisite.  And training people to do A, B, but not C — quick, hit cancel! — is disconcerting.

A practice system, like its first cousin, a test mode that truly works like the actual system, is a kind of performance-support forest that companies can’t see because all the stakeholders are focused on the system-spec trees.

When I managed online training for Amtrak’s reservation system, we inherited three imaginary trains that agents could access with a training ID. Granted, learners could reserve seats and sleeping compartments, but not much more.  And the practice provided was suboptimal.

Each imaginary train had a consist (a set of cars, with passenger accommodations), but there was no automatic cancellation of the fictional reservations.  In other words, the imaginary trains could sell out.

As for transferring skills, the trains didn’t follow any actual Amtrak route.  One went from London to Rome; Another, from London to Dublin–by way of Donegal.

More to the point, pretty much all you could do was reserve space.  You couldn’t calculate fares, in part because Amtrak didn’t have fares on the London-Donegal Express, but also because there was no connection between the imaginary trains and other parts of the system. Like fares.

During my time as head of online training , we decided to do better.  Leslie, who’d been a reservations agent, worked with John from the Train Operations group.  I’ll discuss specifics not because you need to know about Amtrak reservations, but to show the kinds of factors to consider when planning a sturdy practice system.

Realism: Leslie and John created training trains based on real ones: they cloned trains 3 and 4 (Chicago – Los Angeles) as 9003 and 9004 (no real-world trains had numbers in the 9000s).  Same cities, same accommodations, same schedule.

Coverage: They identified all the different types of Amtrak accommodations, then created training trains to include them all.  They took in geographic routes, so that while they didn’t duplicate the entire Amtrak system, they had trains in every part of the country.  This country.

Integration: the training trains got their city information, schedules, accommodations, and fares from the live system. When the fares changed on the real route, they changed on the training trains as well.  The training ID could access all the information-only parts of the system: fare quotes, current train status, and the like.

Resilience: you could make as many reservations as you liked, for whatever day you liked. At midnight, they’d all get purged, so as not to clog the system with imaginary trains filled with imaginary passengers.  And for entire new services, we could clone another real-world train and launch it in the training environment.

Security: we built in safeguards against error.  If you logged on with the training ID, you couldn’t reserve space or issue tickets on real-life trains.  Your real-system ID would not let you use or even display the training trains.  The burden of requiring  a training ID for practice was low, and the separate systems meant that even if you forgot which mode you were in, you couldn’t do anything harmful to a real reservation.

Continuing the security angle, you could make ticketing entries on the training trains.  That means you could pull up a training-train reservation and tell the system you were issuing tickets.  You couldn’t print the tickets, though, and the financial system ignored “sales” on the training trains.

What did Amtrak get out of this?

• Any Amtrak ticket clerk or reservation agent (more than 2,000 people at that time) could practice virtually any entry, or combination of entries, via the training trains.
• The new training trains, based on real-world routes, reinforced the layout of Amtrak’s route structure.  You could work with complex fares and experiment with complicated connections.  You could also build skill with accommodations or trains, like Metroliners, that you might not encounter often.
• As new features went into the live system, they were available immediately in the training system as well.

Safe practice in many live systems is harder than it should be.  Often “harder” means “not possible.”  Less-safe practice can mean goofy messages going to customers.  Phantom sales inflating revenue.  Accidental cancellations of live orders.  Triple demand for supplies.

No matter how firmly your company insists on formal training, your learners and the entire organization  can benefit from support provided on the job by a realistic, feature-rich way to practice skills.

CC-licensed images: a few stakes by TonZ;
log slices by the queen of subtle;
caber toss by notacrime / Gregor Dodson.
Detailed map of the London-Dublin Express is mine.