You may well ask, How do you go about documenting a process or procedure?
Great question!
Here's how we do it. See instructions with related notes.
1. Log on to your computer.
2. Run the program.
Yes. Really. Start at the beginning. Users are easily frustrated when documentation starts at step two or three. This common mistake happens for two reasons.
First, the documentation is written by a programmer or regular user. So they know the program backwards and forwards.
Second, the writer starts where they are in the program. That's fine as long as the user always starts in the same spot. But chances are, they won't.
3. Don't assume anything.
If you "always" change a setting or use keyboard instead of mouse, make sure you put those things in your documentation.
You'd be amazed at what you take for granted, especially in a world where we each get total control over the look and feel of our desktops. If you use more than one computer on a regular basis, you've seen a touch of this.
I go back and forth between my beast at home, a plain vanilla PC at work, and a laptop. Three different screen sizes, three different resolutions, three different sets of defaults. Over time they become more alike, but they're all different.
Every user's desktop is different. You can't even assume that their menus are the same.
4. Go through your process.
Do what you normally do, but go slowly and write down each thing you do.
Use numbers for action steps. So, Log On is an action step. Open MS Word is an action step.
Under each number, give any useful information or description.
Do Not write lengthy explanations or justifications. You can put that stuff in a memo, print it out and shred. When someone is running a procedure, they need bullet points. A block of text will be ignored.
Take a lesson from some of the well-designed government forms you see. Pages 1-2 are the form. Page 3-9357 are the clear and concise explanation. If you start reading it, you will contact your accountant halfway through page 3.
If you need a bit of information or "cheat sheet" for data entry, put it on the form. But don't write long blocks of text.
Think bullet points and action steps.
5. Describe the process in order.
Again, sounds simple. But I'm amazed at how much documentation is not In Order.
Bad: "Select font size from the typeface menu after selecting the text." Exact reverse order. Easy to follow if you're very familiar with a program; impossible to follow if you are new to the program.
Good: "1. Select the desired text. 2. Go to the Typeface menu and select font size."
6. Take Screen Shots!
Whenever it will help clarify the process, take screen shots. You can circle the most important items, or highlight the relevant field in yellow.
You'll be amazed at how much a series of screen shots will help clients understand what they need to do.
Just be careful. If you're going exactly step by step, and something unexpected shows up, they'll grind to a complete stop.
7. Have people test the procedure
When you think you're done, print out the procedure and hand it to someone. Then watch them go through the procedure. As soon as they start to ask questions, make they write down their questions on the form. Then give them the answer and make them write the answer on the form.
Eventually, you can train your staff so they all know how to create and update procedures. When people learn the process of updating processes, you'll be able to post a procedure on the server, point them to it, and they'll run and update it without supervision.
And thus begins the road to SOPs -- Standard Operating Procedures.
- - - - -
There's nothing difficult here. Just process, process, process.
You should document your internal procedures and have your employees make documentation a standard part of their daily routine. That way it just gets done.
You can also create documentation for clients (e.g., how to do mail merge). Yes, they can go read the help menus. But they're paying you to run their I.T. Department. Make their life easier.
And once you create a documentation for one client, it will be an easy process to fine-tune it for the next client.
Sample Procedure: Procedure: Setting Up Automated Recurring Billing (ARB) Background Automated Recurring Billing (ARB) is a process for charging a credit card on a regular basis. We most commonly use this for charging client credit cards every month for Managed Services. The Steps 1. Log Into Authorize.net
In the upper right-hand corner, click on Merchant Login. As of Fall 2008, the account that processes credit cards through Merchant Warehouse and deposits the money into the BofA checking account 12345-67890 is: Username KPErulez! Password Sn0rt1ng 2. Set up a ARB
3. Important Final Note: This is extremely valuable financial information. Log out when you are finished. This doc = \Operations\Policies Procedures\Automated Recurring Billing.docx |
:-)
Karl - but how do you avoid getting bogged down with the question of how much detail? Your first line of the example is 'go to www.authorize.net'. An extreme example, but depending on the person reading this, you might have to tell them that's a web address (versus a place down the road?) and to use internet explorer.
ReplyDeleteHow do you handle documentation for users / groups where you might need to tell them how to open IE but others in the group may be much more comfortable with the PC.
Mike: Your point is valid. You have to know your audience.
ReplyDeleteIt's only been ten years since we stopped saying "Open up Netscape, Internet Explorer, or your preferred Internet Browser."
If we find the right client, we'll add that back in.
This example is for internal employees who will know that www. . . . means to go to a web page.
But you can also see how we would get into trouble if we assumed the first step. "Look on the left side of the screen." OK. I see a recycle bin.
Everything's relative.
:-)