Business Analysis: Who is the “real” client?
As business analysts in an agile environment, we tend to find that our requirements are guided and approved by the product owner. The product owner then is tasked with making the final decisions that will impact the client. However, who is the actual client?
I firmly believe that this answer should be guided by the nature of the project and the people who will be using the system. So are the solutions we are building meeting the needs of the actual client, who is meant to use the system, or are product owners driving for solutions that are focused on their own agendas? In this article, I'll raise the question, who is the 'real' client and include insights into my findings as a business analyst.
During analysis, it is essential that we identify our real clients to ensure that our solutions solve business problems and not introduce new ones. In cases where systems are employee facing and will be used by internal staff, are we treating these employees who are the actual end users as our clients? Are we so focused on how we appear to the external customers of the business that we do not consider the needs of our actual end user who in this instance is the employee?
When building a system that will be used by a servicing team, as much as they are servicing the customers of the business, are we then saying that the external customer is the client instead of the internal people that will be interacting with the system on a day to day basis?
Identifying the client
When we are building an interface that will be used by anyone - be it internally or externally - we should ensure that we consider design and quality so that when users interface with our systems, their experience is a positive one. When defining who our stakeholders are, we should look at placing internal staff in a client category if they will be using our system and not just as another stakeholder.
So what type of questions should we be asking to determine who is to be considered a client when defining requirements? These three questions will help:
- Will they be interacting with a system that we are building?
- Will they be using documents that we are creating?
- Are they affected by the design decisions within our projects?
We certainly can't expect people that are using our custom built products which are meant to service external clients to get excited about providing excellent services if we don’t consider them during the design process. It is therefore vital that we take a holistic approach when considering who our real client is.
Where support staff need processes automated to make it easier for them to work, let’s make this a priority in initial releases, and not move this requirement further down the backlog. If not we end up in a situation where things continuously change, and new projects come into play leaving those internal staff members frustrated with having to do manual tasks. If proper design considerations were put in place, to begin with, these tasks could easily have been automated.
The design aspect
The look and feel for internal facing systems matters because it influences how the users view these systems; therefore all aspects of design need to be considered internally and externally.
Consider a scenario where we have an administrator capturing forms manually when people call in to place an order for a product. In most cases, the focus is on the new system that the external customer will be using to capture orders online, and not on the interface that the administrator will use to support the customers.
While the external facing one will have all the bells and whistles, the one used by the administrator has only the basics. As much as the external customers are the ones who contribute towards revenue we want to ensure that the internal user experience is a great one as well. Remember charity begins at home.
If we want our internal employees to be excited about what they are doing and to provide the best service to clients, they also need to feel that each system they are interacting with makes them happy and caters for their needs.
Another step to consider is to conduct interviews with internal clients. These are important not only to find out how they work to build systems for external customers but also to understand what they would like to see included from their side. This interaction and feedback will not only make them feel involved but will also ensure that they take pride in the systems used by the organisation. It will inspire them to provide better services as well as encourage external users to interact with these systems as they would also feel a sense of ownership.
As we build iteratively and take small releases into the market, our focus should be on adding value holistically. One way to do this is to ensure that in each version there is enough work done to cater to our internal and external clients. To achieve this means we need to define the Minimum Viable Product (MVP) scope from project inception for the external facing systems and the internal ones and continue in all subsequent releases.
We can add enormous value by considering the systems we build for our internal clients. It can decrease their amount of manual work leaving them free to grow and explore more of their capabilities, and in turn, increase the value that they can add to our organisations. This concept goes back to lean principles which encourage us to continually create value by reducing waste and thus increasing the efficiency of our business processes.
Remember that delivering fast does not necessarily mean neglecting the quality aspects of any systems created. Lean also advocates for amplifying learning. Where admin tasks are automated, this allows employees to learn and gather new skills and to have a continuous feedback loop from our internal and external clients resulting in continuous improvement.
Finally, product owners and business analysts need to work together to ensure that the mantra 'treating customers fairly' not only relates to external customers but includes internal clients as well.