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.

 

 

Life, the Universe, and Everything

Great User Requirements Rule # 3:  Ask questions in the right way

Information gathered from the users should be about how the business works, not about software features.  After the business needs are known, an expert can present the options to fulfill those needs.

The_Hitchhiker's_Guide_to_the_Galaxy

“42” is the answer to the Ultimate Question of Life, the Universe, and Everything as revealed in Douglas Adams book The Hitchhiker’s Guide to the Galaxy.  This puzzling answer is provided by a computer known as Deep Thought.  Deep Thought explained the answer was incomprehensible because those who asked the question did not understand what they were asking.  A more powerful computer would need to be built to properly explain the question.  This computer, often mistaken for the planet Earth, was unfortunately destroyed just five minutes prior to revealing the question.

There is a skill-set associated with asking the right questions.  Unfortunately, Business Analysts often frame their questions in the context a software feature rather than to understand a business need.  The problem with asking questions about software features is the delivered solution can be a puzzling.    Understanding business needs provides the background a Business Analyst requires to identify options and recommend an approach.

A software product I currently work with has four key fields that categorize orders.  Setting these fields properly is important as it drives a lot of system functionality.  It also locks the customer into certain ways of using the system for years to come because adjustments will impact historical data, system settings, and procedures to use the system.  In the past the discussion with the customer went like this: “Here are four fields used to categorize your orders in the system.  How would you like to categorize your orders?”  A customer not knowing all the implications of these fields will provide their best answer.  Often the consequences of an uninformed decision materialized well after the customer was live on the software.

A better practice I instituted is to have the Business Analyst ask a full set of business related questions that accounts for all the downstream effects of those four fields.  This includes questions designed to understand how work is organized amongst employees, commission calculation, how revenue is broken out by accounting, and how operational reports are organized.  With this information we can then provide a recommendation on use of these four fields.  An additional benefit of this approach is that we can recommend the bare minimum use of these fields, leaving the customer’s options open in the future if there is a business change requiring use of an additional field.

The above approach requires some additional effort initially, but saves a lot of time on the back-end eliminating adjustments to the delivered solution.  Preparation is required to ensure that all the down-stream impacts of the design are fully known.  System users know their business, not software features, so Business Analysts need to be prepared to talk the language of the customer.

We had a customer once that was insistent on putting into place a system feature that enables his system to talk to the on-board computers of his carrier’s trucks.  The team spent a lot of time talking about this software feature without understanding the background of what he was trying to achieve.  The outcome was a sub-optimal solution as the system would need to have records for each of his carrier’s trucks and track when each of them is dispatched; an administrative nightmare.  Had the team understood the underlying business needs, they would have known that the customer simply needed to know where the loads were for the purposes of alerting the store of the incoming shipment.   Once known several simpler solutions were quickly identified.

Asking questions in the right way is not a skill-set that is quickly acquired.  There can be some training to help a Business Analyst focus on business needs and how to write good business requirements.  This foundation can be supplemented with observation of someone who has great interviewing skills and to have a coach present as they begin their own interviews.  A technique some find helpful is the 5 Whys.

The key to getting started with the right questions is awareness of the Business Analyst’s obligation to fully understand the business practice.  Make sure your questions are focused on a business objective and answers clearly explain the root cause for performing that business action.  Is it value added or just something that has always been done that way?  If no value can be articulated, could the business practice be eliminated?  Until you understand this detail you have not probed far enough.