2.17 Workflow Analysis

---

2.17 Workflow Analysis

Before moving on to the next topic, I want to take a moment to tout workflow analysis as a wonderful tool for project managers, particularly for the requirements definition portion of the project. If you have never personally invoked this process, either in the privacy of your own office or on a white board in front of the crowd, let me assure you that nothing stimulates good thinking and participation than jumping to your feet with a felt marker in one hand and exclaiming, "Let's see how this works!" It does not take long before the people you really want to contribute to the discussion either chime in or grab the marker from you and start going to town.

A workflow is just the way it sounds - the graphical depiction of a business process your project is creating, supporting, or replacing with one or more IT deliverables. You should consider incorporating two excellent workflow opportunities into your requirements development activities:

1. A proposed layout of a project deliverable - the ISDN provisioning process drawn up in Chapter 1 is a good example of this.

2. The exposition of an existing process that is a project dependency

The latter is particularly useful for the requirements discovery process that has been the focus of these first two chapters. In fact, you should attempt to make liberal use of it, and encourage everyone else to do so as well. What is interesting is that people can sit around a table for hours chatting or arguing about existing processes, or how a proposed process should work; but until someone starts drawing pictures, these conversations tend to go around in circles as everyone gets lost in the verbosity.

The other advice I would like to impart is that your workflow drawings should find their way into electronic form, be distributed as part of your normal correspondence, and be followed up. I cited an example of the benefit of this a few pages back. I studiously avoid mentioning products throughout this book to avoid the inference of approving or disapproving of any particular one, and will likewise remain mum on preferred products for drawing process flows. Chances are, however, that both your work and home computers probably have at least one program you can use to create this kind of document. All you really need is the ability to:

• Create and label boxes

• Move them around

• Draw arrows or use some other obvious means to show how the boxes interact, whether these dependencies are temporal or logical

Exhibit 5 is an example of a useful legacy from the voice mail provisioning workflow tale told in the success metrics section of the Big Thirteen in Chapter 1. You may recall that the crux of that project was minimizing provisioning errors. We eventually isolated the error source as nearly exclusively occurring in Step 8 illustrated in Exhibit 5. This was when the sales CSR manually entered information about the customer and the central office from which their new service would originate.

Exhibit 5: Voice Mail Provisioning Workflow

Although I did not understand all the technical ins and outs of this process, having investigated it to the level of detail described eventually facilitated development of the proper and cost-effective solution.

---