The Bits and Pieces VIII: Training and Documentation


I wrote a post awhile back where I confessed to my ineptitude with drawing. I said no amount of training would allow me to be an artist because I don’t have the brain upgrade required to transform 3D reality onto a 2D piece of paper. I still believe this is true, but there’s a problem I didn’t consider. What if my boss showed up one day and said 20% of my job now entailed drawing pictures? Do I quit? Take a 20% pay cut? In this economy? My only choice would be to try my best to figure out how to do it.

The same goes for authors and editors who work for companies that are implementing XML workflows. Yes, they were hired for their writing and editing skills. But as technology progresses, so do our jobs. We all figured out how to use computers when they came along. I’m sure some people are still more comfortable with a legal pad and pencil or an IBM Selectric, but their job requires using new equipment, which requires new skills.

Depending on where you work, training is either a fully-supported discipline with dedicated professionals whose only job is to make sure you know what you’re supposed to be doing, or you work someplace where they throw you a manual and a typed-up “tip sheet” that some guy put together in his spare time 3 years ago and you’re pretty much on your own. And of course there are shades of gray in between.

Our XML publishing system had a hodgepodge of approaches for training. We had the professional manuals created by Arbortext and Documentum for their products. We even had an Arbortext trainer come in to “train the trainers”. A caution about that: if you assume you’re training trainers, then you need to make sure part of their job description now includes training, or you’ll end up with a couple people who know what to do spending odd moments tutoring others as they have time. This is not exactly a rigorous approach.

But because there’s nothing in the Arbortext or Documentum manuals that actually explains how WE were using those products, we needed to create our own documentation. The manuals might show how to log in, but they don’t say what to do after that. At the beginning, we actually had a training department. I met with the person assigned to the project and explained how it was all going to work. She took screenshots and wrote up some procedures. Then there was a merger or something and that department was disbanded. So we had a 15-page Word doc with about a quarter of the procedures we needed documented.

Which brings up another point: if you’re working on a complex project that’s going to fundamentally alter how people are going to do their jobs, and training and documentation are not part of your project plan, then you’re asking for trouble. The kind of trouble where you have a roomful of people showing up tomorrow to learn their new tasks and you have nothing to give them.

And, of course, that’s exactly what happened with us. It almost felt like a form of abuse when we had a group of editors watching me click through their whole new world, and there wasn’t even a handout to give them at the end. I’m sure you can imagine the number of calls I fielded when they finally started working in the system. And the enormous frustration they all felt. Toward me. Awkward.

So what’s the big deal, you might be saying. Write something. Annotate screenshots. Whoop-de-doo. And I agree. It shouldn’t be that big a deal to do this. What is the big deal is doing it at the same time the project is being developed. It’s hard to do use cases and testing and bug reporting at the same time as crafting easy-to-understand documentation and training modules. There’s only so much time in the day.

It would therefore be ideal if at least one person on the project was responsible for documentation and training. And they should be there from the beginning, so they understand all the little details and workarounds that inevitably crop up during development. When the project goes live, so should the documentation and training program. And the documentation and training should be constantly revised as new features come on line or new processes are discovered as the system is put through real use.

Also unicorns should be assigned to every child under 12 and my car should run on wishes. But we can dream, can’t we?

Advertisements

2 Responses

  1. Who could not agree?
    Let me know when pigs fly and Hell freezes over.
    (Wanna buy some 3-year old tip sheets?)

  2. John, we call them “vintage” around here. 😉 Anytime you want to be a guest blogger and share some knowledge, the keyboard is yours.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: