Work Processes

The best way to communicate system work processes depends on how you've captured them. If you've used an outline format, you can include that in the text. If you've prepared work process diagrams, you'll want to include them in the document as well. Just be sure to include an explanation of the symbols you're using. In either case, be sure to explain what you mean by the terms "process," "task," and "activity," or whatever terms you're using.

No matter what form your work process description takes, include a narrative description of the work process. In the first place, preparing a narrative is a good double-check on the formal description. It's amazing how often you'll find minor errors this way.

In the second place, it's critical that people evaluate the work processes, and in my experience outlines and diagrams tend to be glanced at rather than understood. By providing a graphic and a narrative version, you're encouraging people to understand, and the two forms of information will help clarify each other.

If you're proposing changes to the work processes, include both the current and the new versions and highlight any changes in the narrative. Obviously, you'll want to explain why the proposed changes will improve workflow or resolve problems. You'll often find that the client will point out something that was overlooked in your initial analysis if you include an explicit discussion of the changes you're proposing.

Documentation of work processes is one area in which the needs of your various audiences can conflict. The development team will be expecting a discussion couched in technical terms: transactions being committed and data items being updated. Clients, on the other hand, need the process described using whatever terms they use. These can, coincidentally, be the same as computer terms, but they probably won't be.

When in doubt, err on the side of the client. On practical grounds, it's likely to be far less a stretch for the development team to understand the client's terms than the other way around. If you must use technical terms, make sure that you've adequately defined them in the document.

Unfortunately, this is much easier to say than to do. When you work full-time with computers, it's easy to forget that some of these terms aren't really in common usage. I keep a checklist of words like "transaction" and even "file" and do a final review before submitting a document to a client. It's not difficult to do using the Find functionality of your word processor. Confused clients are rarely happy clients.