Business Analysis Process | Business Analysis

Being assigned to a new project can be nerve-wracking. You might be wondering what exactly is expected of you, what deliverables you should be creating, and how to guarantee success on your project.

This document is intended to help you learn about the business analysis process that should be applied regardless of the project type (e.g., process improvement only, purchasing an off-the-shelf software or building a custom solution) or development methodology (e.g., agile, waterfall, etc.).

First, take a look at the process flow below which shows how the steps fit together and how you might iterate through them on a typical business project.

Depending on the size and complexity of your project, you can go through these steps quickly or slowly, but to get to a successful outcome you must go through them.

Now let’s look at each of the steps in more detail.

1. Get Oriented

Often as business analysts we are expected to dive into a project and start contributing as quickly as possible. It’s very common for business analysts to feel pressured to jump right in to defining the requirements.
Many times, the project is already underway. But that doesn’t mean that it makes sense to get knee-deep into specifying the requirements right away. Doing so very likely means a quick start in the wrong direction.
Take some time, whether that’s a few hours or a few days, to familiarize yourself with the project and its history to ensure that you are not only moving quickly, but also able to be effective and confident in your next steps.
Understanding the project and its history will ensure that you don’t inadvertently repeat work that’s already been done or rehash previously made decisions.
Things To Do:
1. Meet with the assigned project manager to discuss the project.
2. Review any existing documentation (e.g., the business case, meeting minutes, request for proposal documentation, existing process documents, etc.)
3. Schedule a “kick-off” meeting (or get on the agenda for an existing meeting) with the project team and primary stakeholders to introduce yourself and describe your role and business analysis plan for the project.
  - During this meeting, you should:
    1. Confirm the business objectives and project scope
      - Business objectives and scope should be clearly defined, documented, and reviewed at the beginning of requirement elicitation activities to avoid scope creep
      - Getting agreement on the business needs and scope early in a project before the requirements are defined is the quickest path forward to a successful project
      - If the business objectives have not been well defined and/or documented, you should do so at this time. (See Defining Business Objectives & Project Scope for more information)
    2. Confirm the list of stakeholders
      - Stakeholders are those with an interest or concern regarding the project’s outcome (See Stakeholder Identification for more information)

2. Elicit Requirements

After you determine the business need and applicable stakeholders, the next step is determining the requirements. This stage is called requirements discovery.
A good discovery process is critical for any project. The requirements that are generated at this stage form the backbone of the entire system, setting it up for success or failure.
Your key objective in this step is to understand and achieve agreement amongst the stakeholders about what the business community wants to accomplish with the system.
Schedule meetings with the applicable stakeholders to discuss what activities the business community needs to perform or wants to accomplish with the new process.
- Existing Process
  1. As a starting point, it often helps to discuss and outline the existing (“as-is”) process and any pain-points experienced or needed changes.
    - Before you can improve a system or build a new one, you must have a strong understanding of what is already in place.
  2. This will help you develop a reasonably clear picture of the current state that needs to change or be replicated.
- Desired Process
  1. Document the desired (“to-be”) process.
  2. Meet with the stakeholders again to review the desired (“to-be”) process document to ensure that you have understood and properly identified the needed process steps,
  3. Consider documenting the process(es) in a visual format, like a process map, to show the steps and actors involved and using wireframes to help users envision the system. (See Process Mapping and Wireframing for more information)

3. Document Requirements

Solution (or “System”) requirements provide a vendor or development team with the information they need to implement the solution. They make the project objectives and scope implementable.
Without clear, concise, and actionable detailed system requirements, implementation teams often flounder and fail to connect the dots in such a way that delivers on the business objectives for the project.
- It can also lead to selection of a vendor or product that does not adequately provide the desired solution
System requirements specify what the system, product or process must do to fulfill the user’s needs. These requirements are detailed and specific, written from the process perspective.
- They outline the system’s functionalities/features, behaviors, properties, and qualities.
  - In other words, system requirements define “what” the system will do, not “how” the system will implement the requirements
Create a requirements document that contains the detailed functional and non-functional requirements for the system based on the information you’ve discovered and the defined process documentation. (See Requirements Specification for more information, tools and templates)
Meet with the appropriate business and technology stakeholders to review and validate the specified requirements, asking questions to fill in any gaps and making any necessary changes.

4. Assist With Solution or Vendor Selection

It can be difficult to find the right software for your business usage and functions, despite the availability of online information.
Your concern should revolve around whether the software will be the right fit for the business, data security, integration, user adoption, and licensing, to name a few.
Participating in solution/vendor evaluation and demonstrations will allow you to ask questions and assist in assessing a vendor or product’s ability to fulfill the specified requirements. (See Solution or Vendor Evaluation for specific guidance regarding solution and/or vendor assessments.)

5, Assist With Solution Implementation

On a typical project employing a business analyst, a significant part of the solution involves customizing, and/or deploying software. During the technical implementation, there are many worthwhile support tasks for you to engage in that will help drive the success of the project and ensure the business objectives are met.
1. Technical Implementation
  - Your key responsibilities in this phase include:
    1. Participating in solution design discussions to ensure it fulfills all of the system requirements.
    2. Clarifying requirements documentation to ensure that the technology design is accurate.
    3. Managing requirements changes to ensure that everyone is working from up-to-date documentation and that appropriate stakeholders are involved in all decisions about change.
2. Solution Validation
  - It is essential that the solution delivered be evaluated to ensure that it meets the documented requirements
  - If dedicated tester(s) have been assigned, this includes:
    - Engaging with the tester(s) to ensure they understand the system requirements
    - Reviewing the documented test cases to ensure they adequately exercise the system and provide the functional and non-functional system requirements specified.
  - If dedicated tester(s) have NOT been assigned, the responsibility for testing lies with the business analyst. (See Solution Validation for specific guidance regarding testing activities.)
3. Change Management
  - Your technology team can deliver a beautiful shiny new solution that meets the business objectives, but if your business users don’t use it as intended and go back to business-as-usual, your project won’t have delivered on the original objectives.
  - This step is all about ensuring that members of the business community are prepared to embrace the changes that have been specified as part of the project.
  - Your key responsibilities in this step may include:
    1. Collaborating with training staff so they can create appropriate training materials and deliver the necessary training to ensure that end users understand all process and procedural changes and are prepared to use the solution.
      - If a dedicated Change Management resource is not available, this is the responsibility of the business analyst.
    2. Collaborating with business users to update other organizational assets impacted by the business process and technology changes.
All of these efforts help the implementation team fulfill the intended benefits of the project and ensure the investment made realizes a positive return.