Turn Right to Go Left

Doc Hudson: I’ll put it simple: if you’re going hard enough left, you’ll find yourself turning right.
Lightning McQueen: Oh, right. That makes perfect sense. Turn right to go left. Yes, thank you! Or should I say No, thank you, because in Opposite World, maybe that really means thank you.

In the above exchange from the movie Cars, Doc Hudson is explaining to Lightning McQueen the effect that dirt track drivers call drifting.  Drifting occurs when the rear wheels of the vehicle loose traction and slide around as the car goes around a curve.  With Lightning’s experience on paved tracks he has no idea what Doc is talking about.  The drifting technique is best demonstrated by Doc in the following clip:


I feel as though I talk frequently to Lightning McQueen when implementing software systems.  When I talk about the need to develop written specifications I hear “we do not have time to develop specifications”, “we know what we are doing so there is no need”, or “our customers are on a tight budget so we cannot afford to write specifications”.  My typical response is “how could you afford not to write specifications.”  The implications of failing to write specifications is that you spend several times the original effort fixing problems.  Just because you know what you are doing does not mean you are aligned with customer expectations.

Earlier in the movie McQueen learns the hard way that turning left around the dirt track leads to him skidding into the cacti as he attempts to race Doc.  Being a young race car with more energy than practical experience on dirt he cannot understand what happens.  Later in the movie he tries over and over to make the turn and fails; even after Doc tries to explain the concept.

I can see how that happens to someone implementing a system.  They get a piece of advice that is so far removed from their frame of reference they are not able to process it.  They have always thought the way to implement a system is to rush through the initial setup and then rework, rework, rework.  They were the super-hero that used brute force and multiple tries to finally get it to work.  Meanwhile the customer has a horrible experience suffering through multiple drawn-out failures causing them to inspect quality into the work product.

The written specification ensures that all parties agree to what will be delivered.  Without it a decision made during the build that does not align with the customer’s expectations is the same as defect.  Why not eliminate this ambiguity before starting development?

As with McQueen, the system implementer with a completely different frame of reference frequently is told about the right way to do something, but cannot imagine it to be true.  Seeing may be the only way to make them a believer.

Where I work, custom developed interfaces delivered to customers gave me the feeling that we were sliding off the track only to be pulled out by Tow Mater over and over again so that we could start over.


I picked an upcoming project with a need for heavy integration and told the team of a new requirement for approved technical specifications for each integration point.  I heard all the objections I identified above.  After that I heard an extra special objection: “we copy similar integrations, so we are not able to explain exactly what happens.”

There were a couple of bad assumptions made in the specifications that caused issues in the written code.  The good news is the customer had ownership in those assumptions because they signed off on the spec.  We adjusted the spec and simply moved on with everyone agreeing that it was a change (not a defect).   We brought that project to closure on time, much quicker than any other project with custom integration.  At the end the customer told us that their experience on this project was far superior to the past experience.

The best part of this project was that the team bought into the methodology and has become advocates.

As with McQueen learning to drift, after some practice, development specifications are becoming the new “way things are done” and I am proud of the team for making this transformation.

piston cup

Don’t Cross the Streams

Spengler: There’s something very important I forgot to tell you.
Venkman: What?
Spengler: Don’t cross the streams.
Venkman: Why?
Spengler: It would be bad.
Venkman: I’m fuzzy on the whole good/bad thing. What do you mean, “bad”?
Spengler: Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.
Stantz: Total protonic reversal!
Venkman: Right. That’s bad. Okay. All right. Important safety tip. Thanks, Egon.

Early in my career I was assigned to an SAP implementation project and received a task to create a financial statement.  I was given a printout of a report from the legacy system and given the requirement of “Create this report in SAP.”  No explanation of which accounts go with particular lines, no explanation of report parameters, and no explanation of how the math was to work.

