Topic: wftk -- Usage scenarios: trade show organization

wftk home ] [ usage scenarios ] [ discussion ]
(2/15/00) New! XML process definition.

Our next trick is the organization of a trade show. This was the second of the scenarios proposed in the original RFP, and after the chair scenario was so easy to model, I thought this was going to be simple. Let's look at the actual things done in this scenario. First, the person who initiates the workflow this time isn't a spectator, as the chairless employee was in the chair scenario. In this case, the person who initiates the process is the organizer. In the jargon, this role is often called a case worker because each instance of a process is a case (so, for instance, an insurance case or a loan application). The case worker is responsible for the entire process, even if other people are doing some or most or even all the actual processing.

So OK. Our first role is thus the Organizer, who is responsible for monitoring the process and making sure everything gets done. If people have problems, the organizer is the person who solves them. If special action is required, the organizer is the person who takes that action.

Since I've never organized a trade show, I made up four actions required. You can elaborate as you see fit. But in general, the whole process is kind of like this:

  1. Organizer assigns roles and starts process.
  2. Somebody books the hotel.
  3. Somebody creates a floor plan.
  4. Somebody roughs out a schedule.
  5. Somebody books the caterer.
  6. Produce a brochure listing the hotel, showing a floor plan and the schedule.
Obviously the entire process would be considerably more complicated: the booths are reserved, the rooms are blocked out, the tickets are sold, and so on and so forth. But this much already illustrates all that this example will illustrate, so I'm not going to waste time going into too much detail (although it might be interesting later to show a really complex example and this one would certainly be interesting to see in full-blown glory, with pictures and arrows and four-part harmony. For instance, booth reservation is a completely asynchronous task, depending on people outside the organization, communicating by mail or something.)

PERT charts and task dependencies
When I got down and started drawing the RAD for this process, I noticed a few things. First, the order of the tasks needn't be linear -- but they can't be done in just any order, either. For instance, the caterer could be booked before the hotel is booked, but we can't create a floor plan without knowing which hotel we're going to be in because we don't know the size or layout of the convention rooms there. The RAD isn't set up to represent this sort of prerequisite relationship. The graphical formalism most people use to show tasks which depend on one another is a bunch of boxes with arrows between them: a PERT chart. (PERT was formalized by the military and it stands for Program Evaluation and Review Technique. Sigh. These are the people who call a pair of glasses a Vision Correction Device.) The thing about the PERT chart is, everybody uses it automatically. It's the most natural way to show tasks in a project and which tasks have to be done first. Unfortunately, the PERT chart doesn't really show roles well, so it abstracts away some of the information most useful in the RAD.

Here is this project shown as a PERT chart:

As you can see, PERT charts are extremely easy to understand, which is the main reason everybody uses them. But after I drew this, I realized that it can be translated back into the RAD pretty easily, and this is the result:
Or is the organizer
Gr is a graphic designer
and X is everybody else.
Now, I find it easier to see the task dependencies in the PERT layout, but you can see the same structure in the RAD as well. Once this project gets into a sufficiently advanced state that we're considering graphical tools for workflow representation, I propose that we use both. (Another useful layout is the Gannt chart, which I won't be using in these usage scenarios, but suffice it to say that Microsoft Office uses PERT and Gannt for project display.)

Task assignment
Although task assignment was part of step 1 in the original description of this scenario, I don't think it belongs in the process definition at all, for a couple of reasons. First, we don't need to assign roles until each task becomes active. We might have some ideas about who should do what, but there's no reason to force that early on, because then we might just have to change it later anyway. Second, task assignment must ultimately be done in every project for every task, so it's silly to have to represent it in every one.

That said, task assignment could be as complex or as simple as it needs to be. A manager may assign all tasks. Or the different workers may choose tasks to suit themselves. Tasks may be prioritized, or some other system may be used to force task assignment: first-in-first-out, last-in-first-out, and so on. In fact, if we consider each role a queue, there is an entire branch of mathematics (strangely enough, called queue theory) which describes and compares different strategies of task assignment. Ultimately the workflow engine should support any number of task assignment strategies.

A further lesson about roles and task assignments is apparent from this process: basically, except for the special role of Organizer, anybody could perform the other tasks. Well, presumably the preparation of the brochure would fall to a graphic designer, but the other organizational tasks could easily be in a single role. The organizer could perform some or all of them, or could delegate all of them. They could be performed by one or more people.

This task is different from the chair scenario in a further respect: the process itself, and some of the internal tasks, have deliverables. A deliverable is an object or document which is created during the task or process, and which is the point of the process, usually. In this case, one deliverable is the brochure, another the floor plan, another the rough schedule. The deliverable of the overall process is in a sense all these together, as an information packet or something.

