Month: November 2019

BACCM: Impact on Knowledge Area 1. Business Analysis Planning and Monitoring

BACCM: Impact on Knowledge Area 1. Business Analysis Planning and Monitoring

In 2015, IIBA published it’s Business Analysis Body of Knowledge (BABOK) v3, which places a high emphasis on developing the BA Core Concept Model (BACCM). The BACCM is a significant part of testing for certification. So to better understand the BACCM and how it relates to the Knowledge Areas, I will attempt to explain how the BACCM ties everything together.

According to BABOK, v3, the following table represents the application of the Six Core Concepts to the Planning and Monitoring Knowledge Area.


First, some basics. The Planning and Monitoring Knowledge Area is concerned with setting the guidelines of how the analysis will be done, as well as how the effectiveness of the analysis will be measured. Putting it another way, it’s deciding how we will analyze the analysis. I know, redundant. But how else will we know if we are working our plan, or if our efforts are practical and efficient? So for the Planning and Monitoring Knowledge Area (the focus of this article), it is in this context that the Six Core Concepts of BACCM are being applied. So let’s expand the relationship between these concepts and Planning and Monitoring.


In applying the Core Concept of Change to the Planning and Monitoring Knowledge Area, the business analyst considers how changes will be made to the plan and monitoring documents. If Planning and Monitoring need revision, how will that revision occur? Just as a project should have a change request process, so should the analysis.

For example, in the middle of analysis, a new regulation has been enacted requiring additional information to be captured and analyzed if your company exceeds some threshold. The additional data will likely require changing the analysis approach because there will be a requirement to measure the company against that threshold. This new requirement forces an alteration to the plan.

How will such a change be requested and approved? How will the change in the plan be incorporated with existing plan documents? Of course, this will affect the project solution at some point, but for the Planning and Monitoring Knowledge Area, the project solution is not the focus. The effect will be documented in the “Business Analysis Approach” document (BABOK v3, 3.1 Plan Business Analysis Approach) as well as the “Governance Approach” document (BABOK v3, 3.3 Plan Business Analysis Governance Approach).


In applying the Core Concept of Need to the Planning and Monitoring Knowledge Area, the business analyst is determining the best approach for conducting the analysis. The primary consideration is in the context of the change and includes:

  • How to best get the information needed for the analysis and how to represent the results? 
  • What are the tools and techniques needed? 
  • Why are these better than other options?

The Business Analysis Approach, Stakeholder Engagement Approach, and Governance Approach all impact Need. Need then affects the “Information Management Approach” document (BABOK v3, 3.4 Plan Business Analysis Information Management).


In applying the Core Concept of Solution to the Planning and Monitoring Knowledge Area, it is again important to remember we’re analyzing the analysis. This can take you in two directions:

  • How do we determine what kinds of analysis should be performed? This is the Planning part.
  • How can we determine the impact of the analysis on the resulting implemented solution? This is the Monitoring part.

In dealing with Monitoring, we can ask questions like the following:

  • How do we know if there were items missed?
  • How do we know if we’ve added too much?
  • If there are errors in the implemented solution, are those resulting from the analysis, the requirements, or the implementation? 
  • How do we identify if there are there missed changes, need unrepresented or uninformed stakeholders? 
  • Did it achieve the expected value?

As it relates to Planning and Monitoring, the Solution joins with the Need as influencing everything. Need focuses on the motivation – Why are we revising our Planning and Monitoring documents. On the other hand, Solution focuses on execution – How will these documents be changed.


In applying the Core Concept of Stakeholder to the Planning and Monitoring Knowledge Area, we need to understand what the stakeholders need to see from the analysis. Doing this analysis during the Planning and Monitoring Knowledge Area could reveal that individual stakeholders need a high-level view, while others need greater detail. Some may need to see technical aspects, others need a financial assessment, and others need to see that everything is going according to plan. Understanding the full set of stakeholders needs dovetails well with the Need core concept. You cannot fully understand Need unless you understand Stakeholders. This will impact the “Stakeholder Engagement Approach” document (BABOK v3, 3.2 Plan Stakeholder Engagement).


In applying the Core Concept of Value to the Planning and Monitoring Knowledge Area, we need to know what is valued by Stakeholders and how to demonstrate that the value is achieved. As such, Value is an integral part of the other concepts of Change, Need and Stakeholder. as well as the primary driver for how the Solution will be measured.

