The Value of Business Analysis: Storytelling

One of the main duties of the IT Business Analyst, or Business Systems Analyst, is to document requirements for software development projects.  Many organizations believe this is the only role of the IT Business Analyst and utilize them only in this very narrow scope of duties.  Organizations that recognize the true strategic value that Business Analysts can bring to the organization will gain a competitive advantage in the marketplace. 

However, even if the organization defines the role of the Business Systems Analyst very narrowly to requirements documentation, those Systems Analysts can put the word “business” back into their role and show the organization the value they can bring to the table.  They can show management and the organization their value by going beyond documentation of requirements to telling the story of the project and its business solution.  Document the requirements of the project as management and the organization expects you to, but then package those requirements into a story that will tell anyone, even those unfamiliar, all about the project. So how do you start?

Business Case

The business case for the project defines the business problem that the sponsor wishes to have resolved.  It should define the benefits of the project and costs – thereby a cost-benefit-analysis, strategic alignment with organizational goals, business requirements, rough duration estimates, and if known at this time, alternative solutions.  The document is the one that the organizational project approval board reviews to approve and prioritize projects. These approved and prioritized projects make up the project portfolio that needs to be managed to deliver the maximum value and competitive advantage to the organization.  This is another value of business analysis, but that is a story for another day.

Define the True Business Need

Often, symptoms of the true business need or problem are included in the business case.  They are often statements of business stakeholders, what they experience in their work, or their pain points.  This is where the Business Analyst will ask “Why” to drive to the true business need.   Once you get to that true business need, you should also define the contributing conditions that are causing this business need.

Scope

It is true that the Project Manager defines and manages project scope, but the Business Analyst defines and manages solution scope.  Solution scope may be defined more narrowly, or more widely than project scope.  There may be multiple components to the solution to a project; each component will have the scope of that solution.  Solution scope may become wider than the project because the solution interacts with downstream systems.  When you tell the story of a project, you must mention the scope of the project and the solution.  These may be links to scope documentation, but should include more definition that is learned during the project.

Related Article: The Power of Story in Business Analysis

Requirements and Business Rules

Business rules are defined prior to project initiation.  Define stakeholder, solution, transition requirements and business rules during the discovery phase of the project.  These may be defined in multiple documents like a Business Requirements Document, Functional Requirements Document, System Design Specifications, or documents of other names.  Include any assumptions, constraints and dependencies related to those requirements.  Defining these requirements and business rules is the main duties of the Business Systems Analyst and should be included as the meat of the requirements package.

Business Glossary (Glossary of Terms)

An often missed part of a requirements package is a glossary of terms important to the project.  These are often business terms for the business unit(s) for which the project is to deliver a solution.  For product or software project, a technical team is assisting to deliver the solution to the business unit(s), and may not be familiar with the business terms of that business unit(s).  As noted in the introduction of this article, the requirements package should tell the story of the project to those unfamiliar with the project; therefore a business glossary is necessary to ensure your audience understands the package.

Pictures

A picture is worth a thousand words.  They also help the audience consume and understand content much quicker than text.  This should start in the scope section with some type of scope diagram, such as a project functional decomposition or context diagram.  There are several business analysis techniques that deliver a picture or diagram to its audience; these include business model canvas, data flow diagrams, data modeling, decision modeling, mind mapping, organizational modeling, state diagrams, process flows, and prototyping to name a few. Any picture, model or diagram developed during the project should be included in the requirements package.

Use Cases

Use cases are an effective business analysis technique to understand the interaction between an actor, or actors, and a system.  Use cases can be used to highlight a specific process within the scope of the solution to help the audience understand the specifics and reasons for the process.

Lessons Learned

The project team learns a lot during the discovery phase of the project.  Some organizations may call this the analysis and design phase(s) of the project.  These lessons are usually learned after the creation of the business case and scope documents; and therefore, should be included in the requirements package.

Why?

Hopefully by now you are asking yourself “why would I create this one all-inclusive document in addition to all the other documentation created during a project?”  It may even sound to you like duplication of effort or documentation, and I hope you don’t dismiss it as such.  The value of creating this one package was outlined in the introduction to this article – to tell the story of the project.  It should tell someone unfamiliar with the project, or business unit(s) involved, all about the project, its purpose, scope, business problem, requirements, and solution. 

As a person unfamiliar with the project, how would you find out these things about the project?  How would you know what documents to read? In what order would you read these documents?  The requirements package wraps all this documentation into one neat package for easily readability and shows in the order that documentation of the project should be read in order to know what happened during the project.  This is how you tell the story of the project and increase your value as a business analyst to the organization.