In a new business analyst position, it can be a challenge to figure out how to learn everything you need to know to be successful. Knowledge about the business and industry can be acquired over the life cycle of a project, but oftentimes you need to know the basics to succeed on your first project in a new organization.
In this post, we identify the type of knowledge you need, 11 questions you should be asking, and how to document and synthesize the information you pull together.
Acquiring Business and Systems Knowledge
When working with a new client, I often build my knowledge of the business processes and systems in parallel, but I give priority to understanding the business. Without understanding how the business process works, it can be nearly impossible to understand where it’s going, help plan how to get there, and determine how to build or customize systems to support that direction.
Some aspects of the business can be ascertained by the company’s website, and I spend a fair amount of time understanding the business with publicly available information and explore the product or system as well. But most understanding comes from talking to people within the business, whether during the course of elicitation sessions or in an initial “getting acquainted” meeting.
But when you are working on a new business, how do you know what questions to ask in the first place? Let’s look at some high-level conversation-starting questions that are useful in obtaining a big-picture view of the business.
Understanding the Business Domain
Here are some thoughts about the questions to ask and answer to get a high-level understanding of how a business works.
- Who is the customer?
- What is the product?
- How is the product sold? (online, phone, in-person sales)
- What is the cost structure of the product? (subscription, pay-per-unit, etc)
- Where does the money go?
- How do we fulfill or distribute the product?
- How do we produce or service the product?
- How do we support the customer?
- How do we market the product?
- What partners do we work with to do business? How do we manage these relationships?
- What information does the organization manage? Who is responsible for creating, updating, and retiring information? What systems are used to manage the information.
These questions are fairly high-level and they will lead you to obtaining a big-picture overview of the business model. As you work on specific projects, you’ll want to dial in more specifically and get more detailed in your questions. This is when creating a project-specific requirements questionnaire is useful.
(By the way, we’ve pulled together a collection of feature-specific questions and made them available in our Requirements Discovery Checklist Pack. You can also download a sample checklist absolutely free of charge.)
Documenting the Business Domain
As you create the big-picture view, there are a few requirements documents that can be particularly useful to create. Let’s look at how the glossary, business processes, and use cases work together to give you an overview of the business.
- Glossary – This document captures the key terminology that’s used in the organization and can help you keep variations and acronyms straight.
- Business Processes – Business Process Models capture the step-by-step sequence of activities completed to achieve specific business goals. At a high-level, a list of business processes and some simple workflow diagrams is often enough documentation. Business processes identify what the people in your organization actually do to achieve the organization’s high-level objectives.
- Use Cases – Use cases capture the functional requirements fulfilled by a system in context. They identify what software capabilities are in place to support your business processes and look at technology systems from the view of the end user. At a high-level, a use case list with brief descriptions might be a good starting point. As you dial into the details, fully fleshed-out use cases can be a good idea.
With a clear understanding of terminology, a view of the current business processes, and the identification of the functional or feature areas covered by the organization’s systems, you’ll be prepared to talk the talk of the business and relate any new project work back to the big picture view.
I also find that a short narrative or visual model identifying the customers, products, and supporting processes puts everything in context and is great to refer back to.
Sometimes it can feel like you’ll never stop learning more about a new business domain. That’s a common feeling and it’s not necessary to learn everything there is to know upfront. As you are assigned to projects, you can always drill into more detail and you’ll definitely want to discover the specific business needs driving the initiative and key objectives to be delivered by the project.
>>Download a FREE Requirements Checklist
As business analysts, identifying the questions to ask during requirements elicitation is incredibly important. To help you ask better questions, we offer an absolutely free requirements checklist – this is just one example from our Requirements Discovery Checklist Pack – and you’ll learn what a requirements checklist looks like in the example of Supporting Customers.