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 Analyst.com