Workflow management isn’t about online forms

Putting a process on line isn’t just putting the forms on a website.  This is how most people treat workflow management software, though, so it’s no surprise that they hate the software.  I recently experienced such a system, and I can see why people hate it.

For example, in this system, let’s say that I want to get support for a production server.  I have to submit a support ticket, but not just any support ticket will do.  There are about 30, yes 30, types of support tickets I can choose from!  Why are there so many?  Because each group who supports some system wanted their own form.  And so the very first thing I have to do in the process of getting support is to make a decision – which ticket is the right ticket to open?  Get it wrong and I have to start the process all over again!  In reality, first I have to fill in a long form, effectively get the whole thing wrong and then do it again once my form is rejected and they tell me which form was actually the correct form.  Does it start to make your feel like you’re in a ridiculous government bureaucracy?  It does to me!

First off, it’s suboptimal that I have to make a decision about who gets the ticket in the first place.  Whether I had a single form or 30 is irrelevant.  Why do I have to tell people who gets the form?  I have no idea about the way support has their departments set up, and frankly I don’t care!  Really and truly, I don’t.  Secondly, if you are going to make me choose who gets the ticket, why do I get punished so heavily when I choose incorrectly?  I have to completely re-enter the same data on a different form.

It’s a great example of how people mistreat workflow management.  The process for me, includes deciding which group gets the ticket.  Why is that critical step, the very first step I can so easily screw up, not automated?  Why is it that the magical decision tree about which form is right is a) nowhere to be found and b) not done for me?

The second example I have seen is very similar.  Every time someone closes a defect tracking ticket they must assign it a root cause.  The root cause data helps us figure out where we want to improve the process.  In fact, the first improvement would be to improve the root cause collection system.  As it is, people are given a list of choices such as “requirements issue”, “design issue”, “coding issue”, etc.  We don’t provide the definitions of what each one means, although it might seem obvious.  That is, until you get to the next step.  In the next step, once you’ve chosen a root cause, you must choose a slightly more detailed cause.  For coding, for example, there’s “internal error” or “vendor error.”  It all seems well and good until you get to this ambiguous one “not coded according to requirements.”

I have always read this to mean “the requirement was clear but the developer didn’t code it that way anyway.”  And yet, the other day someone said “no, it means that the requirement was ambiguous so that the developer didn’t know what to code.”  Really?  I didn’t get that from the description.  Again, here’s a great example of leaving the process offline while having the form on line.

In order to arrive at the root cause, there are a series of questions you have to ask yourself.  It forms a decision tree.  Assuming you follow the decision tree, you get the right root cause.  If you don’t, and make a guess, you get what we have above which is a misunderstanding over what it means to have something “not coded to requirements.”  Instead of asking someone what the root cause is, ask them the questions from the decision tree.  Because the questions are simple yes/no questions, by the time they get to the end of the decision tree, it’s already been decided what the root cause is.

Was there a requirement for this defect?  If no, it’s a missing requirement.  If yes, continue.  Was the requirement clear?  If no, it’s a vague or incomplete requirement.  If yes, continue.  Did the design take the requirement into consideration?  If no, it was a design flaw.  If yes, continue.  Did the developer code the requirement as written?  If no, it is a requirement not coded as written.  And so on… you see how it goes.  But don’t just give me a drop down for the root cause.  Ask the questions.

The point is simple.  If you only have half the process on line, for example, just the forms, then the rest of the process is occurring without any errorproofing.  What’s the point of using workflow management for half the job?

Leave a Reply

Your email address will not be published. Required fields are marked *