Back in the day these reports were written using SAP’s proprietary programming language, ABAP, which was similar to COBOL.  Getting the right business logic was the big challenge and getting the formatting to line up properly was tedious.  I thought I had done really well figuring out the business logic and was proud that I had done so on my own with the bare-bones requirements.  The tedium of doing the formatting was all that was left, and before doing that I wanted confirm I had the business logic correct.  I passed the report on to the user in the Finance department with the request that he confirm the numbers were right.

What I received back was a marked-up report showing the formatting problems.  This user wanted a double-underline before the grand-total and the numbers needed to be preceded by dollar signs.  There was no review of the actual figures.  It was frustrating to receive the report back with that feedback and a waste of time given it did not add any value to the project task.

At the time, I thought this user had performed an a-hole move that was really an avoidance of having to do any real work.  Looking back on it, there was a lesson to be learned — aesthetics can be a roadblock to a meaningful conversation.  Research has shown that first impressions are made within the first seven seconds.  If those seven seconds are spent trying to decipher something, then the impression is that the work is shoddy.

Consider these two process maps that convey the same business logic:

Receive_Goods_process_flow_sloppy_2  Receive_Goods_process_flow_4

The process on the left is difficult to follow with all the crossed lines, loops, different fonts, and unnecessary shapes.  Logically it makes sense, but there is some significant mental capital that is spent trying to understand it.  By the time the reader figures out how to follow the logic, they are not focused on the outcome of the process.  The streams are crossed, which is bad.

The process flow on the right eliminates confusion by avoiding the crossed lines, having a simple left-to-right flow, and a limited set of symbols to follow.  It looks like someone put some care and effort into developing it.  With that attention paid to the format, surely the creator paid attention to the business logic.  No need to worry about every molecule in your body exploding at the speed of light.


Van Halen always had a clause in their contract rider that promoters must provide a bowl of M&Ms containing absolutely no brown ones.  At the time many people thought that was some ridiculous request included as a joke.  The real reason for it was that it was a quick indicator that the promoter had thoroughly read the contract.  Failure to eliminate the brown M&M’s and there is a good chance the promoter failed to address the electrical requirements for the complex lighting system, which could cause significant safety issues.

People will use the superficial aspects of a work product as the initial indicator that the care has been put into the part that really matters.  This may not always be a conscious decision, but it does create biases in our minds.  There will always be times where we share rough work product with a close team member, but that should be with someone where the right working relationship has been developed.  Work presented to a customer or management should be presented in polished format that shows you have taken pride in all aspects of the work.  The process flow streams should not be crossed.

Division of Labor

One of the most expensive cars in the world is the Ferrari LaFerrari with a price tag of $1.4M.  Ferrari cars are hand-built and described by the manufacturer as a “unique piece of art”.  Customers specify their options which include 16 exterior colors, 12 leather types, 8 carpet colors, and 3 trim options, making 4 million ways to build a Ferrari.  Ferrari produces only 5,400 cars per year, ensuring owners have a unique vehicle.

By comparison, Toyota produced over 10 million vehicles a year.  At this volume you can be certain that these are not hand-made and that a single technician does not produce an entire engine.  And by the way, these vehicles cost a lot less.

Division of labor is a concept introduced to auto manufacturing by Henry Ford in the early 20th century.  Ford broke work up into smaller pieces and standardized it.  This simplified his training of employees and ensured they became extremely proficient at their particular tasks.

I had a fascinating discussion with a colleague from the Northeast chapter of the Project Management Institute a few months back at the PMI Region 4 leadership conference.  This colleague works for one of the large insurance companies (I will refer to it as Acme) and was telling me about some of the work they do in their call centers.  Acme employs some individuals with the title of “Data Scientist”.  This term can mean a lot of things, so we dove into some of the details on what this role means for Acme.

Here is a summary that aligns with our conversation that I lifted from mastersindatascience.org:

Data scientists are big data wranglers. They take an enormous mass of messy data points (unstructured and structured) and use their formidable skills in math, statistics and programming to clean, massage and organize them. Then they apply all their analytic powers – industry knowledge, contextual understanding, skepticism of existing assumptions – to uncover hidden solutions to business challenges.

