If you’ve not seen my announcement on LinkedIn, I have been very busy developing a course called Preparing for the Agile Analysis Certification Exam. It has been published on the Udemy platform, so it is available to everyone. This is a self-paced version of the course I have taught to Business Analysts across the US in association with the Bluegrass chapter of IIBA.
This covers the entirety of the Agile Extension to the BABOK Guide with over 3-1/2 hours of videos and several quizzes. The quizzes are intended to help foster the “Agile Mindset” and help you grow in understanding of the concepts presented in the Agile Extension.
If you are interested in learning more about Agile, becoming certified as an Agile Analyst, are curious about whether there is a career path for Agile Analysts, or just need some ideas on how to improve your projects – this is a great course to cover everything.
This post wraps up this series with a discussion of how the BACCM relates to Solution Evaluation. In its introduction of this knowledge area, the BABOK guide makes an important distinction between Solution Evaluation from either Strategy Analysis or Requirements Analysis and Design Definition – that Solution Evaluation is performed against work that has been done, where the other Knowledge Areas are looking at future work. For this post, when I talk about delivered work, that can be a prototype, beta, product increment, or full release of the product.
Solution Evaluation asks questions such as:
Does this do what is needed?
Does it perform well?
Are changes needed to the work that has been done?
Is the need satisfied?
Can the need be satisfied?
How does the BACCM interact with Solution Evaluation? The chart below gives a summarized answer to that question.
The Core Concept of Change allows looking at what has been finished and decide that a course correction is needed. That correction could be an adjustment to adjust what has been done, change the future planned work in some way, determine the product meets the need or never will.
All of the analysis is to be measured against the need. There are several factors in this analysis:
Changes to the organizational environment, which changes the need.
The expense of the solution may be significantly higher than anticipated.
The organization may have overestimated their capability to deliver the solution – it may not be possible.
The time to deliver may be more than anticipated (likely also reflected in costs).
There are four options which could result from an analysis of these factors:
If the delivered work continues to provide hope of meeting the need but has not completely done so, then the project should likely continue.
If the delivered work meets the need, but additional features are determined to be valuable, a decision to extend functionality beyond the minimum viable product may be made.
Or, if there are no desired other features and the delivered work already meets the business need, the project will end with the delivered work.
Finally, if the analysis factors (environment, expense, capabilities, time) are weighed, and the project never will meet the need, it should be discontinued.
It may be a bit redundant, but it is the delivered portion of the solution that is analyzed by comparing it to the need. It may be possible to measure the realized value delivered as compared to the anticipated or potential value that was proposed.
In Agile environments, it is essential not to conflate effort with value as part of Solution Analysis. For example: If I take a job that pays $30/hour and a friend does the same role at another company for $25 – the effort may be the same but the value is not. Value is determined by the benefit received, not the effort used to obtain it.
At some point, the stakeholders will have the opportunity to review the delivered product and determine how well it meets their needs. They will be considering the question of how well it provides value. As an analyst, our job is to help their observations have a voice – determining whether the value is delivered, whether changes are needed, or whether the need cannot be met.
Here again, we need to recognize that need is only half of the value equation. From a financial standpoint, value = benefit – cost, where the benefit is the monetized representation of the need. There may be other ways to determine value based on some non-financial considerations, such as regulatory compliance. Yet still, when we consider value, this goes beyond merely considering the need.
Before the work, there probably was a determination of how much benefit would be received and an anticipated cost. So the Core Concept of Value measures that prediction against reality.
Previously we mentioned that a change in the organization’s environment might also mean that the need has changed. Several organizational factors may be in play. This may include any of the following:
External factors, such as changing public opinions or values.
Regulatory changes may alter what is required.
Organizational changes, such as changing corporate purpose, leadership, structure or viability.
Technological changes, such as new publicly available services.
Competitive changes where a competitor enters or leaves a market position.
Because Requirements Analysis and Design Definition has a broader scope than many see envision, including measuring requirements and designs against overall organizational strategy, this Knowledge Area remains essential to Business Analysis. Here is where models, designs, and solutions are documented, revised, and verified.
Inputs to this Knowledge Area include the Solution Scope, which represents potential gains. Outputs of Requirements and Designs will feed into any prototypes, beta versions, and eventually an operating solution. So, again, this is the central piece.
So how is this affected by the BACCM?
During Knowledge Area 2 – Elicitation and Collaboration, the Business Analyst worked to discover details about the need as well as what will satisfy the need. During the Requirements Analysis and Design Definition, there is a shift from understanding the need toward proposing optional solutions. The analyst could view each potential solution as a collection of changes and evaluate each set until one solution is chosen.
I know that sounds like Waterfall. For Agile proponents, the process is actually similar – however, it is performed against small chunks and reviewed in increments. The significant difference is that each product increment provides an opportunity to change in Agile, while Waterfall is much less adaptive.
While we may have produced multiple solution options, these options are evaluated against the Need. For this, there may have been some metrics discussed that define precisely what the need is. Then the potential solutions can be measured against those metrics to see how well each solution works.
For the assessment of need, remember that this element of the BACCM does not concern itself with cost or environmental factors. These are functional concerns at this point.
Some of the options, such as commercially available software packages, may provide additional capabilities beyond those that are described for the defined need. In this evaluation, the assessment needs to represent only those functions relating to the defined need. To do otherwise would introduce scope creep before the project even started. The overhead of the unneeded functionality, even if it is included in the price, may drive up the total operational or deployment cost as well.
On the other hand, the Core Concept of Value is much concerned about cost. But it does not stop there. Value may be a combination of the value gained – the cost of delivery and ongoing operational expenses. However, value may also include such factors as improving resource utilization for higher-value tasks. In such a case, the value can be intangible. Other value expressions could be compliance related, where the value derived is motivated by legal concerns more than financial.
That last statement is not intended to be a judgment on an organization. Many highly ethical enterprises existed for decades before legislation such as Sarbanes Oxley required improved audit controls on the processes of publicly traded companies. It merely means that the environment may have changed, which created a value on compliance, which was quite expensive to fulfill.
Going back to another element ignored by the Core Competency of Need, there is Context. On the simplest terms, Context is concerned with how the solution option fits within the organization.
One interesting side note is how there can be an interplay between Value and Context. A solution may be feasible but require added resources – thus driving up cost and decreasing the realized value of that solution. Another solution that can be supported without the additional overhead would then both fit better in the context and provide higher value.
At all points in this discussion, the concerns of stakeholders are to be considered. These concerns will be reflected as part of the need. But more than that, any documentation of solution options, as well as the selection solution, must be understandable to all stakeholders.
At first, this will be decision-makers and subject matter experts associated with the initiative. However, as the requirements near development, the delivery team needs to be increasingly consulted and included in conversations.
Now that all of the options have been measured against Need, Value, and Context, the Requirement Analysis and Design Definition can settle on a specific solution. Up to this point, the solutions have been discussed in a context of broad direction, not a thorough definition. The requirements have been high level for multiple reasons.
One of the common reasons is that the audience involved in making decisions will not require all the details to set a direction. But perhaps more importantly is to maximize the value of the analysis itself. If multiple options are being proposed, it merely may not be feasible to define the designs for all of those variations.
Once a direction has been determined, the analysis can become more focused on the solution. This option will then be refined in greater detail so that all requirements and designs will be captured, reviewed, verified, and validated before the start of delivery (either for the requirement, or the solution as a whole – depending on the SDLC chosen).
When we talk about Strategy Analysis, we are referencing the activities and analysis that is performed to ensure alignment with business goals and to address a business need. We ensure that the need has strategic or tactical importance to stakeholders and that proposed solutions meet the need and fit within the context of the organization’s capabilities.
According to BABOK v3, the following table represents the application of the Six Core Concepts to the Strategy Analysis Knowledge Area.
BABOK v3, Table 6.0.1: The Core Concept Model in Strategy Analysis
For this article, I’m going to take the BACCM items in a different order than what they are typically presented. For Strategy Analysis, there does tend to be a progression revolving between identifying the need, determining the scope and defining a solution. This progression could happen in an iterative fashion, or through stages depending on the chosen SDLC.
I know some will argue that the previous two statements are true for some SDLCs and not others. Waterfall advocates will say Agile does not have this progression. Yet, when you look at Agile literature, the feedback loops between Strategy, Initiative, and Delivery horizons are precisely what I described above.
Agilist, including myself, say that Waterfall does not adequately focus on the need. For me, the primary distinction is whether the result is as effective as needed when it comes to production. Forget whether it does what was intended – does it do what is needed now? Waterfall has too many instances where the need changed, but the project goes on as planned.
In Strategy Analysis, everything starts with the needs of the organization. Technically, you could say that for any of the Knowledge Areas, because they are all applied to meeting a need. But it is especially true here.
The need can affect a scope as broad as the enterprise, or as small as a department. Strategy Analysis will provide prioritization of all requirements.
There is a difference between knowing what is needed and knowing what has to change. I think of Change as it relates to Need as if it were an application of Newton’s 3rd law of motion – For every action, there is an equal and opposite reaction. For every need, some items will change to meet the need.
Identifying those changes is another part of Strategy Analysis that works hand in hand with identifying the needs. Change, in this context, becomes the scope of the project, defining what must be different from the current state to address the need.
Understanding what has to change to address a need involves understanding the context. Nothing is done within a vacuum. The context includes existing capabilities held internally, technologies that can be leveraged, and external factors defining what would be acceptable.
Context can also include market factors that can shape how a solution is delivered. For example, an analysis may determine a new product must have certain features that will drive market adoption. These probably should be developed uniquely for the product.
Alternatively, other analysis may uncover necessary features that are expected to be there. These are candidates for outsourcing since there is not much gain for a uniquely developed solution.
At a basic level, the potential value is determined by the need. The project exists to make that potential become a reality.
Strategy Analysis will review the potential value of a project and weigh it against other initiatives to determine which projects move forward and which are delayed or scrapped. Additionally, the value of the various features is also prioritized.
I have seen development teams working on an enterprise-level backlog and pulling globally prioritized requirements from multiple initiatives. I was the Product Owner in that environment, and it was very challenging to negotiate a global perspective from all stakeholders. But it is doable.
Stakeholders touch everything we have discussed so far. Most often, stakeholders will be involved in identifying the need. Subject Matter Experts can be consulted to identify needed changes within the context of the organization. These factors will merge into one or several viable solution options.
Collaboration is necessary in order to ensure that priorities and functionality are clearly understood by all parties.
In my opinion, the quality of stakeholder engagement is as strong of a success indicator of the project as the quality of the project delivery team.
As solutions are identified to meet those needs, those will also be broken down into features and prioritized. Here, it’s not what must change to meet the need, but how. The proposed solution is described, reviewed, and approved.
Strategy Analysis will involve determining the best solution out of all viable options. From there, establishing the priorities of which features to build first is a critical function.
Back to the Agile side of things, these decisions will be revisited frequently to confirm they still hold, or determine what changes need to be made.
According to BABOK v3, the following
table represents the application of the Six Core Concepts to the Requirements
Life Cycle Management Knowledge Area.
First, we need to clear up the scope of Requirements Life Cycle Management (RLCM). Whenever something is called “Life Cycle,” the implication is that we’re talking about more prolonged than the project. The same is true for SDLC (Software Development Life Cycle), STLC (Software Testing Life Cycle) as well as RLCM. None of these are talking about Project Cycle. So for RLCM, we are talking about processes that will span a period from cradle (the beginnings of the idea for the project) to grave (when the solution, not the project, is retired).
forget that changes to a solution continue throughout its life. So the
requirements will continue to be generated, just not as rapidly as when it’s
being developed. RLCM will be a necessary function, though some
modification to its processes is likely, as long as the solution is active.
In the context of of the RLCM knowledge area, the Core Concept of Change refers to how requests are evaluated and managed as the system transitions from development to maintenance, evergreening or end of life. Each of those phases in the application life cycle will likely represent changes in the review process. A simplistic example is that it would probably be tough to justify changes for a third party application that is nearing the end of manufacturer support. The rules that decide how change requests are managed and evaluated must change to reflect each stage. Those changes are what is revealed here.
All changes to the product must be made to meet a need. Once the need is identified, the changes must be traced back to it. Needs which change late in a solution’s life illustrate why RLCM is so important.
Whether you are utilizing a Waterfall or some Agile framework, the requirements were documented during the development of the solution. These requirements can be researched to provide valuable information concerning the resulting product which can help define what is needed.
Any changes to designs or solutions must be designed to meet the need. As the need changes, so does the solution, even if the need is long past the initial project. In the case of RLCM, there are many times that the practice of maintaining requirements ceases when the initial deployment is completed.
In my opinion, that is a very shortsighted practice. Instead, retain the initial project requirements in a searchable repository, and augment that information as changes to the functionality are applied.
Another practice is to simply view the source-code as the searchable repository for what the system does. The thinking is, nothing happens unless it is in the code, and the system was approved when it went into production. Therefore, the source-code should be a viable tool for determining the current state.
This also is shortsighted. It presumes that the person who needs to understand the current functionality has the same level of technical knowledge as the original developer. Items stored in a RCLM will be communicated in a way that is understood by both the Stakeholders as well as the developers.
Always engage the stakeholders to identify and clarify the need, discuss the solution and verify acceptance of the results. The RCLM must reflect their understanding of what needs to change, as well as why and how.
Going beyond deployment, this may mean reviewing functional specifications to determine the previous intent. Additionally, any post deployment changes will need review as well. The goal is to have as clear of an understanding of the current system as possible, and allow for additional requirement changes to be captured and understood.
when one thinks of adding Value, they are thinking of the Solution. In the
context of RLCM, Value is looked at in terms, not of the solution, but the
requirements which led to the solution. Perhaps it’s stating the obvious,
but requirements can affect value. BABOK v3 mentions one way – through
re-use beyond the current initiative. It seems that IIBA is seeking to address
value in terms of the Life Cycle, which implies a longer view of the
requirement than the initial implementation. Frankly, I find that to
be not a good example.
would suggest that the quality of the requirement significantly affects value
in that it impacts the development, testing, and end solution. Though
admittedly, the impact on Value using the requirement’s quality – that view is
a short term view. Yet it is one where value is 100% of the time affected.
Core Concept of Context must be understood to provide traceability and
prioritization functions for the RLCM. Without Context, it would be challenging
to correctly determine what is most important and move that higher in the list.
In previous articles, I
have discussed how Business Analysis has suffered an identity crisis of sorts.
But if there’s one area which people think is core to Business Analysis, it is
most likely summed up by the Elicitation and Collaboration Knowledge Area.
You’d think I’d be cheering for that. Not quite.
involves so much more than determining and confirming requirements. Yet without
Elicitation and Collaboration, much of the analysis effort could not even
begin. In many ways, this is often a starting point for getting into the
“what are we going to do” for this product, where Planning and
Monitoring (KA-1, which I also wrote about previously) tends more toward
administrative endeavors – determining how is the Business Analyst going to do
The Elicitation and Collaboration Knowledge Area describes the tasks to be used to gather information and verify findings. Elicitation must be a multi-directional process, which is why it is paired with Collaboration. The ideas discussed from one stakeholder often influence discussions with others. As the saying goes, “Everyone is smarter than anyone,” and that saying could be a model for Elicitation and Collaboration. Involving everyone (or representatives of constituent groups) in the best way possible, whether by one-on-one interviews, focus groups, JAD sessions, surveys, or other means, is the primary task of this Knowledge Area. And the primary result of that effort is the gathering of requirements and supporting documentation.
But it doesn’t end with
the stakeholders as the sole focus of elicitation. Collaboration with the
development team and other technical or support elements is also a critical
aspect of this Knowledge Area. This additional feedback will make the resulting
product successful. Without it, not so much.
So, with Elicitation
and Collaboration in mind, we will look at how the Six Core Concepts apply.
Here, the word “Change” refers to the scope of the analysis. It is the definition of what the analysis effort is intending to explore. During Elicitation and Collaboration, the analysis will collect and determine the characteristics of the “Change,” including impacts and concerns. Several factors can determine the techniques and depth of the Elicitation and Collaboration effort, including environmental factors, cultural factors, stakeholder’s interests, existing documentation and the nature of the change. So the Core Concept of “Change,” when applied to Elicitation and Collaboration, involves assembling all the details surrounding the requested “change.” I know that sounds a bit cyclic. Yet, when you get past that, the Core Concept of “Change” is the primary boundary and driver for the other six Core Concepts during Elicitation and Collaboration.
You may be thinking
that all 6 Core Concepts are supposed to be viewed as equal within the BACCM. However,
I didn’t elevate Change over the others. Change does provide a boundary
and a driver for everything else. But everything else also helps define
what Change is, so it all comes around.
Context is always
present and must be understood.
Say someone built a great Lawn Mower. It’s Zero-Turn, rugged, has a 70″ cutting area, and has mulching capabilities. And – get this – it is Self Driving. Just lay back and drink your lemonade (or whatever) while it runs circles around your hammock. And when you think it doesn’t get better – get this – it’s Solar Powered. Well, technically, it’s battery-powered but uses a Solar charging station. So there’s no engine noise, no emissions, and no runs to the gas station with the smell stinking up your car. And since it’s a mulching mower, there are no cuttings to worry about. This mower won’t spray you with clippings while you’re drinking that lemonade in the hammock. It runs for 4 hours when it’s batteries are fully charged. It finishes your yard in 40 minutes. Attachments include a built-in edger and trimmer. Life is good!
But the project which
funded this great device was NASA’s next deep-space mission. As great as
the Driverless, Solar Powered, Mulching, Edging, Trimming Lawn Mower sounds
(whisper-quiet actually, so it doesn’t sound), it’s probably not a good fit for
what NASA has in mind. Although many possibilities have been discovered in
what NASA calls “the Goldilocks Zone” (not too hot, not too cold),
we’ve yet to find vegetation on other planets. The time spent developing
this machine was wasted and has delayed the multi-billion dollar space
exploration project for a year. The developer of the super-mower just got
charged with obfuscation of government funds and will likely serve ten
Putting aside the silliness of the above scenario, the point does remain – Context can mean everything to the success or failure of the project. Whatever the team does must fit the context. Things like the platform, security, legal requirements, existing assets, existing capabilities and a host of other contextual factors affect the Solution. And there’s only one way to discover what the context is – Elicitation and Collaboration.
One could take the view that “Need” would refer to “why do we need this change.” That would be an incomplete view of what Need means to Elicitation and Collaboration. A better understanding would include every aspect needed for the change to be successful. That would include everything from process redesign, to resources, to systems design and implementations and more, in the detail that defines the Need, or requirement, completely. So, the Core Concept of “Need” forms the backbone of the requirements that we are attempting to identify and define. This is tied closely to “Change” in that one could say that the collection of all the identified Needs are required to enable the Change to become a reality. To make the point a little more directly as it relates to the Knowledge Area, Elicitation and Collaboration is not complete until all of the Needs have been fully defined.
The focus of this Knowledge Area is to collect the information, to translate into ideas, refining those ideas into requirements, finally communicating and confirming those requirements into the Solution. We started with the desire for a “Change” – which could be viewed as a response to a business need (or high-level requirement). The Solution is the end goal – it answers, “What are we going to do about it?” Any solution which was not derived from a full understanding of all of the other Core Concepts will be incomplete. So, Solution is the output of Elicitation and Collaboration.
If the goal was to help
the disabled live in their homes in a self-sufficient manner, including
enabling them to maintain their yards, one part of the solution could be a self-driving,
solar-powered, mulching, edging and trimming mower.
Yes, I had to find a
way to re-use that product. But this isn’t a complete solution to the stated
need. All analogies have their breaking point.
One of the primary sources for information on the Needs for this Change, the Stakeholders are the ones who must sign-off on the requirements, as well as on the final product. As such, it is necessary to gather their thoughts, concerns, and insights. It is also important to collect what will satisfy them, that the proposed solution is the one which will meet their expectations and needs.
Through Elicitation and Collaboration, consultation with various stakeholders will help to define “Value” for the change. Defining Value doesn’t just stop at determining what is relevant to the stakeholders. It involves understanding how value relates to the change as a whole. And it also involves using the Value of the proposed solution as a benchmark measure of the success or shortfall of the implementation. In other words, Value determines whether the Solution is the right one, whether it meets expectations, and whether it was implemented in the right way. Without Elicitation and Collaboration, the analysis would have no actionable guide for this.
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.