Here, the question is, how is Value determined. Planning and Monitoring will be concerned with the value equations for the final product, as well as how to confirm the potential value will be verified. But it will also be concerned with the impact of the Analysis effort on value.


In applying the Core Concept of Context to the Planning and Monitoring Knowledge Area, we need to ask Why. Why is this change to the Business Analysis plan required? Why do the stakeholders value certain items? Why is this analysis required?

When we discussed the Core Concept of Change, we gave an example involving a new regulation. Understanding the new law would provide the context.

With the perspective of the BACCM, we have a framework for understanding the various aspects of Planning and Monitoring. And that framework can be leveraged to produce a complete set of plans for this Knowledge Area.

BABOK v3, ch3

Process Begins with Bach

J.S. Bach

Yes, that Bach. Johann Sebastian. There were others, his children primarily. In many ways, western music is influenced by him more than anyone else in history, including (I can hear the collective gasp) the Beatles.

I’m not going to review his impact on music though, but his impact on the beginnings of my IT career.

What does Bach have to do with “process”

In college, I was a double major in Applied Mathematics and Music. The Music major was much the harder of the two. And Dr. Hall was the most challenging professor of all. I will admit to never getting over a C+ in any of her required classes. Although I liked her as a professor, I thankfully only had her for two courses needed for my major.

It was Spring term of my senior year when I took Baroque music history, a requirement for the major. And the most significant figure of that period was, of course, Bach. And as usual, my research papers were insufficient to get a B, but I did improve significantly by changing my approach to the material.

Instead of reading tons of materials from various musicologist (the term that is given to music historians), only to choose the wrong sources, I did my own thing. I dissected one of his works, “The Easter Oratorio.” And by dissection, I mean the basis of my paper was a discussion of a chart I constructed which looks more like a Work Breakdown Structure than it does a piece of music. That brilliant shift got me up to an impressive C+ in her course.

By the way, my overall GPA was 3.3. And I was the highest-ranking music major in my graduating class. Well, I was the only music major in my graduating class. It was a small school.

The Discovery

The approach I took toward this paper is one that dovetails nicely into my eventual profession in Information Technology. I’m not going to rehash the paper but will show several of the elements Bach commonly used. By identifying all of the source material used in the piece, I was able to document the musical equivalent of a transformation process, both on a thematic and structural level.

That transformation is illustrated in various ways. Thematic transformation can be analogous to data transformation in systems. When looking at thematic transformations, you can see where the themes started and how they were changed along the way to a finished product. Common transformation processes include truncation, key changes, inversion (the theme basically upside down), retrograde (backward), and various repetitions with other themes creating a counterpoint or counter melody.

But another discovery is the structural transformation, which is more in line with process analysis. Bach is notorious for structural frameworks. Often involving numerological symbolism, these structures are part of the story of each composition.

Later generations would settle on the simple ABA “song” or “sonata” form. Often Bach would use a ABACADACABA form. Yes, that is exponentially more complex. Although this work is considered short, lasting about 45 minutes, each of those sections did have some time to develop. All those “A” sections are repetitive in style, not content. In his compositions, the central “D” section would be the point of highest tension. This is called a chiastic structure, which Bach used as symbolic of the cross, which is the subject of Easter.

Often the central section would feature intervals of an augmented 4th, called “the devil in music” partly because of its extreme dissonance, and partly because of its difficulty to sing that interval. In the Easter Oratorio, he did something different. He changed keys, adding a sharp to the key signature. That sharp also symbolically represents the cross.

The musical themes, the lyrics, and the structure of the piece all tell the story.

Relation to Information Technology

With the thematic and the structural transformations, Bach addresses the subject in both a personal and an overarching global sense. I find that mirrors much of what we do with systems.

In the same way, as a Business Analyst, I use tools and techniques to communicate the desired transformation. We transform individual elements through data manipulations and global structural elements through process redesign. This transformation is of processes and data. The tools I use augment the desired changes, highlighting specific functionalities. They break down the elements of a feature the same way Bach segments his themes. They move to the critical point of decision in a way similar to how the conflict redeems the theme and propels it to its final destination.

I would not realize how important this paper, and a couple of others, would be to my eventual career. I got started in IT because of my Math degree. But I understood it so much more because of my Music major.

While cleaning out a storage unit, I found my old Music History folders. And there it was. The orange notebook I used for the Baroque Music History class. And inside was the paper called “The Symbolism, Form, and Rhetoric of the Easter Oratorio by J. S. Bach.”

