Let’s face it. Way too many projects fail. And they often fail because of low user adoption. Users hate the new processes, they dislike the new report style, they are not sure how to best use the new planning software. Project managers claim that the users are not open to change. Sounds familiar? But when we look at it carefully, a lot of the issues boil down to how we gather user requirements.
THE PROBLEM WITH REQUIREMENTS GATHERING
In my very first job, a senior colleague invited me to join a critical requirements gathering session for an SAP implementation. He had prepared an intricate questionnaire (By the way, he called this process a ‘JAD session’ as in Joint Application Development). We met with the users and he rattled off a ton of detailed questions. I was impressed. The users weren’t. They struggled with a lot of the questions and my colleague left frustrated. His message to me was: “Users never know what they want. This is the most frustrating aspect of our business.” To make a long story short, the users ended up not liking what they received. When my team mate pointed at the signed off requirements document an angry user replied: “Sure, I signed off on this document but this is not what I had expected.” This type of situation happens everywhere. But what is causing this problem?
HORROR IN THE KITCHEN
A few years ago, we moved from San Francisco to Europe. We ended up renting a house that did not have a kitchen. No big deal, I thought, and went to the first kitchen store I could find. The friendly sales person started rattling off a ton questions: What type of stove do you want? Have you thought about the size of your fridge? How many liters of storage space do you need? It went on and on. I had no answers for this person. Strange. I love to cook, I spend a lot of time in my kitchen. Yet, I was not able to provide satisfactory answers. And the sales person got frustrated with me. He suggested we take a break and reconvene after I had done some soul-searching. Sounds familiar? Any similarities to the standard requirements gathering process? Well, I aborted the process at that point and found another store that clearly knew how to help me.
A FEW IDEAS
Here are three ideas for making that requirements gathering session easier and to help drive user satisfaction:
- Business problems come first: The traditional requirements gathering process focuses on features and functions (which fields do you need in the report, how do you calculate this metric). There is a place for that, but let’s start focusing on what the users are actually trying to accomplish. Ask questions like: “What do you use this report for? What problems are you trying to solve with this? Has this been useful in the past?” We are in the business of solving business problems after all. So let’s focus on that. By asking those type of questions first we are able to make new connections and we are able to guide the discussion proactively. I went to another kitchen store and found a great sales person. He asked me a ton of questions around our family life-style, looked at pictures from the prior kitchen, etc.. He got the big picture. Also, I felt at ease. This person clearly showed an interest in helping me.
- Stop asking users for what they want and start showing them how the world could be: We don’t know what we don’t know. It’s that simple. Look at a user who has been using a certain set of paper-based two-dimensional reports: that person would not know how to articulate the requirements for a multi-dimensional online version (What is a dimension?). Instead, build a little prototype and show them how the world could be. Make it easy for people. The person at the new kitchen store did just that. After asking the high-level questions, he used a few models to explain to me what type of decisions I would have to make. He basically educated me. And that did wonders. All the feature and function questions from the other store suddenly made a lot more sense.
- Create and share: Don’t just stop there. Take the initial requirements, apply your knowledge and think ahead. Take the input from the general business problem discussion and create a prototype that includes useful things the user might not have articulated. You are the expert and you need to inject your expertise. Apple does that extremely well. Steve Jobs once said: “Let’s go invent tomorrow instead of wondering about what happened yesterday.” And this could be a highly rewarding exercise, because we get to apply our deep knowledge. Also, make sure to show the advanced prototype for early feedback. It is easier to visualize what could be when I actually see it. The guy at the second kitchen store did that. We configured a basic setup and he then applied his deep knowledge to surprise me with a really cool proposal.
THE NEXT PROJECT
Next time you head out to meet with users, try to remember some of these things. It can make a huge difference. I can tell you that my family is pretty happy with our kitchen. The combination of understanding how the world could be coupled with the deep knowledge and creativity from my coach (the sales guy), we ended up with a rather cool setup that continues to delight us. Why shouldn’t we be able to do this in business as well?
“When you fulfill dreams, success is inevitable.”,Carmine Gallo, The Innovation Secrets of Steve Jobs