Planning Business Analysis Approach and Monitoring

Sharing is Caring
Share

Business analysis & Scrum agile

Do you want to learn Business analysis? or Scrum? Learn complete business analysis & Scrum. You will perform better stakeholder management, requirement elicitation, requirement prioritization. You will also get templates for BRD, user stories, product back log & burn down chart. 

Download android app for better experience. 

Business analysis is one of the most critical element of an IT software development project and often its success is oneBusiness Model Canvas - New Page of the major cause of the success or failure of the overall success or failure of the entire project. Therefore it is imperative to focus and plan business analysis activity of a project.

Every element of the business analysis activity should be carefully planned. If we categorize BA activities, then following activities are the most important business analysis activities which a BA need to perform;

  • Business Analysis Approach
  • Stake Holder Analysis
  • BA Activities Planning
  • Business Analysis Communication
  • Requirement Analysis Management
  • BA Performance

Above mentioned activities are the primary responsibilities of a Business Analyst.

Business Analysis Approach

Business Analysis Approach specifies the process or methodology of business analysis activities or software development approach, which needs to be followed for a particular project. Two most common example of business analysis approach would be, waterfall and agile software development methodologies.

At times, you can even combine element of various methodologies and business processes to come up with a custom business analysis approach for a particular project. Primary objective should be to drive maximum value for the project and sponsors.

Some of the most important factor influencing the choice of business analysis approach are;

  • Business Objective
  • Organization processes followed by the client or end user
  • Time to market limitations
  • Legal Compliance factors
  • Existing standard Approach and Willingness of the stake holders to work with traditional or new methodologies
  • Expert judgment and organization process assets
  • Amount of business analysis required for the project
  • Amount of details required to finalize the requirements
  • Method of communication with stakeholders (formal or informal)
  • Project complexity level
  • Prioritization of requirement
  • Phase of the project in which BA work will take place and whether it will continue throughout the project or mostly at the beginning of the project.

Business objective or the problem which a project is trying to solve, is the king maker when it comes to choosing the business analysis approach. It’s not so much about the new-old or good-bad but it’s more about appropriate. That’s what you need to target and business requirement or need should be primary driver for deeming a particular approach as most appropriate.

Expert judgment is an important method to gauge the feedback about a particular approach. You should consult stake holders, users, consultants and others to get their feedback about a short listed approach which you are contemplating.

Organization process assets are the existing process and tools which a team is already using, people are familiar with them and it tend to increase their confidence in them. So they may be inclined to continue with them but it also pose significant challenge to propose changes because we, as a human, resist change. Therefore carefully examine existing assets and capabilities of the development teams to finalize the approach. if stakeholders or programmers are extremely comfortable with waterfall, they are going to resist any change towards methodology change and will not favor agile or something new. Therefore plan change and account for existing assets.

And if you decide to change, reexamine existing asset and check if they could be reused like deliverable templates etc.

There are two types of business analysis approaches;

  1. Plan Driven Business Analysis Approach
  2. Change Driven Business Analysis Approach

Plan Driven Business Analysis Approach

Plan driven business analysis approach is used when requirements are clear from the beginning of the projects. As the term “Plan Driven” suggest, you basically plan activities in advance and in order to plan anything, you need to have clarity on it.

So for example, if the system requirements are known at the beginning the project, one can go ahead with waterfall methodology for software development.

Please note that in plan driven approach, final authority rests with project sponsor though stakeholders too, can approve requirements.

In plan driven BA approach, most of the business analysis activities like enterprise analysis, requirement analysis etc take place in the early phase or some specific phase of the project and once requirements are signed off, primary BA activities remains managing coordination, communication, development & QA/UAT support along with change request management.

Plan driven approach requires formal communication for requirements, deliverables and other BA activities. Requirements and functionality is explained in detail and standard templates are used for each activity. Documents are walked with the stake holders who first approve document before any development work can start on it.

Change Driven Business Analysis Approach

Agile software development methodology is the example of change driven business analysis approach.

Basically if the focus is the ability to quickly develop a particular module or functionality and use multiple iteration for the entire project because multiple changes are expected in the course of project then change driven approach is the choice for you.

Approval process follow a strict deadline and usually one person is responsible for approving the requirements.

At times, you will combine both approach to tailor the appropriate approach for your project.

You select appropriate approach based on the factors mentioned earlier in this post.

In change driven approach, business analysis could be higher at the beginning of the project when requirements are finalized at higher level but as requirements updated throughout the life cycle of the project, BA activities like requirement analysis, continues to happen across project phases.

The process of listing requirements at higher level in change driven BA approach is called, requirement envisioning.

This list of requirement is constantly updated as new requirements continue to come throughout the project phases. Business analyst will work with the stakeholders and sponsor to prioritize these requirements as per business need.

Business analyst will primarily maintain a pipeline of high level requirements where the most important (high priority) requirement will be picked for further analysis and implementation as soon as current phase is over and resources are available for it.

One of the primary reason for change driven approach was to reduce the additional documentation and keep it to minimum. So if you are looking to achieve minimum documentation in your project, change driven approach is for you.

In change driven approach, most of the communication is informal and documents are not as elaborate as they are in case of plan driven approach.

Usually requirement documents will have a list of requirements but they are explained in very much details. At times, if required for a particular project, team may create some artifact explaining some particular functionality. Requirements are used as formal acceptance criteria and formal documentation happens after project is over.

Sharing is Caring
Share
About akhilendra

Hi, I’m Akhilendra and I write about Product management, Business Analysis, Data Science, IT & Web. Join me on Twitter, Facebook & Linkedin

Comments

  1. The business management is itself is really an amazing thing. Thanks for sharing this information with us. Subscribed your blog.

Speak Your Mind

*