Your cart is currently empty!
— by
A lot of business analysts, especially new business analysts, have questions regarding what exactly they are supposed to deliver. After some research and applying my personal experience, I’ve found a simpler way to “shed some light” on exactly what it is we’re supposed to be doing.
First, business analysis isn’t a single task. It actually encompasses a few value-adding activities. For the purposes of this article, I’ll break them up into the following sections or categories that make sense in terms of deliverables.
- Understanding The Business
- Planning Your Work
- Defining The Solution
- Evaluating The Solution
Let’s break these down so you can understand what they are and what deliverables would come out of each. One thing to remember is that different companies may name some of these items or concepts differently, so what’s important is understanding the value of the end result not what it is named.
Understanding the Business
This part of the job is where you figure out whether there is really anything to be solved. This is not always done by a person titled “business analyst,” because at this point you are figuring out returns on investment, getting business justifications, etc which more senior business analysts tend to be more prepared for. Depending on the company, this senior business analyst may have many different titles. My company, for example, calls it an IT Partner, usually partnering with a particular business segment like marketing, sales, etc.
The High-Level Deliverable: A Business Case
The business case is typically what comes out of this, and it may include outputs of various techniques that come together to show that a problem needs to be solved or there is an opportunity to take advantage of.
Planning Your Work
Once you or someone else has determined there is a project worth doing. It is time to plan how you are going to do the rest of the business analysis work. Planning is important because a business analyst can’t do very much alone. Analysts need to plan how they are going to interact with all the stakeholders and get what they need out of them to create a solution that works for them. It prepares everyone involved and also ensures they have the resources (people, tools, facilities, etc) they need. This becomes especially important if you are a contractor and statements of work will be required.
The High-Level Deliverable: The Business Analysis Plan
While at high-level everything that comes out of this might be included in a business analysis plan, they may be broken down into smaller common deliverables like work breakdown structure (WBS), communication plan, business analysis approach (plan vs change driven), and requirements management plans.
Defining the Solution
This step is typically what people believe the “business analysis” is, and what their deliverables should be centered around. Defining the solution is essentially documenting what the future solutions should be capable of doing to meet the business needs, also known as requirements gathering.
The High-Level Deliverable: A Requirements Document
This can come in many shapes and sizes. Requirements document makes it sound like it should be a paper document, but it doesn’t always have to be. The BABOK terms this the “requirements package” which I think better describes what it is. This could include a traceability matrix, use cases, business requirements, stakeholder requirements, solutions requirements and they can be textual or in the form of diagrams, models, or wireframes.
Evaluating the Solution
Sometimes your job may require you to evaluate whether a given solution actually meets business needs. This can happen in two ways. The first is when the requirements document has been done, the solutions have been designed/built, and you need to make sure it meets the actual business needs. The second is when the requirements are defined, and you want to assess a bunch of different potential solutions. Kind of like creating a list of things you want in a car and checking cars out to see which models meet your criteria (instead of building your own).
High-Level Deliverable: Acceptance/Evaluation Criteria & User Acceptance Test Cases
Acceptance and Evaluation criteria are typically lumped together, the main difference is acceptance describes the first scenario where you make sure what you build or purchased is really meeting your needs. Evaluation is usually used when you are using your list to decide on which option you are going to go with. This can come in the form of user acceptance test criteria, vendor selection criteria, etc.
***
I hope that helped and put some perspective into your BA world. Do any of you have examples of specific deliverable names you have ben asked to deliver?
Side note: Even in an agile world, a BA needs to accomplish these same things, but they are done within the scope of sprints/iterations and are typically named differently.
