The project and the business analyst

A typical project's life cycle has the following stages: Discovery, Planning, Design, Build, Implement & Warranty. As a Business Analyst, depending on the stage of the development life cycle a project is in, you will have to support different types of activities.

Let's make some basic assumptions for the sake of this discussion:

  • The Business Analyst works on the project from inception to completion.
  • Ignore the different testing stages to keep everything simple.

Activities by phase

The chart below shows different activities that a Business Analyst may perform as part of a project. In general, there is more involvement in the first few stages of a project.

Let's investigate what each of these activities (in green) means.

  1. Understand big picture: Understand the overall objectives and how the initiative correlates with business goals and strategies.
  2. Work on the business case: Assist the project's sponsors to justify the need for the project. This may include high-level estimates of benefits.
  3. Determine performance metrics: Projects are intended to accomplish something. This step is intended to provide you with something that you can use to perform a before-and-after examination. For example, did performance improve by the stated amount?
  4. Gather high-level components: Understand the big moving pieces that compose the different pieces of the project. These pieces and sub-pieces will be given priorities in the next activity.
  5. Prioritize components: Now that you understand the major components, estimate how much benefit is associated to each. Also, factor in natural dependencies between components to end up with a prioritization scheme that depicts the order in which items will be examined.
  6. Gather low-level requirements: For the major components with the highest priority, delve deeper to identify the low-level requirements (e.g., functional requirements, specifications, process flows etc...)
  7. Train end-users: Prior to deployment, train the end-users on the new solution.
  8. Troubleshoot issues: After the project has gone live, be available to troubleshoot and provide support.
  9. Hand-off to support: Prep the production support teams so they can eventually take over support for the new application.
  10. Measure against metrics: After a sufficient amount of time has transpired, with the solution in production (e.g., end-users have ramped up appropriately), measure against the performance targets or metrics from activity 3.

Observations

  • In the beginning stages, a Business Analyst is trying to grasp the basic concepts of the project. Understand the what's and the why's and then delve down into the high priority items.
  • During the middle stages, a Business Analyst provides guidance and clarity to the design and development teams, ensuring that the team understands what the client needs and wants. Note that this does not imply providing design solutions to the design team!
  • In the final stages, the Business Analysts is performing a knowledge transfer to end-users and support staff. This is a precursor to the Business Analyst ending the engagement with the project.

Implications from Agile methodologies

The table below takes steps 4, 5 and 6 (Gather high-level components, Prioritize components & Gather low-level requirements) respectively and provides an example of what occurs in the real world. Before we get into the nitty-gritty, let's make the following assumptions to simply this discussion:

  • Each component can be broken down into groups of functionality called Requirement Sets.
  • Requirement sets are prioritized using their benefit as well as any natural dependencies they have.

Observations

  • A requirement set can be in a different stage than another requirement set. It all depends on its priority.
  • A Business Analyst will need to do different things based on the requirements set being worked on as it may be in a different phase than another set.

Summary

When using an Agile methodology, understand that groups of requirements will need different supporting activities because they will be in different stages of the system development life cycle.

8 comments:

Marcus Ting-A-Kee said...

I've made the slides used on this presentation available for download using this link.

All feedback is welcome and appreciated.

Anonymous said...

Thanks a lot

Anonymous said...

The link is broken!

Marcus Ting-A-Kee said...

Here's a new link.

Joe Ballou said...

Hey, great site! Studying up on "stuff I already know" for an interview. Great reminders and refreshing of skills I haven't used in years. Thanks for providing this resource!

Are you an IIBA member? I would recommend it!

Marcus Ting-A-Kee said...

Hello Joe,

Thanks for your comments. I'm not an IIBA member. I haven't really looked into it much.

Business Analyst said...

Business analyst life cycle is well explained. business analyst

Unknown said...

Thanks a lot. The link is broken. Kindly provide it again. Thanks