As I reviewed this paper, I was reminded that there is a language the composer used to tell a story — the techniques used in the composition highlight the transformations. And like Bach, I have a language, a set of tools, which I use to tell a story of transformation.

Additionally, I saw how it mirrors communications among multiple stakeholder groups. If A were the shared understanding, the other sections are enhancements from other groups. As a CBAP, I have experienced enough to communicate on multiple levels. It is the difference between ABA and ABACADACABA forms.

Understanding the Agile Mindset

In today’s post, I will discuss The Agile Mindset.

You may be thinking, why do they call this a mindset? Isn’t it simply a methodology or framework that is applied to solve a problem? Some clarity is needed to define what is a framework or a methodology. And with that clarity, we will show that Agile is neither.

So, let’s start by thinking about what a methodology is, versus a mindset.

Why a Mindset?

On a high level, a Mindset is a way of thinking about things. It involves ideas and attitudes and is based on principles. In Agile, there are seven principles, which we’ve touched on already here. Agile can be applied using any number of methodologies or frameworks, so long as those principles apply. 

Agile Extension to the BABOK®  Guide – chapter 2.2

Agile is not a framework. Instead, you can think of it as a collection of frameworks that meet a mindset, possibly including frameworks that have yet to be envisioned.

To be Agile implies that there is flexibility for each unique situation, allowing the practitioners and teams discretion to choose what works. Each project is unique, and by selecting an appropriate implementation of a framework – a methodology – that uniqueness is encouraged. 

Mindset – Framework – Methodology

Let’s clarify this a little more. I find it is always useful to give a simple definition.

Mindset – Framework – Methodology

The difference is from general to specific. To start, a Mindset is simply a way of thinking about work. It is a philosophy which shapes decision-making, upon which a value system can be determined.

A framework is a set of concepts and ideas that guide teams. This goes beyond philosophy to defining broad techniques which may be used to define and address the problem.

Finally, a methodology is a specific application of a Framework.

So, if you are working in Strategy, and the organization decides a project needs to use Scrum, that is a Framework decision. However, if it is later determined that the sprints will be three weeks, and that specific elicitation techniques will be used, such as Job Stories instead of User stories, that is defining the methodology.

Applying the Agile Mindset

When applying the Agile Mindset, we need to understand a few things. 

Agile Extension to the BABOK®  Guide – 2.3 Applying the Agile Mindset

One of the misconceptions about Agile and it’s related frameworks, as well as any other project methodology, is that it’s not limited to Information Technology. Agile has been applied to Manufacturing, Retail, Legal, Medical and many other organizational domains.

It is dependent on a few things such as Collaboration, Skill and Knowledge. I think of these as Risk Factors. If these are delayed or ineffective, the results will be sub-par. What jumps out to me on this level is Knowledge because that is something that becomes available just as it is needed, as User Stories or Cards are “groomed.” It also can be viewed as an output or by-product of Collaboration and Skill.

When Agile is applied, value is delivered based on needs, with an iterative delivery, with known expectations on what is delivered, how it will operate and when it will be ready.

Examples of Agile Frameworks

Characteristics of Agile Frameworks

The 7 Principles of Agile Business Analysis describe how Agile operates. But there’s another way to look at it. When you see an Agile environment, what are the characteristics of that environment? How can you look in from the outside and say, “That looks like they’re doing some flavor of Agile?”

Examples of Agile Frameworks

Various Agile Frameworks

Because of the dominance of Scrum, I often hear the terms Agile and Scrum used as if they are the same thing. Agile is not the same as Scrum. It is not a single framework. It is not prescriptive the way a framework is. An organization could apply any framework, such as Lean, Rational, Six Sigma, and of course Scrum, and would still be Agile. Also, some of those frameworks tend to focus on the development horizon only. Agile, as we’ve already discussed here, can be applied well before development.

Characteristics of Agile Frameworks
Agile Extension to the BABOK®  Guide – chapter 2.2
  • First, there’s an emphasis on respecting all of the team members and their creativity.
  • You can see that feedback and learning is greatly valued to guide the delivery of the highest-valued work first.
  • Collaboration and communication is a core priority, not just on the team, but all stakeholders, to have a shared understanding.
  • Work is divided into small chunks. Working, functional outputs are delivered on a regular iterative schedule.

When you look at the list of Agile frameworks from above, and I claim that as a representative but not an exhaustive list, each of them demonstrates the four characteristics.