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.

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.

Ten Rules for Great User Requirements

Who doesn’t like a good top ten list?  There are websites devoted to them.  David Letterman presented 4,605 on his show.  My favorite was Top Ten Numbers Between One and Ten.  Out of concerns over copyright infringement, I am not going to repeat it here; you will just need to guess 😉

top_10

Well, here is my list focused on software implementation.  I will keep it brief as each of these items can consume an entire post of its own.

  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.
  2. Align with the business process – Unless the business process is fully understood, chances of the system adding value are slim.
  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.
  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.
  5. Don’t automate a bad process – As you are understanding the business process take advantage of the opportunity to make improvements.  See what the technology can do to lean out the process.
  6. Don’t chase the shiny objects – Focus on the business needs, not the cool system features.  A great tool looking for a problem to solve is a recipe for a wasteful project.
  7. Get it signed – A formal signature confirms alignment.  A need to look back at the requirements for reference confirms you are looking at the proper version.
  8. Don’t over-design the process – No need to design for every exception.  Ensure the baseline processes are covered and work out the exception handling during the implementation.  If there are exceptions discussed during requirements gathering, capture them for later.
  9. Keep the pedal to the metal – Information gets stale over time.  Old discussions are forgotten or remembered in different ways.  It is best to close out the requirements discussion, get them clearly written up, and signed-off as quickly as possible.
  10. Think about the end game – A well organized set of requirements will make life much easier to track implementation tasks, prepare for system validation, and prepare for training.  This is especially true if it is in the context of process maps.

Stay tuned.  More to follow on each of these in future postings.

 

Until We Master the Force . . .

The Jedi Knights use the Force to guide their actions.  “It’s an energy field created by all living things. It surrounds us and penetrates us; it binds the galaxy together.” – Obi-Wan Kenobi

SW blast shield
“But with the Blast-Shield down, I can’t see!”

I am amazed by the number of people who believe the Force is the best method to implement software.  With nothing visible in place to direct project activities, I can only assume they are relying on the force.  Unfortunately, I have not run into implementers / developers who have mastered the Force, dooming them to long, and frequently unsuccessful, projects.

A good set of requirements can go a long way to guide our actions during the project.  Unfortunately, this is frequently skipped or inadequate.  Why?  Here are some of the excuses I hear:

“There is no point; it will change during the project” 
All the more reason to have the blueprint established.  This is the vehicle that should be used to lead a discussion on the consequences of making a change.  Is this really a change from what was already agreed upon?  Will the change result in rework?  Does it add time/cost to the project?  Is it a “must-have” or a “nice-to-have”?

“I don’t know how”
An understandable dilemma.  This is a skill-set not many people have.  In fact, I find it interesting there is not a standard approach.  Other skill-sets on a project have a fairly standard set of techniques established; e.g. Project Management.  Even after working in the industry for so long, I couldn’t point a person in the right direction to gain such knowledge.  I hope this blog will address that and provide a practical method to establish a requirements document.

“We do not have time”
The most prevalent (and lamest) reason I encounter.  How could you afford not to have a requirement document in place?  Having no plan in place that describes the final solution is a plan for failure.  You would be crazy to hire a contractor to build a house without blueprints, so why hire a contractor to build a software system with no plans?  I believe this excuse is typically a different version of “I don’t know how”.  Generally when I hear this excuse and I provide some coaching, I am able to show the benefit.

 

Yodalukedagobah
“No more training do you require. Already know you that which you need . . . One thing remains. Vadar. You must confront Vadar.”

 

Until we master the force . . . the next best thing is a user requirements document.  Coming up next . . .the journey to good user requirements.

Management Must be Crazy

Implement

Implementing software can create an experience for users much like the characters in the film The Gods Must be Crazy.  The gist of the movie is that a remote tribe suddenly encounters modern technology.

“Lately strange new things appears in the sky . . . noisy birds flew without flapping their wings.  One day something fell from the sky.  It looked like water, but was harder than anything else in the world.  He wondered why the gods had sent this thing down to earth.”

The “thing” was an empty Coke bottle.

the_gods_must_be_crazy_still3

Sound familiar?  What about this version?

“Lately these strange new consultants have been passing through . . . they are very noisy.  One day they dropped in this new software.  It looked interesting, but it was harder than anything else in the world to use.  He wondered why management had sent this thing down to them.”

In the movie, the tribe is puzzled by this technology.  They invent uses for the bottle, none of which are for its intended purpose:

  • Curing snake skin
  • Making music
  • Decorating cloth
  • Milling grain
  • Opening goads

While the bottle was seen by the tribe as a great technology, it caused fighting and arguments leading the elders to decide it must be returned to the gods.  This sends one of their members on a trek to the end of the world to return the bottle.

gods must be crazy cliff

Users, while initially enamored by new software become frustrated when they do not understand it.  Many time we see users make the best of situation, using the system in non-productive ways.  In the most extreme cases it is dysfunctional enough that management will abandon the system; a colossal waste of time, money, and employee goodwill.

In my 20+ years of implementing software, I typically hear blame placed on poor project management, lack of training, inadequate management support, and inaccurate setup/configuration.  Rarely do I hear the root cause discussed: “we did not have a good method of confirming the business needs were understood and using them to guide the rest of the project.”  Having a solid set of requirements will mitigate the typical issues I mentioned above.

Often the task of defining requirements falls on someone with a title like “Business Analyst”, “Solution Architect”, “Implementer”, or “Business Consultant”.  Frequently I find professionals in these roles to be well trained in the technology, but lacking the ability to synthesize system requirements in a way that is useful for all stakeholders.  There is the further challenge that different functional areas are unable to effectively integrate their requirements.

I want to change that.  I have developed a holistic approach to system implementations that provides a method for understanding business needs and leveraging that to ensure success for the rest of the project.  This blog is devoted to explaining that approach and helping others to become Implementation eXperts.