Motivation
The past is littered with examples of building the wrong thing. For an informative list go to the Catalog of Catastrophes, from the University of British Columbia, Sauder School of Business
http://calleam.com/WTPF/?page_id=3
One example is the 2020 failure of the Iowa Caucus app. In February of 2020, Iowa attempted to do caucus reporting with a new ‘Iowa Reports’ app. While it easy to criticize in hindsight, it is clear that an careful elicitation would have uncovered the following facts:
- That the application would cost significantly more than the bid;
- That the each of caucus chairpersons needed to be trained and that the app needed to be loaded before the caucus; and,
- What the expected load and level of chaos of an actual caucus was likely to be, so that testing could have been done properly.
The failure to elicit the complexity of the actual problem led to an internationally embarrassing situation.
While not every failure can be prevented, a careful elicitation will give you a much better chance of building the correct thing.
What is elicitation?
Elicitation is the process of discovering what your client really needs and translating the result of that discovery into requirements. But, you might say “You just ask the client what they need, and you build that for them.” That is an invitation to disaster, sometimes it might work, but most of the time, the client does not know what they need. Later, I will discuss a few reasons why this is true, but, in my experience (I have been doing elicitation as part of our consulting practice for over 20 years), it is generally true. This fact means that you need to work with the client (and possibly other stakeholders) to discover the true extent of the problem, and come up with solutions that will work for that client. I will talk about the “shape” of a solution. This is shorthand for the nature of a solution that will meet the client’s needs, not violate their culture, and have a look and feel that they find acceptable.
Why should I do it?
Because there is nothing worse that building the wrong solution. This is generally a very expensive mistake. There are the hard costs, the cost of building the wrong thing and the cost of correcting or rebuilding the right thing. Then there are the soft costs, the cost in reputation, but also the cost in self esteem. After all is said and done, we want to be able to do the best job possible for our clients.
There are a few ways that a solution can be wrong. It could solve the wrong problem. This often is a result of a superficial assessment. It could solve the right problem, but not be a solution that the client can use. This could be for technical or, more commonly, for cultural reasons. Many of these problems are discussed in the field of Requirements Engineering.
Understanding the problem
There are a few reasons that the client does not understand the problem, The first, and most common, is that the client is too close to the problem. This will show up in comments like “But, we have always done X this way” or “There is no other way to do Y”. They may not think that a solution is possible. You bring a new point of view, without the preconceptions that a person in the trenches will have. This is particularly true if the problem has grown steadily worse over time. When it started, it was manageable, but it got worse. Your job is to ask why that happened and what the shape of a good solution would be.
Another possible reason is that they are not experts, as you are, in the technical domain. What you bring to the table is a set of specific solutions. These may be in constructing new and better data visualization techniques, constructing new data structures, constructing a predictive model, or constructing code based middle ware. They own the problem domain, you own the solution domain. Note that, in order for this to work, you must embark on a course of lifetime learning, in order to be familiar with a number of possible solutions for each problem domain (not just your favorite solutions).
Yet another possible reason is that the client is conflating two causes into one problem. The two causes may have very different solutions, or only one of them may need to be solved. You have to consider the problem space carefully and analytically. Because you have an outsider’s view, you have the ability to ask questions about what is really needed.
How to conduct an elicitation
First , you need to learn their pro lems. This involves a lot of listening. Fortunately most people love to talk about their jobs, particularly the parts that they hate to do. Another powerful tool is watching the customer do their job. Either by shadowing or embedding with the customer, you will see parts of the problem that the customer may not consciously recognize. You will also at this stage want to do some research into the domain of the problem. It will build your credibility with the client if you can ask reasonably knowledgeable questions. Remember that they are the expert in their domain. Your job is to learn enough about it to propose solutions. While you are learning their domain, you also need to learn about their culture. If the client runs a strictly Windows© shop, then proposing a Linux based solution will probably not fly. Do not offer a specific solution at this time, although this is a very good time to explore what the shape of the “ideal” solution might be. Elicitation is about exploring the problem with the client.
One thing to be aware of, is that you may have identified multiple problems. The following process must be followed with each of the identified problems.
Once you have learned enough to start considering solutions, then then you must take the time to elaborate possible solutions. Start with the most obvious solutions and work your way out to the wild ones. Then critique them, be harsh, try to crash them. Consider ways in which each solution could fail, due to cost, cultural, and technical reasons. If you have done the first step well, you should be able to come up with two or three possible solutions. Take the winner(s) and sketch it (them) up. Do not solve the problem at this stage, but explore the shape of the solution.
Cycle back to the client, with enough of a sketch that they can discuss the solution with you. They often will have good reasons why this solution will not work. Take those concerns and go back to the drawing board.
Wash, rinse, repeat. Keep doing this until you and the client agree on the shape of the solution. Then, and only then, start constructing the solution. Depending on the nature of the solution, you may work closely with the client or you may work at more of a remove from them. But make sure that you keep the client in the loop.
Capturing the requirements
The solution is defined by the requirements discovered in the elicitation process. The work of capturing the requirements should be happening during the work of eliciting the client’s solution. They can be captured as requirements or as user stories, depending on your team, your client’s needs, or other considerations (such as the complexity of the project). A good requirement/user story will be clear, short, and testable. Discussing the requirements is an essential part of your interaction with the client. The client will tell you when you have the right solution.
A good, agreed upon requirements set will help to avoid “feature creep”. When the initial problem is solved, anything else is embellishment.
Conclusions
A good job of elicitation at the beginning of a job will save you a tremendous amount of trouble at the end of the job. Remember that the problem domain is not yours, so be respectful of the knowledge of the client, they know the problem better than you ever will. Do not look to your favorite tool to solve all of the problems. If it is the right tool, that is great. If it is not the right tool, that is even better – because then you get to learn a new tool.As an added benefit, you get to learn about a new domain, and that is always fun.
About the Author:
LOUISE GUNDERSON, PHD
As a Systems Engineer with 25 years experience, Dr. Gunderson focuses on working with clients to help them determine what they really need and then designs complete solutions that work with the technology, the business culture, and the people to integrate a working system into their business.
With multiple degrees in fields ranging from Biology to Systems Engineering, Louise brings an impressive array of skills to bear on our client’s problems. She integrates a broad understanding of problem elicitation, complex data analysis tools and a strong ability to cut to the core of the underlying models that make up successful data analysis tools.