The Ultimate guide to all Business Analysis documents and deliverables.

Document Map

1 Business Case

  • Is this project worth undertaking? - Before any company spends money on an initiative, they have to perform some due diligence to figure out whether the pay-off is worth the investment. This is where the business case comes in handy. Sometimes this business case is informal, other times, it is a mandatory part of the budgeting process - all depending on the company you work for.

  • Summarize other documents + Attach a Cost - Before you can determine the payback on the investment, you have to figure out what the business problem is in the current situation (As-Is Document), and what the best solution is to fix this problem (To-Be + Vision). For the business case, you have to summarize what the As-Is, the To-Be and provide the financials around ROI.

  • What other options did you explore ? You might be asked for up to three options you've explored before you came to the conclusion that about the best solution. Be ready to explain why the solution you're recommending is better than other solutions that could be explored. Are you proposing a new build solution? Did you look at packed software alternatives? Is there a manual solution that would save the company more money over the long run? Make sure that questions like these are already answered as part of your business case document.

2 BA Work Plan

  • How will you execute requirements? - If you're a Sr. BA, you'll likely be expected to produce a plan that tells the project manager (PM) how many work packages are required to complete the requirements, and what sequence these work packages should be done. This document is the BA's portion of the overall project work breakdown structure (WBS). The PM will take this and plug it directly into their project plan for tracking purposes. The PM will also ask the same thing from the architect / Sr. Developer on the project - that's how most PMs come up with their plans. You have to have a good enough understanding of the solution and work a lot with the architect or lead developer on your project to come up with this breakdown plan. Most PM's will assume that you've already done all the due diligence and understand the solution at the level of detail needed to produce this document.

  • Be ready to report progress using this plan - During project execution, you're going to have to report the progress of your work to the PM (usually weekly, sometimes bi-weekly). This is the plan that you use to report your progress (e.g. "I'm 60% complete on item #5 of my plan").


3 Requirements Strategy (for consultants)

  • What is your requirements methodology ? - What is your requirements methodology? - There are many requirements tools and techniques out there. Which ones do you use to get the job done? If you're an in-house BA working for a good company, you won't ever be asked to produce this document - your company already has policies and procedures in place that answer these basic questions. If you're a consultant BA working for a software development shop (or independent), this will be a common ask from your clients - especially if this is your first time working with them.

  • Clients want assurances - Most clients want to make sure that your style of analysis will work with the processes that they’ve instituted in their company. It's going to be difficult for you to run an Agile style JAD-based requirements program with a company that does only waterfall implementations on their projects. The requirements strategy helps you're team and your client bring their processes in line.

4 Stakeholder Analysis

  • Who needs to be involved in the project ? Whether on small or large project, you should have a clear idea of who fills the key roles. If you’re not asked to produce this as a formal deliverable, go ahead and produce it for yourself. You want to make sure that there is agreement between your chain of command and the rest of the project about who is to be involved in the project.

  • Make sure you cover the following groups / roles Depending on the size of your company, you as the BA may be filling more than one role here (e.g. smaller companies won’t have a separate QA or training lead, and will expect the BA to fill that role)
    • Project steering committee
      • Project Sponsors (business)
      • Project Sponsors (IT)
      • Project Sponsor (Finance)
    • Core project team
      • Company project manager
      • Vendor project manager (if working with external vendor)
      • Business Analyst
      • Technical Lead / Development lead
      • QA lead
      • Training Lead
      • Business SME

5 Change Requests / Change Control

  • Change is inevitable - A lot of time can pass between the first requirement being documented and the that the first line of code being written – especially on larger projects. A lot can change between this time, Changes to requirements are inevitable in most projects. Instead of avoiding change, the BA has to know how to handle it. The key here is to make sure that the project can formally absorb the changes into the cost and schedule budgets at the same time as adding it to the scope.

  • Prevent scope creep - One of the most common issues that projects face has to do with ever expanding project scope. As the requirements / development process proceeds, people start coming up with more good ideas to add into the solution. If change control isn’t practiced, the scope of the project gets bloated but the cost and schedule of the project stays the same; this is a recipe for total disaster. Exercising good change control allows each change to be sized and incorporated into the project scope with additional money and time allocated to the project.

6 Stop Gap Strategy

  • Large programs need a clear implementations strategy Business cannot stop while the project executes. Large programs that try to make drastic changes are usually phased in incrementally over time rather than a single “big bang” implementation. This usually means that that the initiative gets split into a collection of projects that fit under a single program. As these projects are being implemented, the business needs temporary solutions to be put into place so they can still operate until the time that the

7 As-Is Document

  • What does the current situation look like? It’s hard to suggest real tangible solutions for the future unless we understand where things currently stand. The as-is document captures the results of the “discovery” process that I go through when starting on a new project – especially when it’s a project in a domain that is new.

8 To-Be Document

  • Who needs to be involved in the project ? Large project teams might have many people from very distant branches of the organization getting involved.

9 Detailed Requirements / Specification Document(s)

  • How does the solution meet the business need ? Understanding what the business needs is a good first step, that's where we document the high level requirements that go into the To-Be and vision Documents. When the project kicks off the detailed requirements phase, it becomes our job to work with subject matter experts, along with the architects and developers, to design a solution that satisfies the business need that we've already outlined in our high level requirements

  • What goes into detailed requirements ? There is no clear standard for how requirements should be expressed. Over the last decade, I've found the following to be the most useful set of tools that I use to document the requirements for my projects.

    1. Mock-ups - Lets the clients envision what some parts of the system might look like. Its best to use wire-frames instead of realistic UI components. When the mockups are too realistic looking, clients will attach an expectation that the final product will look like the mock-ups. We don't want that.
    2. Use Cases - Describes the users' interaction with the system.
    3. Business Rules - Describes the rules that have to be observed by the system as the use cases and business logic executes in the system. Ron Ross has written an excellent book on this subject.
    4. Pseudo Code - Best used to describe processing logic that the system is expected to execute as part of its functionality.
    5. Entity Model - The static logical data model will describe the major business concepts and how they are related to each other.
    6. State Transition Models - The major entities in the system will have a life-cycle with many stages that it goes through. This document describes the stages and how the entity goes from one stage to another.

10 Integration Points

  • How does the solution meet the need ? Understanding what the business needs is a good first step, that's where we document the high level requirements that go into the To-Be and vision Documents. When the project kicks off the detailed requirements phase, it becomes our job to work with subject matter experts along with the architects and developers to design a solution that satisfies the business need that we've already outlined in our high level requirements

| All site content is © |