Business Analysis Work Products and Deliverables

Business Analysts get involved in projects from the inception till the end and produce different artifacts.  In some cases, the Business Analyst’s involvement begins prior to the project inception in the pre-sales and feasibility stage and go beyond the project’s end into the operations and maintenance phase. 

The artifacts BAs create at different stages are different and not all of them get presented to clients or other important stakeholders of the project. It is important to understand the rationale and timing for creating such items as well as understand how they differ based on the project approach. The BABOK® defines two major categories of artifacts. They are work products and deliverables.

What is a work product?

The BABOK® defines a work product as: 

“A work product is a document or collection of notes or diagrams used by the business analyst during the requirements development process.”

The business analyst identifies the needs and wants of the stakeholders during the requirements elicitation process. Requirements are not normally readily available like fruits on trees. The business analyst needs to ‘bring forth or draw out’ requirements from stakeholders using various elicitation techniques. Though requirements available in documents or on existing legacy systems can be ‘gathered’ the real underlying needs of stakeholders can be identified by techniques such as interviews, observation, prototypes, focus groups and , workshops.

The Business Analyst must be competent enough to quickly document the data and information identified during such elicitation sessions. The BA may capture these pieces of information as meeting notes on a notepad, a scribbling on a piece of paper, notes on a whiteboard, an audio or video recording, photographs, status reports, presentations or even some diagrams drawn using some tool to quickly capture stakeholder needs. 

A work product may or may not end up becoming a deliverable. The BA may grow the work product and structure it in a manner presentable to the stakeholders and thus make it a deliverable. In addition to documenting elicited requirements, a work product may be used to share information with stakeholders, share status reports among many other reasons.

What is a Deliverable?
The BABOK® defines a deliverable as: 

A deliverable is any unique and verifiable work product or service that a party has agreed to deliver.

A deliverable is a particular output that a business analyst creates as part of the underlying competiting business analysis activities. The BA may decide to use the work products to create these deliverables.  Business Analysis Deliverables are normally identified during the business analysis planning stage and get included in the project management plan as well. 

The deliverables, the acceptance criteria, the level of detail, the level of formality, frequency etc. are normally agreed upon up front and sometimes get tied with project milestones. Business analysis deliverables in plan-driven projects are normally formal, and are created using organization specific documentation templates. Deliverables in change-driven projects will be less formal and may even be captured in requirement management tools such as JIRA and confluence. Some business analysis deliverables include the business analysis plan, requirements management plan, business requirements document, system requirements specification, product backlog, business analysis communication plan etc.

For example, an SRS document created as a deliverable may contain process diagrams, use cases or user stories, data dictionaries and prototypes which may even be work products on their own.

Why should the BA know the difference between the two?

It is very important for the business analyst to understand the difference between a work product and a deliverable. A work product may be work in progress, unstructured and very confusing if shared with a stakeholder. A work product must only be used as a means of collecting or presenting information and should not be considered as a final product for delivery until properly structured, detailed out and reviewed. 

So, make sure that you understand the difference between the two and use these two wisely to elicit, analyze and document requirements for your projects.

Unlock the power of data with the best certificate for data science. Gain a competitive edge and dive into the world of analytics, machine learning, and more. Start your journey today!