Acme is using their data scientists to analyze massive volumes of data from the call centers for the purposes of predicting a customer’s need.  Transcribed recordings of calls are run through statistical models to identify certain patterns.  Those patterns are plugged into an application built by the data scientists.  The result is that when communicating with Acme via the chat function on their website, you may actually be having an exchange with a bot.


The data scientist, as an emerging profession, covers a wide range of topics.  As this profession evolves, I would expect that specialties develop.

This feels to me much like the field of computer programming years ago.  At the time there were computer programmers doing extraordinary things working directly with businesses.  The programmers listened to the business needs and determined how to code the applications to meet those needs.  Eventually the field of Business Analysis evolved.  These were the people who had a good understanding of how the business functions and were able to more quickly identify the business needs and formulate something that was useful for the programmers.  The business analysts brought to the table the ability to speak both the language of the business and the language of the programmer.  Having that translated allowed the programmers to focus on developing outstanding applications.

Programming as a profession has been around for may years and the training, techniques, and job expectations have been pretty well formed.  With the Business Analyst having been around for some years, but being relatively new, the profession is not nearly as defined.  People come into this role with much different background employing much different techniques.  This makes me think the data scientist role will split at some time in the future, as the programmer / business analyst developed.

So what are the implications of separating these professions?  Efficiency and cost.  Having someone who is really good at defining business needs, really good at analyzing data, and really good at programming is not very common.  It is as though these high-caliber individuals are hand-building the $1.4M Ferrari.  If you are able to perfect the profession of the Business Analyst, you can start to implement a system at the cost of the Toyota.

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.


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.


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.”


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.


“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.

Building On Sand

Great User Requirements Rule # 1:  Write it down

Writing down the requirements is the first step toward alignment.  The act of writing requirements forces us to boil it down to the essentials and provides a mechanism to play it back to the system owner.

Sand Castle

I enjoy building sand castles with my kids at the beach.  Normally we start by digging a moat.  The sand from the moat provides good material for the structure and as well as the walls.  Although we have fun building the castle, inevitably the venture is doomed.  During the construction a foot may be inaccurately placed, causing part of the ground to shift resulting in damage.  This forces us to stop and improvise as we spend time on the repair.  The tide is another factor that can cause us to deviate from our initial plans.  The water coming close to the castle moat causes the sand to shift resulting in even more damage to be repaired.

The kids and I have fun with the process of constructing the castle.  Fortunately, we are not accountable for delivering a final product.  With the constant shifting of sand and changing conditions we can never say the project is fully complete nor does it look like we initially imagined.  We could overcome these problems with a good set of blueprints at the beginning and driving piles deep into the sand on which we would build a stable foundation.  But we are on vacation, so that is not going to happen.

While skipping the detail planning for a sand castle is okay, doing so for a computer system is a setup for failure.  Unlike the sand castle, there are expectations that a computer system is delivered that meets a certain business need, is completed on-time, and is within budget.  Delivering these things requires that a picture of the end product be first established, which is done through a user requirements document.  The requirements document will serve as the blueprint and ensure the foundation piles are in place.

Much like the sand at the beach things shift and change in the business world.  Often needs change during the course of a systems implementation.  Having an established requirements document enables the team to recognize the significance of changes and communicate the impact.  Design documents can be easily modified to accommodate changing business needs.

Failure to have approved requirements leaves things open to interpretation.  A discussion with users causes both parties in the conversation to make their own little assumptions as they fill in the unspoken detail.  A well written requirements document will fill in the gaps with statements that stand on their own, thus eliminating gaps caused by differing assumptions.  Having the document in writing allows all parties to sign indicating the system, as designed, will satisfy the business needs.

Without an initial design someone will insist the shifted sand has always been that way; the team simply misunderstood the needs as they were initially discussed.  Overcome this by having a clear blueprint that maps the path to success.