THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com October 2001

[The following is an excerpt from an early chapter from the book titled Workflow Modeling: Tools for Process Improvement and Application Development, by Alec Sharp and Patrick McDermott, copyright 2001, Artech House Publishers.]

This is the second part of an excerpt from a chapter in our book which covers how to build an as-is workflow model. You need techniques to get started (which is often the hardest part), to maintain progress (avoiding inappropriate detail and distractions), and to validate the model. It is not as simple as just grabbing a pen and starting a diagram.

The second part of this article will cover items 3, 4 & 5 below. The two parts of the article progress through:

1. Building the team
2. Organizing and initiating the modeling session
3. Getting started by building the handoff (level 1) model
4. Adding detail with a flow (level 2) model
5. As necessary, developing a task (level 3) model, and even doing some task analysis if the situation warrants it.

The Kickoff

How you start makes a difference. Start on time, give a pep talk to establish scope and direction, and provide an overview of what’s to come. Then get on with it! Don’t bore them – do it fast, and put them to work as quickly as possible, ideally within 15 or 20 minutes.

During the introduction to the first session, the more that can be done by the sponsor (or other big shot) the better. Have them summarize key points from the charter and process frame– event, result, key actors, milestones, relevance to mission, strategy, goals. Describe the problem, business imperative, and goals. Material from the Case For Action and Vision can help. Stress why participation is so important.

The facilitator or the lead process modeler will then introduce workflow models, and the method the session will follow. If the group hasn’t seen one before, show a sample workflow process model, although not from their area. A flow (second level) model can be used to explain the four components – actors, steps, flow, and handoff. Explain that this can get bogged down in detail, so we start with a handoff level model. Show the handoff level model corresponding to the flow model you just showed them, and then explain the concept. Tell them that it might be frustrating at times when important details are omitted, but this will provide a framework for gathering that detail.

To avoid bogging down in detail, we’ll follow four principles that also may be frustrating, but are proven to help maintain progress, especially at the outset. They all relate to the idea that we constantly strive to get all the way through the process, and then come back to fill in the details. These guidelines should be summarized on a flipchart and posted during the session.

• Starting with the “mainstream” (normal, most common, “sunny day”) case, model one case (variation) at a time.
• At a decision point, follow one branch, and mark the other with a cloud or “???” You’ll come back to it later.
• Do focus on “what’s next.” In the handoff model, keep asking, “Who gets the work next?” and in other models keep asking, “What happens next?”
• Don’t dive for detail, especially detail that doesn’t belong at that level.

Building the Handoff Level Diagram

It’s usually easier to gather content or build a rough framework than it is to build even as simple a diagram as a handoff level model. Accepting this, we’ll look at two alternatives for gathering information (all the while avoiding unnecessary precision) and then turning that information into a handoff diagram.

The first approach is to build a “cloud diagram”. The idea here is to trace the involvement of the actors without worrying (yet!) about what they actually do at the points they’re involved. We also refer to this as an “involvement diagram.” It captures “dynamics without details”. By hiding details of individual steps, it actually does a better job of showing the “structure” of the process. Not much preparation is needed– you just want a long whiteboard (probably multiple adjacent whiteboards) or some convenient drawing surface. The method:

1. Draw a swimlane for each process actor you identified during “Framing”. Leave some room, because you’ll probably find additional actors.
2. Start with the initiating event.
3. • If it’s a timer, put the clock on the diagram.
   • If it’s an actor doing something (including deciding if a counter or threshold has been met) put a cloud in that actor’s swimlane. Why a cloud? To show that we’re intentionally keeping it vague right now. It correctly implies it’s nebulous and imprecise.
4. Ask the all-important question: “Who gets the work next?” Ignore all the details of the work performed by the actor who has the work right now.
5. If it always goes to the same actor at this point, draw a cloud in that actor’s swimlane and return to step 2. If it varies (that is, there’s a decision) draw a fork on the right edge of the cloud, choose the mainstream path, connect it to a new cloud in the next actor’s swimlane, and return to step 3. (The other branch/branches of the fork just go to a big “?” to indicate that we need to return). Figure 11.1 shows what one of these can look like.
6. When you hit an end-point of the process, go back to the earliest incomplete branch (“fork”) and pick it up from there, following the same method.
7. Perform an initial validation by walking through a few scenarios and revising the diagram as necessary. A more thorough validation will be described in the next section, “The five key questions.”

