The Community Blog for Business Analysts

Eric Provost
Eric Provost

You are not the user : 4 tips to elicit better requirements

I recently had the chance to spend half a day with some customer service representatives (CSR) in one of my organization's call centers, in order to get a better grip on their work and to see how they interact with the multiple systems available to them to better serve our customers.

I didn't answer any customer call (God bless them!), but I sat next to my assigned CSR with my headset and listened to real customer calls while watching him navigating through our systems to answer the customer requests.

At first sight, you may think, "What a boring way to spend a day at work!" After all, as a Business Analyst and as a former System Analyst in this organization, what could I have learned from this experiment that I still didn't know?

Well, I actually learned one key thing: I had absolutely no idea how our systems were really used by our users in real life.

Fact: you are not the user

In most of my projects, I rarely talk to real users to elicit requirements. Sometimes, I work with a department expert or a division project manager who acts as a user representative to elicit requirements. When I'm lucky, I have access to one selected real user for a few workshops. In most cases, I try to figure out by myself the best solution to a problem based on my incomplete knowledge of the business and systems.

The core of the problem here is that it's hard to reach the real users. They have full-time jobs, have responsibilities and daily tasks to achieve, and simply cannot be freed for days to participate in requirements workshops.

The consequence is clear : without users, business processes and systems can't work efficiently. At best, some minor things will be missing. At worst, users will refuse to use the new solution because it makes their life miserable.

Fortunately, there are some things we can do as BAs to prevent this.

4 tips leading to the right requirements

1. Do not use proxy users

The best way to get information about business processes & procedures and understand their current problems is to talk with the real users. You don't want to introduce noise in the conversation by adding layers of people between you and them, like I described above.

By being able to work with multiple users from multiple departments, you will get richer information, especially when it comes to details, exceptions and variations in the same procedure / activity.

2. Ask them how they work

Asking questions is almost as natural as breathing for a business analyst. You need to ask many questions to your users until you can reach a perfect understanding of a requirement.

However, you can't simply walk in a workshop and ask questions as they come to your mind. A good workshop needs preparation, so that you don't waste your users' precious time. This will probably be the subject of a future blog post, but in the meantime, this excellent checklist will help you at being a better interviewer.

All this is usually easier when you face real users (and not their proxies) because of interactions that allow you to clarify this in real time.

3. Watch them work

When you ask people questions, they tend to depict an idealized view of a specific situation (or a dramatic view of a bad one). You can reduce this effect by relying on more than one user, but the best way to prevent this is by actually watching them work.

By watching users perform their day-to-day work in a real context, you will be able to validate a lot of information you got by first asking them. Moreover, you will be able to distinguish the "should-be" way to work (which is often the information users will give you first) from the real way to work. In a context where your users have many systems and tools to deal with, it will also provide you unvaluable and more realistic information about how those systems and tools are used.

Be aware that watching users work can introduce some bias in their activites (phenomenon known as the Hawthorne Effect).

4. Involve them in the new solution definition

Working with users to understand the current business processes will bring you a lot of information. However, one thing that is often forgotten is to keep them involved later in the requirements elicitation process, when you try to define a new solution.

Indeed, most users have a lot to say about what's working well (and probably more about what's not!), and have a lot of ideas about what could be improved to help them in their work.

You don't want to rely only on them to define your new solution, but their input will be useful in the long run, by making the solution more acceptable; it will not only be your solution, it will be their solution. You will have a lot less change management to do this way.

I often tell my students that 80% of my job as a Business Analyst is communication. So get out of your office and go toward your users; your life as a BA will be much easier.

* * * * * 

Eric Provost, Senior Business Analyst and Lecturer

This post was initially posted on Eric the Business

This entry was published on Jan 16, 2015 / Eric Provost. Posted in Elicitation (BABOK KA). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  6 members liked this article


Mindy Knuffman posted on Thursday, February 5, 2015 2:34 PM
Thanks for sharing! I have recently requested to sit with the end users in order to understand their process better!
Mindy Knuffman
Andy B posted on Thursday, March 5, 2015 12:30 PM
I have always felt the best way to understand the product, whether a developer, analyst or manager is to what how and ask users how they use the system, likes / dislikes , and keep them involved in the process, not just a one-off interview.
Andy B
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC