Reviewing BABOK Guide v3

High level view of the BUsiness Analysis Core Concept MOdel (BACCM)

High level view of the BUsiness Analysis Core Concept MOdel (BACCM)

Since the public review started around 4 hours ago, I've been working my way through the first two chapters of the BABOK Guide v3, under the user name sci_ba.[1] I'm up to 2.2 Key Terms now, and taking a break. I've added over 20 comments so far, ranging from 'please replace all instances of "in order to" with "to", and "within" with "in" ', through clarifications, to a few deeper concerns - three of these, to be precise. Overall, I think the content is pretty solid: fairly clear and readable, and mostly covering the introductory material that BAs and some key stakeholders should understand.

Concern #1: Context

My first serious content concern is with the definition of the core concept 'context'. The definition in the draft is,

The circumstances that form the setting for a change and allows for further understanding and assessment of the change.

I've probably done more work on the Business Analysis Core Concept Model (BACCM) than everyone else in the world combined at this point, and this definition confuses me. A simpler definition might be that the context is everything relevant to a change but which is not controlled by the change effort, or similar. The concept of control is critical to the boundary between 'change' and 'context'. A regulatory body like the CRTC or FCC could be a stakeholder for a team working in Comcast or Rogers Communications - but they could also be part of the context. If the change team has no control over the regulator - no lobbiests, no contact, no negotiations - then the regulator is part of the context, not part of the change. If the change team can influcence the regulator, the regulator is part of the change.

This definition doesn't preclude the ideas above - but it sure doesn't make them clear.

I'm also concerned that this definition breaks a powerful analytical technique based on the BACCM: substitution analysis. To do this, take any term - core concept or otherwise - and start substituting the first part of a core concept definition in for the word. For example, substitute 'problem, opportunity, or constraint' for need. (The second clause of the other definitions is explanatory and provides emphasis, but is not absolutely necessary to the definition.) A requirement is not just "a usable representation of a need." It is "a usuable representation of a problem, opportunity or constraint."

Business Analysis is not just

the practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders.

Using a "substitutable" definition for context, it is

the practice of enabling [controlled transformation of an enterprise] in the [uncontrolled environment] of an enterprise by defining [problems, opportunities, or constraints] and recommending [specific ways to satisfy needs] that deliver [worth, importance, or usefulness] to [groups or individuals with a relationship to the change or the solution].

In other words, the definition of context doesn't quite break the model - but it strains it.

Concern #2: The Deadly 'S'

"Requirements" (noun) is paired with 'design' (noun or verb) in many places. This distinction seems petty and pedantic. Based on the vast amount of discussion and argument and discord comes from the confusion of design (activity) and design (artifact), it isn't. In the BABOK Guide, if 'requirements' is used to refer to a representation, 'designs' should be used to make it less likely that the reader will think of the activity. We should see "requirements and designs" and "business analysis and design" - but never "business analysis and designs" or "requirements and design".

Concern #3: Unrealistic Risk

Section 2.2 says,

A risk is an uncertain event or condition that, if it occurs, will affect the goals or objectives of a proposed change.

If the key terms and core concepts are supposed to facilitate communication with many stakeholders, and be as near to common use as possible, this is wrong. Risks don't just 'affect the goals or objectives of a proposed change.' Risks can affect the change, the solution, the stakeholders, the context, and the need - in each case by reducing value. If this definition of risk is accurate, it is natural and common to hear statements like,

  • "We are at high risk of making our targets this quarter."
  • "Can we transfer the risk of a sudden increase in our stock value?"
  • "By implementing this solution, we risk gaining customers."

Statisticians are welcome to put a minus sign in the equations related to risk; business people and business analysts and everyone else calls this 'benefits' or 'gains'.


[1] My name appears on many pages in the 'Created By' link under the page title, and links to my 'when-I-worked-for-IIBA' profile. I'm not with IIBA anymore - so a new profile was in order.

Julian Sammy

A passion for business performance has driven Julian’s decades-long, evidence-based exploration of human behaviour, emerging technology, and information science. His insights are often surprising, and are shared in a provocative, engaging style in print and in person. Julian has delivered inspiring and informative keynotes, created and delivered many track sessions, and advised senior managers and executives from many industries. As the Head of Research and Innovation for IIBA, Julian led a global team of volunteer researchers in the creation of a scientifically testable theory of business performance. As a member of the Core Team developing the next version of A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) for IIBA, he drove the collaborative development of the Business Analysis Core Concept Model — a work that is so fundamental to the profession that it is the foundation for the new definition of the profession. In March 2014 Julian Sammy and Kathleen Barret co-founded MicroMarketplace, to get on-demand expert advice to managers, one hour at a time.