The Deliverables

I wish there was a “one size fits all” some days as a Business Analysis professional!  Yet, as I have worked through my career, I have realized how much chaos that would actually create on my projects!

The reality is, that this is a complex practice, and it’s NOT a discipline that follows the exact same document and procedure repeatedly. The type of project and context matter, and doing the same thing on each team or project usually does not serve our teams and projects well. It is detrimental to results.

We must “practice” our discipline and be open to changing our approach, documents, and techniques as we work, while honoring our purpose as analysis professionals.  Just as a Doctor is honoring “keeping us healthy and out of severe illness”, and they do this using a lot of different knowledge, techniques, and artifacts, even experimenting, we also need to treat each project, product, and feature as a unique piece, honor our purpose and use our skills to navigate a complex path to making their world better.

Deliverables, assets, artifacts, documents, and more….can change for BAs depending on many factors such as the type of project, the various roles involved, the team’s and organization’s risk tolerance, and the approach they are using (predictive or adaptive).

Some see “deliverables” as the actual software that is implemented, not all the work that goes into it. Others see “deliverables” as the documents that BAs create to be handed off to other teams, and others see them as “assets” for the team to use to collaborate.   Much of this depends on the project and approach the organization and team are following.

In this course we will cover some common deliverables BAs create:

  • Product Vision
  • Scope
  • User Stories, Backlogs, & Agile Artifacts
  • Requirements Document (BRD)
  • Business Analysis & Requirements Plan (traditional and Agile)
  • Traceability Matrix
  • Test Plan
  • User Impact Analysis – Change Management Plan
  • Visual Models

It’s important for the BA to help the team evaluate and decide which deliverables are needed and why. Helping determine who will use them and how long they will be valid for, then if they are worth creating based on the risk, cost, and deadline trade-offs.  Sometimes this is a formal discussion and plan, and sometimes an informal process BAs navigate.

Assets BAs create are about the models and things BAs create to help their own analysis, as well as help aid in the conversations they have with the stakeholders, users, and team. These can be very informal whiteboard drawings or formal visual models and can be high-level or very detailed. The decision for which models and assets are needed is highly dependent on the organization, team, skill set, complexity, and tolerance of risk compared to the cost/effort and time to create them.

Many assets BAs use are solely at the discretion of the BA to create and use them. BAs do not need permission from others to create them, as many other roles will not understand the reason, value, and effort needed to create these assets. As a BA grows in skills and maturity, the decisions on which to use, create, share, and at what level of formality get easier.

Next, let’s learn about these deliverables and what goes into creating them! We have lessons for you with templates, how-to, and critical guidance on the steps to get the right inputs into these deliverables.