Don’t be a Rube

Great User Requirements Rule # 5:  Don’t automate a bad process

As you gain an understanding of the business process take advantage of the opportunity to make improvements.  See what the technology can do to lean out the process.

I love a good Rube Goldberg invention.  It is so much fun because the intent of the machine is never clear from first glance, so studying one is almost like doing a puzzle.  Even after I read the individual pieces, I often need to do a second read from beginning to end so that I can fully understand.

Self Operating Napkin
Professor Butts and the Self-Operating Napkin

Over time business processes can become like a Rube Goldberg invention.  In business nobody sets out to create a Rube Goldberg process, but it happens over time.  All of the little quirky aspects come up because small adjustments were made to deal with specific situations or to resolve some problem.  Each cracker being tossed to the parrot or rocket being lit was added to the process for a good reason.  Unfortunately, the organization can forget why they have a rabbit running on a small treadmill.  Perhaps the process steps were added a long time ago or the person who implemented the change is no longer with the company.

When implementing a system one of the worst things that can happen is automation of a bad business process.  This causes us to focus so much effort on setting up software for a situation that may be found so infrequently.  Even worse, when we set up the computer to automatically handle the fish jumping through a hoop, it becomes undetectable to the typical user.  The unexpected response of the system is confusing to the user and may even be reported as a defect.

fish hoop

During a system implementation, these crazy nuances can be difficult to deal with.  The implementation team may never be told that there needs to be a knife to cut the string holding up the bucket of water.  They find out late in the project or perhaps after go-live.  If the implementation team does know about the nuance in the process, it is possible the business no longer has a need for it.  The effort that went into setting up a snapping turtle to bite the tail of the dog was a waste.

Avoiding implementation of a bad process starts with a full understanding.  In prior blog posts, I wrote about asking the right questions and developing a process map.  These are fundamental tasks that will help to ensure the team is on the same page.  Often the business users forget that the bowling ball needs to go down the ramp to tip over the watering can.  Having the process map facilitates the discussion to draw this out of them.

Some situations are complex enough that an “As-Is” process map is necessary to document what currently happens and a “To-Be” is created for comparison purposes.  Personally, the only process map I care about is the To-Be, but sometimes the As-Is is a necessary first step.

Team members should also agree on some ground rules to ensure they are on the same page during this phase of the project.  Here are the guidelines I like to go by:

  • Do not design the system for the exceptions:  This does not mean the design is devoid of alternate process paths.  It means avoid spending time on situations that happen infrequently (80/20 rule is typically a good gauge).  Make a note of this scenario so that it can be worked out later during system setup.  Spending time on the infrequent scenarios will prevent you from moving beyond the design stage of the project.
  • Understand how frequently the exception scenarios occur
  • Recognize that not everything must be automated:  Assess the effort/benefit of automating exceptions.  A task that consumes 10 minutes of a person’s time every six months is not worth 35 hours of software development time.
  • Remember that intelligent human beings will use the computer system:  If an infrequently occurring situation arises, they will be able to deal with it.  Often the best way to deal with this is to ensure the user has easy access to all the information they will need to solve a problem.  Can a screen or report be provided with all the information a user needs to assess an deal with a variety of problems?
  • Keep in mind that adjustments can be later:  There is no reason the exception cannot be automated under a Phase II project.  The added benefit of this approach is that users have become familiar with the system and will be able to better understand how the Phase II features will work.

While it could be fun for a team to set up a woodpecker to peck through a piece of wood, causing a flame to light under a balloon, which pops scaring a monkey causing him to jump on a tube of toothpaste and dispensing some on the toothbrush; in the business world that is not worth the effort.   Those team members would be better advised to spend some of their time with the many Rube Goldberg enthusiast who set up contraptions on their own time.  Joseph Herscher is one such guy and here is a video of his invention that turns the page of a newspaper.

 

 

A Picture is Worth . . .

Great User Requirements Rule # 4:  Show a picture

Descriptions are great, but process maps can show so much more detail.  They also provide a way to ensure the entire process has been thought through.

Swing

The above cartoon has been around so long and there are so many derivations, I have no idea who should get credit for the original.  It is a great reminder that no matter how well a deliverable is described, there will be some critical details missed.  I often wonder what the original description was that led to so many interpretations.  Here is my guess; “We need you to construct a seat attached to this tree with the capability of moving in multiple directions to create the sensation of swinging for enjoyment purposes.”  To avoided the mess above, a lot of words would need to be written to properly describe what the customer needed.  That is not a task I would relish.

Architects use blueprints to confirm the customer agrees with a building design and to guide the work of the contractor.  Implementing a software system should be no different.  A customers needs can be easily reflected in a process map showing how work will be performed in the software.  The things I look for in a good business process map:

  • Business process focused – It does not try to show desired software features.
  • Recognize that rational people perform the process – The objective is not to program a computer.  People with brains, making rational decisions,  will perform the processes.
  • Shows the baseline process – Showing every possible exception is counterproductive.  Show how the process should work and any major deviations that routinely happen.
  • Neatly drawn – Crossed lines, reverse flow of logic, misaligned shapes, and other sloppiness make it difficult for someone to quickly grasp the concept of what is happening.
  • Easily understood – Anyone familiar with the business should be able to pick up the diagram and understand how the work is being performed.  Content that requires the reader to remember something from a prior discussion is insufficient.  Words should be kept brief and precise.  Two words (one verb and one noun) is ideal.
  • Supplemented by text – Text can be used to describe information about what happens in a process step.  This could be how decisions are made by the person performing the task and how exceptions are dealt with.
  • Consistent level of detail – Each process step should be at a similar level of detail.  For example, a process map with steps of “Receive Goods” and “Sign Name” are different levels of detail.
  • Decomposed – Process steps too high-level to fully communicate a concept should have a more detailed process flow to show details.
  • Contains simple shapes – The fewer shapes the better.  The reader will not be able to understand or remember the meaning of many shapes.  I like to stick with five: rectangle, oval (start/end), diamond, on-page connector, and off-page connector.  Sometimes I even drop the diamond decision symbol and have multiple labeled lines come out of a process flow, which is clear that a decision was made within the process step.
  • Logical flow – A properly developed process flow will help ensure the process is fully documented.  All process steps should lead to another stop or a start/end.  Decision diamonds have at least two outputs.

 

Here is a simple example that demonstrates the above rules.

Receive_Goods_process_flow_4

Notice how everything flows left to right.  When the first line reaches the end of the available space an on-screen connector is used to resume the left-to-right flow.  The lines are straight and boxes are aligned.  Process steps follow the verb-noun convention.  There are no orphaned process steps; “Rejected Delivery” goes to a terminator and “Sign for Delivery” goes to a connector that leads to another process flow.

The process is baseline, only showing major and routine exceptions.  For example, “Look Up Purchase Order” does not try to explain the logic if the PO cannot be found.  The process step “Confirm Delivery Matches PO” could be be either decomposed into a detailed diagram or a text work instruction could be provided.

Thorough process mapping can become complex as the number of flows increase and the many connections between them need to be accounted for.  This requires some organization that will be discussed in later posts along with more advanced process mapping techniques.

The old saying “A picture is worth . . .” is undeserved by the normal ending.  I would argue it should be more like “. . . ten thousand words.”