The second approach is collecting tasks and assembling a workflow diagram. The first approach focused on involvement – “who is involved at what points in the process?” This second approach is more bottom-up - the idea here is to more or less randomly identify individual tasks (who does what) through brainstorming without regard for sequence and flow, and then organize and cluster the tasks to produce a handoff level. Then verify the structure, and proceed with gathering additional detail. We should note that this is similar to the bottom-up technique used successfully for project planning.

In Preparation, create some large (4x6 or 5x8) Post-It’s (big yellow stickies) – depending on facilities and number of participants, between ¼ and ½ of an 8 ½” by 11” sheet of paper – divided by a horizontal line about ¼ of the way down. We’ll explain why in just a moment. On the longest plain wall surface you have, tape up as long a sheet of butcher paper (or plotter paper or whatever kind of rolled paper you’re using) as you think you might need. Leave room to add another strip below, in case you’ll need it to accommodate additional actors. The method:

1. Brainstorm for significant steps or tasks, recording each suggestion on one of the large Post-It’s. The name of the actor responsible for the step goes above the line, and the step description goes below it. This can also work very well with individuals or breakout groups separately identifying tasks – this avoids “herd mentality.” Then combine individual results, and see if synergy results in additional ideas. If people can’t put each step in verb-noun format, don’t worry – anything that captures the idea is “good enough for now.” Don’t interrupt the flow, just get something down you can refine later.
2. Lay out the steps in approximate sequence on the paper (now you’ll see why Post-It’s are so useful – they’re easy to manipulate (cluster, moved, etc.). Try to keep the steps for an actor approximately in their swimlane, even though swimlanes may not be drawn yet, and certainly won’t be labeled. Absolutely don’t worry about precision at this point – you won’t know the precise sequence and flow of steps. You just want to show roughly where steps are happening in sequence or in parallel.
3. Now, have the group look things over and ask, “Did we miss any important steps?” This is where the power of this approach becomes apparent – by laying out the approximate structure of the process, missing steps become more obvious. They can be added while it is still relatively easy to do so (i.e., swimlanes and flow lines aren’t yet specific, so it’s easier to slide the stickies around.)
4. Add swimlanes, labeled by actor, to the paper and place the steps in the right swimlane. (Order here will vary)
5. Wherever an actor has a contiguous set of steps (from receiving a handoff to initiating a handoff,) reduce them to a single step as per the central principle of the Handoff Diagram. Don’t throw out the details you’ve captured – you’ll want that for subsequent diagrams. A good technique is to stack the steps being reduced, and add a new Post-It on top with the summarized step name. Naming the step in the handoff diagram may be awkward – if you have to use “and” and “or,” or otherwise get wordy, don’t worry about it.
6. Add flow lines between the steps, being careful to account for decisions and multiple flows. These will “stack up” at the left and right edges of the step box. The step in the handoff box may summarize several steps, with flow lines coming in or out of these steps along the way. These will all be placed at the left and right edges of the step.
7. Try to improve step names to reflect the “totality” of what happens while that actor has the work. It’s likely that a few step names will still require “and” and “or.”
8. Perform an initial validation by walking through a few scenarios and revising the diagram as necessary. A more thorough validation will be described in the next section”.

The Five Key Questions

Any time substantial progress has been made on your swimlane (completing a whole level of detail, or at least a major phase) you must stop and validate the model. An excellent method is to review each step in the swimlane diagram, one by one, and ask each of five specific questions about it. The questions work through a step from left to right, beginning with the inputs (the flow lines coming in from the left), the actual work of the step, and the outputs (the flow lines going out from the right). Asking these questions almost always leads to the discovery of additional actors, steps, triggers, and flows. This rigorous procedure prevents glossing over ambiguities and missed details. After we review the questions, we’ll provide a real example of a swimlane diagram that was significantly altered (and improved!) by asking these questions. The five questions, in sequence, are:

1. “What makes it go?” This is one of the two most important questions, because it uncovers missing trigger conditions for a step, which is a fundamental aspect of workflow. Often a diagram will show a single flow line entering a step, but the question is: “Is the flow line (or lines) shown really all that it takes to trigger the beginning of the step?” Often, it turns out that a flow line from a step performed by some other actor is required. Even more common is the case reviewed back in Figure 10.5—a temporal event (e.g., “Close of business”) and/or a condition (e.g., “Total receipts >= cash drawer limit”) is also required before a step can begin. The example we’ll review includes many steps that are triggered by a schedule.
2. “Is anyone else involved?” This question often uncovers one of two common errors
   • A step is shown being performed by a single actor when there are actually two or more participants (a meeting,) or there is a handoff to another actor as Figure 10.1 showed.
   • Sequential steps, performed by different actors, are drawn when actually there is one step (a meeting) simultaneously involving multiple actors, as we showed in Figure 10.3—clearly, the complainant (the Customer) and complaint taker (the Customer Service Rep) are both involved at the same time.
3. “Does the name of the step accurately convey the result?” The purpose of this question is to ensure that there really is a legitimate step, the participants agree on what the outcome of that step is, and that the name conveys the result. Practically, this most often means ensuring that a “mushy” verb hasn’t been used unless there is absolutely no other choice. Remember the table of “Verboten Verbs” from chapter 5?—use it! The most common ones we encounter are “process” or “handle,” which say nothing, and “monitor” or “review,” which are usually hiding decisions. If we see a mushy verb, we usually ask this question first, so we can clean it up before investing any more work in it.
4. “Are all outcomes shown?” As in question 1, sometimes a diagram will show a single flow line leaving a step. The most common error (often masked by a mushy verb) is to neglect to show that there are two or more possible outcomes – in other words, a decision is being made. We specifically ask, “is a decision being made here, and if so, what are all the possible outcomes?” The other common error is to miss a parallel flow line. In the case of Figure 10.3, it wouldn’t be unusual to discover that the step “Route Complaint” had a flow to the appropriate specialized service rep, but missed a notification (flow) to the Customer’s assigned sales rep. We ask “does this step initiate work or a notification for any other actors?”
5. If there’s a handoff, “How does it get there?” This is the other “most important” question, because it uncovers missed actors (intermediaries or transport mechanisms). When we ask “how is the work transported from actor A to actor B?” we sometimes discover that additional actors who perform a delivery service are involved—our upcoming example is full such cases. In some cases the handoff is accomplished by an information system running in batch. In both cases, the additional actors might introduce delay, error, or expense.

Figure 11.2 shows a swimlane diagram that was presented to us for review. The process had been modeled because it took excessive time between the time an applicant submitted their application for a cross-jurisdictional business license and the time they received their assessment, prorated across the different jurisdictions. This initial version failed to show where the delay was occurring, but after asking “the five questions” and revising the model accordingly, it was clear where the delay was being introduced. Figure 11.3 illustrates the revised version, but only the first third or so—after the Rating Technician completed their assessment, we discovered a parallel flow to the Program Manager, who “monitored” every application, which resulted in an extensive review! What was really interesting about this example was how much improvement was possible from simply rescheduling some of the delivery and pickup activities. (Eliminating them wasn’t a possibility, because of the collective agreement.)

We emphasize that these questions must be asked, for each step, at each new level of detail – after the initial handoff model, after the flow model, etc. However, they are most important at the handoff level, where they almost always uncover missing actors and steps – the rest of the work proceeds far more smoothly, without continual redrawing, if all of the actors and their “contribution points” have been identified.

One More Question – “Can we stop now?”

With stories of workflow process models stretching to 50 feet, 100 feet, or more. Generally speaking, that much detail in one diagram is useless. It can actually be harmful since the finer the level of detail, the more variation there will be. Even if it is irrelevant, there will be a temptation to show it, creating a vicious cycle. The finer the level of detail, the more words it takes to describe it so the people working on the chart will be working hard, but actually accomplishing little of value.

So it’s important to stop before you slip into modeling useless detail. After completing a level of detail (for instance, developing the initial model, testing it with a few scenarios and the five questions, and making necessary revisions) one more question must be asked - “Do we really need to add more detail?” In general, stop when you understand why the process behaves the way it does.

You only need to add more detail if you aren’t confident that you understand the workflow. If you don’t yet understand how the overall flow and dynamics of the as-is workflow impacts its performance, or aren’t confident you’ve identified the main activities that currently must be completed, handoffs within the process, and handoffs (or interfaces) to other processes, you need more detail.

On rare occasions, you’ll be able to stop after the high-level handoff model is completed. We described a case in Chapter 9 when the handoff model illustrated the central problem with a process’ workflow (continually returning to a control point) so it might have been possible to stop as-is modeling at that point. Generally, though, this level will mask important steps, decision points, and milestones that contribute to the performance of the process, and you’ll have to proceed to the flow level.

The second level flow diagram shows the significant milestones and decisions while an actor has the work, but not any of the details of how they accomplish them. Most of the time, we find that this level of detail is adequate to understand the as-is situation. Some parts of the process may need additional detail.

Subsequent Levels of Detail

Getting the handoff-level diagram completed is the critical starting point – if you’ve done this properly, the remaining steps will go smoothly. From this point on, we “just” add controlled amounts of detail until it’s time to stop. That’s why the paradox – we had a lot to say in the previous section on producing the simplest diagram, but now that the diagrams will get more complex we have less to say. There really isn’t a lot to say – we’re just applying the guidelines that we explored in Chapter 9. Here are a few key principles ...

• When collecting additional detail, it’s generally easier to capture it in list or point form rather than trying to swimlane it immediately. When building a list, it’s easy for people to spot missing or incorrect steps and rectify. With diagramming, there can be tendency to resist changes, even essential ones, because it’s so much work.
• In general, if “unwanted” detail can be tricky for a facilitator to handle. If you just say, “that’s too detailed for now,” the participant may get frustrated and clam up. Usually, we say “Hmmm – sounds like we’d better capture that” and then put it on a “parking lot” (stuff for later) list. Or ask the participant to summarize.
• Follow the principle of “expand by three to five times.” Each step in a handoff model should typically (“typically” – there are always exceptions) expand to no more than five in the next level.
• In most cases, and this is important, you usually have to go too far before you know you’ve gone far enough. You’ll gather some information, but essentially “abandon” it without turning it into a diagram. That is, you’ll list some points about the next level, and then say “hey, there’s no “aha” in here.” When that happens, save your notes but don’t take the time to develop a swimlane diagram! Some analysts find this very difficult – “I’ve gathered the information, I must format it!”

Some specific guidelines for the Flow (level 2) model ...

• First, remember what Chapter 9 said - this level adds steps that depict:
• • Achievement of a milestone
  • Decisions that affect the flow in a significant way
  • The mechanics of any handoffs (both the “pass” and the “receive”) that introduce delay, errors, or expense.
  • Significant looping (e.g., “go back” or “repeat until”).
• Therefore, for each step in the Handoff model, start by brainstorming the significant milestones and decisions. Try to keep it under five. Remind participants that a milestone is just that – an important state or point has been reached. Different than a simple task. Some steps in a handoff won’t break down any further – they represent a single milestone or task.
• If there’s a mandatory sequence, put them in that order and ask: “What’s have we missed?”
• If there isn’t a mandatory sequence, the steps can be placed in a “dotted box” when you draw the diagram.
• Ask how the “handoff in” and “handoff out” are implemented, and if there are any problems. If so, add steps to depict those.
• After you’ve done this for a few (three to five) steps from the high-level handoff, draw the corresponding part of the Flow level diagram, but only if the new information is worth drawing, as discussed earlier. People like to see the diagram starting to evolve, rather than capturing lists for the entire Handoff diagram before starting the new Flow diagram. While drawing, you might find there are important loops that have to be added.
• Walk through a few scenarios to ensure that all steps, decisions, loops, and handoffs are shown.
• Ask the “five key questions”.

Some guidelines for the Task (level 3) model ...

• Chapter 9 noted that “Level 3 makes the transition into describing the details of how the process is implemented - it contains individual tasks or steps leading up to a milestone, and the details which characterize how the workflow is implemented such as “photocopy form” or “fax estimate to shop.” It will also show the mechanics of any handoffs not shown in previous levels, or different cases (minor branching.)”
• In practice, if we go to a third level diagram, it’s usually only for a part of the process that is confusing or problematic.
• The essential technique is the same as it was for building the previous level. Take each step from the Flow model and ask, “What are the individual tasks or steps that make up this step, or lead to this milestone?” Remember – you’re looking for tasks and mechanics.
• It is often useful to have an actor (one of the participants) describe actually doing it, while the facilitator tries to capture it. Then ask, “Did I get this right?”
• Once enough facts are gathered, shift to drawing the diagram, but only if the new information is worth drawing, as discussed earlier.
• Walk through a few scenarios to ensure that all steps, decisions, loops, and handoffs are shown.
• Ask the “five key questions”.

Conclusion

Remember the modeler’s motto - “Good enough for now!” In his book The Rise and Resurrection of the American Programmer, Ed Yourdon discusses the concept of “Good Enough Software”. [1] He attributes this concept to some of Microsoft’s paradoxical success—they ship software with thousands of known bugs, yet are extremely successful where it counts, in the marketplace. The only logical conclusion is that the ultimate judge of quality, the consumer, has decided absence of bugs, the Computer Scientist’s definition of quality, is not the measure (or at least not the full measure) of quality.

In our modeling projects, we will need to keep this concept of “good enough” in mind. Ask, “What is the underlying purpose of this model, and will further effort further the goal?” If not, it’s “good enough”.

Reference

[1] “Good-Enough Software” in Yourdon, Edward, Rise & Resurrection of the American Programmer, Upper Saddle River: Yourdon Press, 1996, pp. 157-181.

Order this book through Amazon.com Today!