|
|
||
|
|
I Have a Little List:
| |
By: Miki Magyar
April 2004
Even in this high-tech, fast-paced, multi-media world, the simple list is still one of the most useful of basic tools for the technical communicator. It may be as basic as a sticky note or as elaborate as a task list for building a rocket, but the concept is the same. Each list provides the answer to a question, and should solve some problem or make life easier for you.
In this paper I will first explore when and how to develop a list. Then, using ten of the most common types as examples, I'll show what problem each list solves or what question it answers.
A list is an ordered set of data. I'll use the term in the largest sense, to include some charts and tables which organize and annotate the items in a list. If you think of a list as an answer to a question, it helps you understand how the list is best organized and used. As a trivial example, a grocery list answers the question, "What do I need from the grocery store?" If it is organized to correspond to the usual pattern of how you go through the grocery store, it will make it easier to find everything and not forget anything. Why and How to Develop a List
A list is typically used as an aid to memory or for verification, or both. Ephemeral lists are task-specific and generally have no use after the task is finished. In general, unless I'm certain I'll never need to know about it again, I save lists for a while after they're officially done. Sometimes they are useful to confirm that something was (or was not) done, and they can provide a basis for planning.
A list is appropriate if
If you realize that you have a problem that could benefit from a list, or a question that you have to answer frequently, follow these steps:
Follow these guidelines as you use your lists:
You may not need all of these at any one time, but you probably will use most of them at some time. Some of them overlap or serve multiple purposes, and you can probably think of many variations. This list is not intended to be definitive, but rather a stimulus to prompt your own creations. They are in no particular order, and this order does not imply importance. Only you can decide which lists you need.
This is the simple listing and tracking of projects, of what you're responsible for. It may also be prioritized, and include due dates and other information to keep you on track. For this purpose, the shorter and simpler it is, the better. This is the sort of reminder list that gets posted on the wall and added to as you get new assignments.
In addition to the formal projects, you probably also have a reminder list of little things you don't want to forget. For me, this includes the things I notice as I'm working along but don't want to get side-tracked on right now, like badly written paragraphs, places where I know there's more information I could add, poor formatting, etc. I keep a 'Misc.' file on my desktop and simply note them there under the appropriate headings (Needs copy edit, verify with developer, etc.). When I have time, I go through and do what I can, then delete them. It's an ephemeral list, and does not need to be kept or logged.
A table of tasks for each project is an example of this kind of list. Most often this is used as a checklist. It can be as simple as ticking off items on the task list so you know what you were doing when you stopped.
On one project we had a set of five related documents, each of which had many chapters. As we worked on a new release, there were a number of tasks that had to be done for all documents, but not for all chapters. For example, a name change to a component or modification of functionality might require updates in several places in each book. Three writers divided up this task, but since we were also working on other projects, it was not unusual for someone to be pulled off in mid-edit and have to hand it off to someone else to finish. To make sure we did all that was required without spending any time on figuring out what had already been done, I instituted check lists, like the following:
This greatly improved our consistency and minimized effort. It allowed people who liked to do one thing across all the documents to work that way, and still coordinate effectively with the people who wanted to do everything in one document at a time.
This can also be combined with the Am I Doing it Right list, to combine quality checks with progress checks. Any time you can combine or integrate more than one function (answer more than one question) with the same list, do it. Just be careful to keep it simple enough that it will get used.
With multiple projects and ever-changing requirements, it becomes more critical to make sure you're keeping up with the essential tasks. Time lines, calendars, and schedules help you meet deadlines and achieve essential goals. A 'doc spec' or list of requirements is essential. Scheduling for very large projects can be a full-time job in itself. For most of us, however, the problem lies in juggling several independent and non-communicating projects. Sometimes all it takes is a large wall calendar with color-coded entries. The essential thing is to be confident that you don't have lurking crises or unanticipated crunches. This is subject to forces beyond our control, but as much as possible, use these tools to build in an adequate buffer.
Over time, these tracking lists can improve project planning by providing data on how long tasks actually take, how many and what kinds of changes really happen, and indicating the sources of delays and re-work.
Quality checks of all kinds fall in this category: edit check lists, style guides, production check lists, etc. This also includes process descriptions, which should be designed so that if you follow the instructions, you can be reasonably sure you have done it right the first time. Process descriptions answer the question, "How do I do that (right)?" As Steve Jong points out, "To do your best and fastest work, then, you must get things right the first time. To do that, you must know what you're doing, and you must keep doing it that way." (Jong, ??)
This is also connected to the Where Was I list, which makes sure that all the critical tasks are explicit.
In its simplest form, this lists who is responsible for what parts of which projects. It can be expanded from just the Tech Pubs department to include critical people in other departments. For some complex projects, the leader will develop a contact list that also indicates responsibilities.
In my current job, I have to deal with over 50 development engineers who are all busy cranking out code on various modules of a huge, complex software package. As priorities shift and new projects come on line, it is not always clear who to ask for information. I don't want to keep asking the managers or bothering people who don't know, so I developed a Who/What list. For each module, I listed the developer assigned to it, and the writer responsible for it. This is distributed to everyone involved, so when it changes, we all know about it. This has cut down on the time it takes to track down information, and minimizes the annoyance to developers.
Use this list to track review copies, to keep your actual process in line with the ISO 9000 process, or to track any multi-step process. It can often be combined with the How Am I Doing list.
When I was the entire documentation department at CDS, I sometimes had to keep track of as many as 25 different documentation projects, all in different stages of development, and with different degrees of urgency. To do this, I used a simple list on a clipboard. When I sent a document to an engineer for review, I listed it, with a short note of what was needed. When it came back, I checked it off. According to the ISO 9000 auditor, this was completely adequate for the purpose.
This is the traditional To Do or Action Item list, and can include the overall project schedule. It is also used for triage when it includes sort criteria. Used in conjunction with the Maybe Someday list (#10), it can insure that people are always working effectively, not spending time on irrelevant or inappropriate tasks.
This lists sources and resources, and can be expanded to include audience profiles. It may be combined with the Who's Doing What list.
A variation on this is the Who needs to know? list. For a contract job helping to design and write a proposal for a complex project, we developed a set of audience profiles for all the people we knew would be evaluating the proposal. For each person we listed the kinds of information they needed, wanted, and should want, their preferred format, and known biases. This enabled us to design an effective document that addressed the needs of all its readers and still looked like it had a single author.
I have also created personal lists of this kind for SMEs I work with. It includes notes on when and how they prefer to be approached, how they like to edit, and other personal characteristics that will help me do a better job of getting information while minimizing annoyance. For example, an entry might be:
Jim B. - e-mail or in person, not hard copy. Will answer direct specific questions but not general requests. Use short deadlines. Doesn't tolerate 'dumb' questions; tell him where you've already looked.
Obviously, a list of this kind is better kept private, or at least confined to a small group.
This is the list of things you'd better check because they might bite: the engineer who's been chugging away for months but hasn't produced anything (that you know about), the note from two releases ago that this command was going to change, etc. This also includes all the routine tasks that should be re-done periodically, like spell-checking the spell checker, updating the glossary, reviewing the boilerplate, or updating your lists.
And finally, the wish list for all those things that ought to be done 'someday when we have time' but somehow never happen. Unless you have a list of tasks for the odd spare moments when you can pick away at them, they will never get done. Include the groundwork and research items for long-term projects, process improvement projects, and clean-up work.
By now you should be able to see that all of these lists aid management goals: meeting deadlines, producing quality documents, reducing stress, and improving communication. Whether you are a one-person office or part of a large team, you can use these tools yourself, and share their effectiveness with your co-workers. I've found that most people welcome anything that will make life easier or help them do their work better.
References"Secrets of Successful Documentation Projects." Metschke, C.J. 1996. 43:3
http://www.ieeepcs.org/transactions/trans_98.htm
Society for Technical Communication. DocQment Newsletter, "Musing on Metrics" column
http://techwriting.miningco.com/jobs/techwriting/gi/dynamic/offsite.htm?site=http://members.aol.com/SteveFJong/DOCQMENT/DocQment09.html
Writing Revisable Manuals: A Guidebook for Business and Government, Appendix B—Checklist of Manual Development Process
http://techwriting.miningco.com/jobs/techwriting/gi/dynamic/offsite.htm?site=http://www.techcommunicators.com/dkmanual/htframe.html
(v) To display data in an ordered format.
(n) Any ordered set of data.
http://www.pcwebopaedia.com/TERM/l/list.html
Cambridge International Dictionary of English. © Cambridge University Press 2000. Cambridge University Press, Edinburgh Building, Shaftesbury Road, Cambridge CB2 2RU
list (RECORD) noun [C]
http://www.cup.cam.ac.uk/elt/dictionary/default.asp?String=list*1%2B0&ACT=SELECTa record of short pieces of information, such as people's names, usually written or printed with a single item on each line and often ordered in a way that makes a particular item easy to find
Miki Magyar, M.A.
Miki Magyar is a semi-retired Senior Technical Writer in Boulder, Colorado. She has been documenting hardware, software, and systems for over 15 years. She taught technical communications at Metropolitan State College in Denver. As Communications Support Services, a consulting service, she offers training for technical professionals in communications skills and project management, in addition to contract writing and editing. She is active in professional organizations, and is a frequent presenter at conferences.
|