I was recently asked by one of our customers to facilitate a requirements elicitation session on a change to an existing system. The software functionality is fairly simple so the group scheduled an hour session and just wanted an experienced facilitator to help lead the discussion. The session was already scheduled when I was asked to participate so I didn’t have much time to prepare but I did talk with a few of the stakeholders to get some background before the session. One of the business people wrote up a current state description which was very helpful in outlining the discussion. As I did some last minute preparations the night before and discussed the session with a colleague we realized that the customer had not really articulated why they had initiated this project. I had a pretty good idea (an assumption) but an analyst always validates assumptions before getting started.
Before the meeting started I posted a couple of questions on a flip chart: “Why are we going to change the existing system?” And “What is the core need?” As with many projects, this business had started with the solution – before carefully considering why. The product is a web-based product selector tool but it has not been updated for some of the new product types the company is now offering. The team assumed the tool should be updated for all new product types, but by asking the WHY question, the team thought about the value of the tool and whether or not it really made sense to use it for new product types.
I find starting with the solution a very common habit in many organizations. Rather than identifying and clarifying the business need, people tend to start with the solution or the technical issues and problems. A good business analyst asks questions to help the group work backwards towards the business need. This group started by articulating the problems with the current system and with the history of why this system had originally been created. This was a great discussion to set the stage for business analysis.
As the group began to describe the core business need, providing product options to customers, we quickly realized that there were many different ways to address this need. Changing the existing tool was just one of them. I asked the group to brainstorm a couple other solution alternatives. They came up with other ideas like direct phone sales rather than e-commerce. They also talked about building a brand new e-commerce site with more features. In addition we realized there was a second business need, a customer education opportunity which could be addressed by another project already in progress.
After brainstorming other ideas and discussing each, we came back to the original solution of updating the existing tool but the way we decided to approach the update was different. Once the entire team agreed about the business need to be met, the requirements were much easier to articulate and consensus was reached almost immediately. It was great to use a business analysis fundamental – asking the why question – and see immediate benefits. It was also great to work with a team who was open to stepping back from the first idea, and really considering the best approach to a change.
- Satisfying Stakeholders with Agile Requirements - January 25, 2023
- Business Analysis: The Best Way to Start a Project - March 2, 2022
- Three Proven Ways Analysis Prevents Scope Creep - December 29, 2021
