Business Analysts are often known as the people that elicit and manage requirements for business or software solutions. That’s certainly true. Requirements are our focus. Yet, if we looked a bit deeper, what aspects of those requirements do we focus on?
Functional impacts, dependencies, assumptions, architectural impacts, acceptance criteria, data structures, business impacts…. there are so many aspects to analyse for each requirement. Yet what is the most important thing to understand, before we start analysing the detail and working out how to fit the requirement into the design?
I would argue the most important aspect is Priority.
The Priority of a requirement can be described or allocated in various ways. Often product owners or business reps will be asked to give them a High/Medium/Low, or Must/Should/Could/Wont (see MoSCoW). But how about looking at it another way – prioritising based on the value the requirement brings to your client’s organisation or customers?
Value can be defined in different ways. It depends on what is important to your client. What are their goals or strategies? What do they want to increase or decrease? Do they want to increase customer satisfaction, product sales, market share or credibility? Or decrease waste, environmental impact or revenue losses? There are all sorts of drivers out there. The first thing a business analyst should do when starting on a project is to fully understand those drivers.
There are a few ways to go about understanding project drivers:
- Talk to customers that use your client’s products or service offerings. This will give you an understanding of how the organisation is viewed externally and what levels of confidence exist amongst consumers. This can be as simple as finding a friend, colleague or family member that has some experience with your client’s products.
- Talk to people who have worked with or for your client, that aren’t directly working on the project. This will give you an understanding of how people who consider themselves “insiders” view the project, which may give you an idea of how the organisation views the project and the level of support you can expect.
- Talk to the project sponsor. They will be able to tell you the “official” drivers for the project, which will control the way resources and funding are applied throughout the project. Consider running a workshop with your project sponsor to determine what is most important in the project through the use of sliders – remembering that no 2 sliders should be the same!
- Find out whose idea the project was, or where it stemmed from. This will give you context which can be useful when the drivers themselves may not be clear.
- Look for past evidence of failed attempts at your project by searching your client’s Sharepoint, JIRA or Confluence systems, or other document repository.
- Other ways? Comment below!
By looking at your project drivers and understanding various people’s view on the project, the true value can be understood. This can help you to provide useful feedback to your project stakeholders and allow you to work with them collaboratively to prioritise your requirements.