Follow us...

The Simplest Way to Understand All of Your Business Analysis Deliverables

By Angelo Kalevela, MetaBusinessAnalyst.com
 
Many business analysts, especially new business analysts, have questions regarding what exactly it is 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 return 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. The planning is important because a business analyst can't do very much alone. An analyst needs 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 the business. 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 a high level everything that comes out of this might be included in the business analysis plan, this may be broken down further 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 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. In A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) the term used is 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 solution has 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 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
 
Acceptance and Evaluation criteria are typically lumped together, the main difference being that acceptance describes the first scenario where you are making sure what you build or purchase is really meeting your needs. Evaluation is usually used when you are reviewing your list to decide which option you’re 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 been 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.

©iStockPhoto/TommL