BABOK Chapter Four: An Approach vs. A Step

While helping a certification study group run by my local IIBA chapter, we inevitably reached chapter four in the BABOK. Chapters three through eight describe the six main knowledge areas for business analysis. They are related to each other per a diagram in the version 3 BABOK (Figure 1.4.1), but that relationship isn’t linear or sequential.

When I discuss my framework for doing business analysis, I approach it from a more linear and sequential viewpoint, as shown here.

I’m always careful to say that my own framework is more a way of thinking about how to do things than a hard-and-fast prescription, as shown in the following figures.

Per the grid below, I observe that business analysis engagements can take many different forms, so the BABOK presents things in a diffuse way, more in terms of techniques and approaches than in terms of “do A, B, and C precisely in order.”

The left column shows the six major phases in my framework, along with the extra phases in a fully realized engagement. The top row shows the six knowledge areas in order as they are presented in the BABOK. I entered bold Xs in the grid where I thought there was an especially direct analog between how I think about things and how the BABOK presents them, and a muted smaller one where I thought there was a relationship but less direct. While I think of the BABOK’s approach and mine as being somewhat orthogonal, the BABOK describes approaches while I describe steps, you may note that the bold marks flow roughly from upper left to lower right, suggesting that both approaches tend to represent a flow through an engagement.

Addressing BABOK chapter four directly, as I represent below, I think it shows that Elicitation and Collaboration are performed in a cyclic manner, meaning the business analyst keeps engaging with the material with the customers and SMEs and stakeholders until everyone agrees on the results. This is why I illustrate my approach as a series of cyclic loops, where there is continuous iteration within each loop and also iteration forwards and backwards among the loops.

Let’s examine this diagram in detail. The darker blue items are the main activities in each chapter about the knowledge areas. Items 4.1, 4.2, and 4.3 involve preparing for elicitation, doing elicitation, and confirming the iteration, along with the lighter blue outputs that serve as the inputs for the next activity. I show them arranged in a circle, and have included a hatched arrow that isn’t described in the BABOK, to show that these activities proceed iteratively until full understanding or agreement is reached.

Item 4.4 involves communicating business analysis information. I always thought of this as sharing the outputs of the above cycle with the other stakeholders that weren’t involved in the given phase, but the BABOK show it as being a somewhat more independent activity.

Item 4.5 is about communicating with stakeholders, and that applies to almost everything that business analysts do. Looking at the representation of my six-cycle approach at the top of this post, it should be understood that the iterations in each cycle not only represent the work done by the BAs (and other practitioners), but also the communication and engagement with the stakeholders, and the internal communications and practices of the teams doing the work in each phase. The last clause may be understood more clearly if you think of a team from an external consultant or vendor providing goods and services to stakeholders in a customer organization. This naturally applies to all different kinds of practitioners working inside a single organization.

The form the iteration takes is different in each phase. In the intended use (problem definition), conceptual model, and requirements phases, the BAs are learning from the SMEs, and iterating until until they’ve demonstrated that they have developed a comprehensive and accurate conception of the current state and requirements for the future state. The flow is somewhat reversed in that the BAs are helping the designers, implementers, and testers deliver robust, working solutions that give the customers and stakeholders the solutions they need to do their work more efficiently and effectively.

This entry was posted in Tools and methods and tagged , , . Bookmark the permalink.

Leave a Reply