It might be a good idea to consider how such a process would be used, especially given that this is a usage scenario. A process is initiated either by anonymous trigger (say, a customer clicks on a customer-service form button), or by a system user (the chairless employee or the trade show organizer.) Each role can be considered a queue, as I mentioned above, and so the tasks which start the process off are placed in their respective role queues. The tasks are then assigned as specified in their own definitions: either they're assigned automatically, by hand by a manager, or people who belong to the roles choose tasks from the queue. Once a task is assigned (or chosen, depending on how you look at it), the task is active and the actor is working on it. A task may then complete normally, it may be thrown back (say the person assigned calls in sick; the task must be reassigned), or it may fail. (If it fails, this is an exception, and either the process must define an exception handling procedure, or the process owner must take some corrective action.)

As tasks are completed, they trigger new tasks, and notification may also be sent to various people. These new tasks enter their respective queues as they are activated, and so forth.

Compound workflow
(1/24/00) After the above was posted, Anthony O'Krongly came back with some excellent feedback, to wit:

The trade show flowchart is a good attempt. It doesn't correspond with what we do, but it does show another example of how the application will work.

Let me see if I can explain what I was thinking when I put that in. (You don't have to change the existing chart. This is just a demonstration of our vision.)

#1. Take each item in the existing workflow and make it a separate workflow similar to the detail included in the "Chair Request" workflow. Booking hotel, creating a schedule, creating a floor plan, etc. would each be a separate and distinct workflow.

This does two things.

  1. It keeps it simple. Each workflow can be set up as needed by the person who most intimately understands what's involved.
  2. It keeps it flexible. By "Grouping" (See #2 Below) simple workflows into "Compound" workflows the system becomes very flexible. If one piece of the Compound workflow no longer applies, it can be quickly and easily removed. The same is true if you want to change a piece of a workflow. Some very simple workflows would be used repeatedly in numerous compound workflows. I can't think of an example at the moment, but it will happen. Then if some aspect of that often reused simple flow changes, then all the others will change automatically.

#2. We saw a workflow as complex as a Tradeshow setup being comprised of multiple simple workflows that are all GROUPED TOGETHER. Let's call this a COMPLEX workflow.

Does it sound crazy? Let's call it the Internet Chaos Paradigm. Take something as complicated as the Internet. Billions of pages, millions of sites, etc. It's crazy and unmanageable!!! But with each person doing their own part in their little corner of the web it works out fairly well. Give users an easy, consistent interface and all of a sudden something which is Chaos Incarnate becomes smooth sailing.

So, here's how it relates to our little application.

Sally, the buffet booker, sets up a workflow that helps her set up a buffet. Jon, the media guru, sets up a workflow that helps him coordinate hotel media for meetings. Steven, the Tradeshow booth expert, sets up a workflow that helps him plan booth space layouts Etc. Etc.

Now Vice President G.O. Devine (GOD for short)- who is over the tradeshow department wants to set up a master workflow for setting up a tradeshow. Since he's a bright guy with a Management Degree and a 2 pm Tee Time, he takes all the flows created by his busy minions and groups them together. Maybe he adds a little workflow in front of the group that says, "Start the busy bees on their tasks". His "intro workflow" might notify some people of deadlines or whatever. He call this Complex workflow "The Hand of GOD"

A client calls and says, "I want a tradeshow". GOD runs his "Hand of God" workflow. It asks for some info and then starts all the other workflows when it gets to them. Viola, the simple becomes complex. The hard to manage becomes easy. The incomprehensible becomes compre.... You get the idea.

Now, I know I left out some details. But that's the goal. Goal #1 - Figure out a way to make a simple workflow. Goal #2 - Figure out a way to group simple workflows TOGETHER both linearly and in parallel. Goal #3 - Go have a beer because you're done.

In short, the existing RAD works pretty well, as long as you realize that a task may actually represent an entire process. Actually, we're going to see some more examples of this in a couple of the other usage scenarios but Anthony's vision of cooperative workflow is just so impressive I had to include it now. This allows the organization of workflow to mirror the organization of the work -- Susan knows about buffets and so Susan defines what it is she does. GOD wants to make sure the whole trade show comes off and so his workflow coordinates everybody else's. When Susan realizes her process doesn't work very well, she can change it -- and nobody else is affected in the least! It's beautiful.

Again, a short list of things that look like requirements:

  • Tasks may have deliverables.
  • Tasks may have complex dependency relationships.
  • PERT charts are nice.
  • Roles are queues, and task assignment may be arbitrarily complex.
  • Exception handling (what to do when things go wrong) must be handled, if not perfectly then at least gracefully.
  • An individual task may represent a subprocess.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.