Categories
Blog

The Business Analysis Process: 2. Considering Perspectives

You’ve now completed step 1 and you’ve now got a good understanding of the situation and are ready to progress your business analysis activities. The second activity within the business analysis process is to consider the perspectives of your stakeholders.

Here’s what you need to do:

  1. Find out who your stakeholders are. You can typically do or should have done this this by gathering details on the situation, from the first activity within the process. With this information you can then decide how to manage your stakeholders by conducting stakeholder analysis. A good way to do this is by using the power-interest matrix; the power-interest matrix will give you a framework for management.
  2. Once you have considered who your stakeholders are, it would be important to conduct the CATWOE analysis to understand what the stakeholders thoughts, feelings and values are with relation to the system/process addition/update/closure. The CATWOE analysis gives the analyst good details on the system from the users perspective; it takes in to consideration, why the stakeholder thinks the system should be implemented, what the definition of the system is, who the customer is, who plays a part within the system implementation, the owner and the environmental factors that need to be considered in which the proposed system will sit. You will conduct the CATWOE analysis with your stakeholders that you have identified as value-adding.
  3. Each perspective that you gather from a stakeholder, would be documented in a business activity model that outlines the main activities within the system, from the individual stakeholder’s perspective.
  4. Once you have gathered the above details and produced the business activity models, the next step is to determine one unified business activity model that synthesises all business activity models gathered. Now, naturally it may not be possible to create a synthesised model that incorporates every single requirement of all stakeholders. BA’s must recognise that stakeholder play a part in systems development because they have good context and understanding of user requirements; naturally people will have different opinions, however it is up to the BA to understand which activities within the documented business activity models that add most value, while meeting each stakeholders requirements. Often negotiations will need to take place, as it may not always ben feasible to deliver all requirements as outlined by the stakeholders. The way negotiation facilitation is highly personal and for that reason I won’t discuss this much.
  5. Compile all information gathered and document all of the details including the business activity models for reference, if required.

This will then take you on the next stage of analysing the needs within that one business activity model that you have now created, amalgamating most, if not all of the activities outlined in all stakeholder business activity models.

The Business Analysis Process: 3. Analysing Needs

Categories
Blog

The Business Analysis Process: 1. Investigating a Situation

One of the Analyst’s key activities will be to understand the context/situation in which a project sits, in order to gain a better understanding of what implications and impact the project will have. The analyst is responsible for gathering all requirements of the project that are (a) relevant to the project and (b) meet the deliverables of the project, which could typically be defined by any or all of the stakeholders ranging from, shareholders, employees to customers. The requirements document will then form the basis of the project.

In order to create a  requirements catalogue for the project, a couple of activities within the process need to be conducted; the first of which is:

1. Investigating a Situation

This is the stage in which you gather high level information about the problem, issue or gap that needs addressing. This data is important because it will provide a good reference point on which to build upon. The situation will contextualise the problem and the potential solution’s practical application within the business.

This can typically done through gathering details on the following:

Context:

  • Speaking with stakeholders on the issues, gaps, problems they are facing, that the project will help  to achieve
  • Consider company strategy and strategic objectives
  • Consider the Project Initiation documentation (if there is one) to gather further details on who the stakeholders are, who will be using the system, risks, costs controls, business case 
  • Consider the terms of reference (if there is one) which will provide details on Objectives, Scope, Constraints, Authority and Resources (OSCAR)
  • Stakeholder analysis

Input:

  • Understand documentation that is related to the project
  • Review process maps
  • Review non-documented processes with actors
  • Speak with relevant stakeholders

Output:

At this point it is worth considering what problems, issues, gaps etc the output is facing. You might want to refer to the following to gain a better understanding of this.

  • Quality control documentation
  • Issues Log
  • Complaints received
  • Performance management reports; KPI’s etc
  • Speaking with relevant stakeholders

Techniques:

Some of the techniques you might use to gather the above information are:

  • Interviews
  • Workshops
  • Activity Sampling
  • Document Analysis
  • Updating/creating draft Business Needs Log

This above gathered information can be documented under the following headings:

  • Summary of information gathered
  • Data gathered
  • Draft business needs
  • Draft world view 
  • Mind maps
  • Use case (as-is)
  • Rich picture diagrams
  • Create a draft business needs log, documenting the high level business requirements based on the stakeholders you have spoken with; this may need revising based on subsequent activities
  • Fishbone diagrams
  • Knowledge on structure, management, policy and change processes
  • Any other details that may come in handy for later stages to help support with questions, interviews, workshops analysis etc
  • The input vs output analysis would be equip you to create a draft gap analysis

With the above information you would be able to document the very high level requirements you will be able to review for the compilation of your business needs log and consider when doing further analysis; you may alternatively encapsulate gathered thoughts, comments etc in to a general “world” view. You will also have good information on the organisational structure, divisions, policies, strategy and more to have a better understanding of the process of change and management within the company when doing further analysis, which is always useful, for context.

And there you have it; you’re now ready to move on to your second activity; considering the perspectives of your stakeholders. The next stage is concerned with analysing stakeholders and their perspectives on the situation/project, to get a better understanding of their values and beliefs for the project. 

The end result of the complete business analysis process will be a clear, non-ambiguous, relevant, reasonable and testable requirements document. The document will take the company’s internal structure, management and policies in to consideration, meeting all relevant requirements and deliverables of the project and your stakeholders, hopefully getting them to buy you a drink at the end of it. Or in my case a can of Dr Pepper; I love that stuff.

The Business Analysis Process: 2. Considering Perspectives