Studying the BABOK: what is in it for you?

Already for some time I was thinking of studying the BABOK, Business Analysis Body of Knowledge, and getting my official ECBA certification. A few of my colleagues had done it before, but for me it seemed quite a time investment and very dry material to read. But then, when some of my colleagues started a BABOK Study Group, I decided to join in. And I am quite happy that I did because it gave me some very valuable insights and takeaways on the 6 key knowledge areas for business analysis.

The BABOK consist of 11 chapters, in which it explains the Business Analysis Key Concepts, 6 Knowledge areas and related tasks and activities to be considered by the business analyst to perform in these 6 knowledge areas, underlying competencies (so what behaviour, knowledge and qualities do you need as a business analyst) and 50 Techniques to support business analysts in their work. The BABOK ends with a matrix where techniques are being mapped against the tasks to be performed in the 6 knowledge areas.

For this blog, I will mainly focus on the Knowledge areas, because I personally gained some very valuable insights from these. I am not trying to give a summary of the BABOK here, but instead list the important take aways from this very interesting and inspiring guide for Business Analysts!

Business Analysis Planning and Monitoring

Business Analysis Planning and Monitoring is about organizing and monitoring business analysis work. It includes determining the Business Analysis Approach (Predictive versus Adaptive), Planning your Stakeholder Engagement (e.g. which stakeholders to include in elicitation and involve in decision making, what information needs to be shared and how should business analysts collaborate with different ‘types’ of stakeholders), Planning your Business Analysis Governance (how are decisions being made, who needs to be involved etc.) and planning Business Analysis Information Management (how is information resulting from business analysis being captured, stored and integrated with other information).

Key take aways:

• Identifying the right stakeholders (Stakeholder Analysis) ensures all critical needs are identified.
• Stakeholder attitudes influence whether they will be a champion or might negatively impact the initiative.
• To make sure your different stakeholders (with different attitudes and levels of influence) are engaged during the entire initiative, it is important to carefully plan your collaboration with them.
• By Planning your Business Analysis Governance, you make sure it is clear how decisions are being made, who are the decision makers and which approvals are needed and which information is needed in the process.

Elicitation and Collaboration

Elicitation is about obtaining information from stakeholders and other sources (like documents, systems and historical data) and confirming the results with the stakeholders. It is about discovering requirements and design information. Collaboration is about communication (regular, frequent and bi-directional) with the stakeholders and working together towards a common goal.

Key take aways:

• Elicitation and collaboration is an ongoing process for the duration of business analysis work and can be planned (interviews, workshops), unplanned (at the coffee machine) or both.
• Elicitation results need to be checked on accuracy and consistency with other information (documents or input from other stakeholder for example, are there no conflicts in the gathered information)
• Good collaboration with your stakeholders, making sure they have the right information and they feel heard and recognized, motivates them to support change

Requirements Analysis and Design Definition

In the Babok Guide, after the chapter of Elicitation, the focus shifts to the knowledge area of Requirements Life Cycle Management. However, that chapter assumes the requirements have already been specified and modelled. But here’s the catch, the groundwork for this phase is actually covered in the knowledge area of Requirements Analysis and Design Definition. So, let’s start by understanding how to analyse and design requirements before we move on to managing them. This knowledge area uses, amongst others, the input of the Elicitation and transforms these inputs into verified and validated requirements, possible solution options and solution recommendations based on potential value.

Key take aways:

• Verification of requirements is about the quality of requirements and the fitness for use.
• Validation of requirements is about making sure the requirements support the organization’s goals and objectives.
• Requirements Architecture ensures the requirements collectively support one another to achieve the overall business objectives and meet stakeholder needs.
• The relation between requirements will be represented in the traceability of requirements (see Requirements Life Cycle Management).
• Defining Design Options is about defining the solution approaches (create vs purchase existing solutions or both) that represent sets of requirements.
• Deciding on the recommended solution is done by estimating and modelling the potential value (finance, reputation, impact on marketplace, etc.) delivered by a set of requirements and comparing the potential values of all possible options.

Requirements Life Cycle Management

Now we get to the managing of the requirements that have been defined during the Requirements Analysis and Design Definition. Requirements Life Cycle Management is about managing and maintaining requirements and design information from the moment they were elicitated until they retire. The focus is on establishing relationships between related requirements and designs, managing changes to both, and gaining consensus on proposed changes.

Key take aways:

• A requirement only retires once a requirement stops to provide value.
• Tracing requirements (forward traceability and backward traceability) is about maintaining relationships between requirements and making sure the effect of a change to one of them is managed.
• Maintaining requirements is about retaining accuracy and consistency of requirements and designs during the entire Requirements Life Cycle, considering approved changes, and supporting the re-use of both.
• Prioritizing requirements and designs are about ranking them according to their relative importance to stakeholders to achieve maximum value.
• Assessing Requirements Changes is about evaluating implications of proposed changes (e.g. increased value of solution, conflicts with other requirements, increased level of risk)  and making sure a proposed change can be traced back to a need.
• Approving Requirements is about agreement and consensus on requirements and designs.

Strategy Analysis

Strategy Analysis is about defining how to apply the capabilities of an enterprise most effectively to reach desired goals and objectives. It gives context to requirements analysis and design definition and helps stakeholders to decide whether to address a business need. Strategy analysis is about analysing the current state (understand the business need and how it relates to how the enterprise operates today, why is the change needed and what is the needed change strategy), defining the future state (making sure future state of enterprise is well defined, conditions to meet a business need are clear and stakeholders have a shared vision of outcome), assessing risks (understanding risks associated with achieving the future state and mitigation strategies to manage those risks) and defining change strategy (identifying several change strategies and selecting the recommended approach).

Key take aways:

• The future state describes Business Objectives or goals and Potential Value
• Change Strategy is a high-level plan to transform the enterprise from the current state to the future state

Solution Evaluation

This knowledge area is about evaluating the solution (against business objectives) delivered by assessing the performance of the solution and the value delivered for the enterprise and identifying constraints that prevent the full value of the solution being achieved. This is the only knowledge area of the BABOK where the activities are around an actual existing solution or solution component.

Key take aways:

• Performance of the solution can be measured by quantitative measures (numerical and countable) or qualitative measures (subjective, perceptions from customers, stakeholders, etc.)
• When analysing performance measures, potential value can be used as a benchmark against which solution performance can be evaluated.
• Assessing solution limitations helps you identify the internal factors of the solution that prevents the full value of the solution being achieved. This is mostly done in parallel with assessing enterprise limitations that focuses on the external factors that limits value realization (like environmental factors, culture and stakeholder interests)

As you can see, studying the BABOK gives a lot of valuable insights in how to successfully perform the profession of Business Analyst. My next step is now to get certified and see how I can apply all this knowledge and the described Techniques in the BABOK in my daily work as a Business Analyst. Interested? Then stay tuned for a follow-up on this blog soon! In the meantime, if you have any interesting comments, experiences, tips on how to apply the guidelines/ practices of the BABOK in your daily work, please share them here in the comments.

Did you become interested and inspired by my key take aways from the BABOK? Then let me guide you to some interesting sites to learn more about the BABOK:

BA Bootcamp – BABOK Untangled Series from Luuk Vermaas en Gert Zweedijk from Olympic training and consultancy. These webinars, that are recorded and can be listened to on youtube, makes the BABOK guide comes alive and less dry to read afterwards. They explain very well the concepts and provide good examples. For me it was a really good addition to the BABOK itself!

Business Analysis Global Standards of Practice | IIBA®