“Are you a business analyst? So, you basically write down the requirements people give you, right?” You might have met quite a few people in your career that think like that. Or maybe you’re a business analyst, but due to time constraints in your project, you can’t do much more than that. Anyways, comparing an analyst to a scribe can’t be further away from the truth. Let’s see what the BABOK Guide has to say about it.
What is BABOK?
Let’s start with the simple question – what is BABOK? BABOK stands for Business Analysis Body of Knowledge. BABOK Guide was written by members of IIBA – The International Institute of Business Analysis – which is the largest non-profit professional association in the world focusing on the field of business analysis. To put it in numbers – they have chapters in 40 countries and 30 000 members worldwide.
The purpose of the BABOK Guide is to define the profession of business analyst and be the primary source of knowledge in that field. It consists of 6 knowledge areas covering knowledge, tasks and skills necessary to be effective in their execution. They are:
- Business Analysis Planning and Monitoring,
- Elicitation and Collaboration,
- Requirements Lifecycle Management,
- Strategy Analysis,
- Requirement Analysis and Design Definition,
- Solution Evaluation.
Let’s take a look at each of them.
Business Analysis Planning and Monitoring
When you plan on doing something complex, the first thing to do is to create a plan. Business analysis usually delivers us a plan of what we have to develop or change in our organization to reach our goals. But the analysis in itself can be a very long and complicated process. In big projects, we have to conduct dozens of interviews and workshops, manage even more requirements, make sure we contact all the required stakeholders and at the end review our solution with the critical ones.
How can we make sure we don’t overlook anything? How will we communicate with everyone? That’s where business analysis planning comes into play. This knowledge area includes 5 tasks.
Plan Business Analysis Approach
Here we determine if we are going to use a more predictive or adaptive approach, how formal our analysis is going to be, what level of details will satisfy us, how big the change is, how much time we have and other general issues. After that, we review and agree on the approach with the key stakeholders.
Plan Stakeholder Engagement
We have to plan our approach to establishing and maintaining effective working relationships with stakeholders. Stakeholders are all people that are either interested, impacted by or involved in our project. In this task, we have to identify all of them and analyze them – which ones have the highest impact, decisive power, and interest in our project? What are their communication needs? And so on.
Plan Business Analysis Governance
In this process, we identify the decision-makers among our stakeholders and the information required for decisions to be made. Without this information, we might get stuck, when we have our requirements ready, but no person to accept them. Or even worse – we moved on as our requirements got accepted, but later we learn that by the wrong person.
Plan Business Analysis Information Management
Business analysis information is all the requirements, diagrams, design, stakeholder concerns, etc. that we have gathered or prepared. Here we decide where they will be stored, rules of indexing (e.g., requirements IDs), their level of abstraction and attributes. Also, who will have access to read and edit them?
Identify Business Analysis Performance Improvements
While all the other tasks we usually do once and throughout the project just to make sure that their results are up to date, this one is ongoing. In the beginning, we set some measurements (or they can be set by our organization) regarding e.g., deliverable dates or frequency of changes. Then stakeholders evaluate our work from time to time and on the basis of their reports, we can find preventive, corrective or improvement actions to better our approach.
Elicitation and Collaboration
This knowledge area focuses on obtaining information from stakeholders as usually, this is the lion’s share of analysts’ duties. It covers everything from preparing your sticky notes and a venue (at least it used to be so a few years ago) to communicating your findings to stakeholders and making sure they can work toward what is best for the whole company and not only their department.
Prepare for Elicitation
Here we focus on everything we will need to gather the requirements. We define the purpose or what information we expect to get, when, from whom and where. We also select the proper techniques e.g., interviews, workshops or questionnaires. Finally, we communicate with stakeholders, so they can come properly prepared.
Conduct Elicitation
The work of a business analyst is not one of a scribe (although it is perceived by many as the same). We need to draw out the information we require, identify relevant information, facilitate meetings and keep everyone focused on the topic. Gathering information can be done in many ways – by talking to other people, going through documents or experimenting. BABOK Guide suggests 18 different techniques we can use.
Confirm Elicitation Results
After the information is gathered, we have to review it. This is done to check if it is accurate and consistent with everything else that we have. It can also help us discover any errors, omissions, conflicts and ambiguity.
Communicate Business Analysis Information
After we have prepared some business analysis information, we have to communicate it to our stakeholders in the proper scope and style depending on the recipient. It has to be done to ensure that all stakeholders have a shared understanding of the requirements.
Manage Stakeholder Collaboration
Stakeholders ever so often have different assumptions and needs (e.g., never-ending conflict between UX and SEO). It is our job as an analyst to encourage the stakeholders to work toward a common goal. Even if sometimes reaching that goal can get one of them fired (e.g., automation, which will result in some layoffs).
Requirements Lifecycle Management
Requirement lifecycle management focuses on working on a specific requirement. How does it connect to other requirements? Does it impact some parts of our organization negatively? Does the new information we’ve gathered change the existing requirement? What if a stakeholder wants to change a requirement, he/she has submitted earlier in the project? Tasks from this area will help us deal with all those situations.
Trace Requirement
We should always keep track of a requirement’s history and know the relationships between requirements, designs and releases or iterations. This way we can clearly identify the effects of introduced changes.
Maintain Requirement
Some requirements represent an ongoing need (e.g., compliance with a legal act) and can be reused in different projects. As such its accuracy and consistency should be always maintained, so it remains valid over time.
Prioritize Requirement
Everyone knows what the prioritization is. But depending on the company, project or stakeholders there can be many bases for it:
- cost,
- ease,
- profitability,
- risk, time,
- value, etc.
Also, prioritization is a constant process, so we should regularly work with our decision makers to keep the priorities up to date.
Assess Requirement Changes
Any change in the existing requirements should be thoroughly analyzed. Maybe this small change in the designs will be much more user friendly, but will actually cost us hundreds of page views per day due to conflict with Google bots logic? Or maybe the newly suggested solution will be faster to implement, but will cost us more in the long run due to higher hosting costs? Or maybe it is much more effective in the long run, but won’t be accepted by the sponsor, because of current budget restrictions?
Regardless of how brilliant the reported change seems to be, we should always assess it in relation to all the business analysis information we already have, before introducing it to our requirements.
Approve Requirement
After we are sure we’ve gathered all the needed information about a requirement, prepared some designs perhaps, we should send it to key stakeholders for agreement and approval of it. That way we can move to solution construction without a risk of unexpected conflicts.
Strategy Analysis
This type of analysis is not something your everyday analyst does. Work of most of us focuses on projects, while strategy analysis can apply to the whole organization. It can work on multiple levels:
- business (what we want to do to differentiate us from competition, what will be our selling point),
- functional (breaking down our company strategy into units or departments we have in our organization),
- product (how will we market it, what needs will it satisfy).
Analyze Current State
As the name suggests we want to describe the state of the organization as it is now. It will help us with evaluating possible solutions later on (maybe doing nothing is actually better than other options?) but it also lets us answer the question why the change is needed, what problems can’t be fixed, or what opportunities seized without changing the current state of the company.
Define Future State
We can’t make (or at least shouldn’t be making) any big changes in our organization, if we don’t know where we are going. So, we define the set of necessary conditions that will qualify as a success for us. Not yet the changes, that need to happen, just the state we want to achieve. And we check if it can be agreed upon by all stakeholders and is achievable within available resources.
Assess Risks
In this task we identify and manage the risk that can materialize during our transition or in the future state. Depending on many factors – our company state, the probability of the risk, its impact, etc. – we decide what our strategy in each case will be – avoiding, transferring, reducing, accepting or increasing.
Design Change Strategy
Now that we know where we are and where we are going, we can start working on how we plan to get there. What new rules or processes have to be introduced, what investments and resources are needed, how our solution will deliver the value we expect? It is also important to always identify alternative change strategies, before we select the recommended approach.
Requirements Analysis and Design Definition
The bread and butter of analyst’s work. All the requirements, we have gathered during the elicitation process, now have to be specified, structured and validated, so we can start working on a solution that will meet the business needs.
Specify and Model Requirements
In this step we analyze, synthesize and refine our elicitation results into useable requirements and designs. We have to take into account, what the appropriate levels of abstraction will be – e.g., a developer will need a much more precise info, then a sponsor.
Verify Requirements
Here we carry out the final verification of our requirements. We make sure they meet the quality standards agreed upon in the beginning, check if they are easily understood and will serve their purpose. The output of our work should be requirements and designs that we can send to the stakeholder for final acceptance.
Validate Requirements
It is an ongoing process in which we meet with our sponsor or a client to ensure, that the solution requirements and designs, that we have prepared, are aligned with their business requirements and objectives.
Define Requirement Architecture
Now that the requirements have been validated, we have to make sure that they – as a whole – support one another and the overall business objectives. Then we should organize them into structures relevant to different stakeholders.
Define Design Options
When we design a solution, we may be able to define more than one option to achieve the desired future state. We have to make sure that all of them satisfy the requirements. Here we can also identify any additional opportunities to improve our business as a by-product of the solution.
Analyze Potential Value and Recommend a Solution
Before we present the final results of all our hard work, we have to analyze them one last time. We should check which one of the solutions, we’ve come up with, brings the most potential value. But also consider their costs of implementation, training, maintenance, etc.
Solution Evaluation
While an analyst’s work in a project usually ends after the solution is selected (putting aside the occasional support for the developers), BABOK Guide actually suggests that the analyst should be brought back near the end of the project. They could be really helpful in comparing the performance of the solution with the expected results and the removal of barriers that prevent the full realization of value.
Measure Solution Performance
It begins when we are able to begin keeping track of how our solution is performing. Without any hard data, we won’t be able to find out if the solution meets the business needs.
Analyze Performance Measures
Performance measures alone aren’t enough to take any corrective actions if needed. In this step we assess the effectiveness of our solution in comparison to the value we were expecting, using the data we’ve collected. We might even find out that the solution is actually over-performing.
Assess Solution Limitation
This task is similar to assessing solution limitation, but here we are looking at factors outside of the solution, that are impacting it negatively. They can include company culture or operations, that haven’t been adapted to the new conditions yet.
Recommend Actions to Increase Solution Value
When we have analyzed all the reasons, why the solution is underperforming, we can move to find alternatives and actions to increase its performance and realization of expected value.
Final thoughts
This is but a brief look at what you can find in the BABOK Guide. It is over 500 pages after all. There is – among other things – a much deeper dive into the tasks I’ve listed, guidelines for 50 different techniques useful in business analysis and descriptions of skills that every analyst should hone.
Despite being written by practising analysts, it still describes, how things should work in the perfect world. So, you don’t have to learn or even read it all. Just make sure to remember, that a business analyst is not a scribe. It is the person in the project, who should be thinking much more than anyone else. But yeah, in the end, writing it all down is still necessary 😉
***
More articles about the work of an analyst can be found here (PL):
Leave a comment