Documenting Work Processes

As with all other areas of the design process, the amount of time you spend analyzing the work processes and the formality of your documentation should be in proportion to the complexity of the system. A simple system for tracking names and phone numbers might require nothing more than an hour's conversation and some quick notes for your own use.

Unless you're the client as well as the designer, however, I'd recommend at least two meetings for even the simplest projects. The purpose of the second meeting is to review your understanding of the client's needs and confirm that what you've understood and plan to do is, in fact, correct.

More complex projects might require weeks of discussion with dozens of people and correspondingly complex and formal documentation. A structured list of tasks and steps like those used in this chapter might still be sufficient to document simple processes. For more complex processes, I prefer to use a picture.

Although the Entity Relationship (E/R) diagrams used to document data relationships are reasonably standardized across the industry, there is less consistency in work process diagrams. The diagramming methodologies in use tend to be closely related to specific analysis techniques. If you know one of these methodologies and are comfortable with it, there's no reason to change. The purpose here is to understand and convey information. Data flow diagrams and process quality diagrams are all useful tools. Specific diagramming techniques have always seemed to me a rather silly thing to get religious about, although people certainly do often enough.

In the absence of a formal technique, you can easily derive your own. You need five symbols, representing the task, the document, the data item, the decision point, and events such as the start-point and end-point of a task. The symbols I use in my own work are shown in Figure 8-1.

Figure 8-1. The work process symbols.

If there are relatively few steps required to complete a task, I list them within the Task box. If there are too many steps for this to be convenient, I expand each task as a separate diagram and use the Task box to represent each step. Sometimes, for clarity, I will use shading or a bold outline to indicate that a task is done by an external group, such as when the Accounting department performs the credit check for new customers.

The data item symbol can represent either a single attribute, such as a customer number, or an entire entity, such as the customer as a whole. When the item is actually created by the task, you can use either shading or a bold outline to indicate this. Some analysts also like to indicate when a data item is "consumed" by a task, that is, when the item is used by the task but never shared with any other tasks later in the process. Frankly, I have rarely found this to be useful information and prefer to keep my diagrams uncluttered.

Having determined the symbols you will use (and I strongly suggest you choose symbols that are easy to draw rather than those that have any intrinsic meaning), you then need a way of organizing them. I use an arrow to indicate dependency and a branching line to indicate that tasks can be performed in any order. An open circle on a line indicates that the task is optional, just as it does in an E/R diagram. These connections are shown in Figure 8-2.

Figure 8-2. The work process connections.

If you find that your work processes are too complex to capture using this simple technique, I suggest you look into one of the more developed methodologies described in any good textbook on systems design and analysis. Several are listed in the bibliography.