Category: Business Analysis

Announcing – AAC Certification Course on Udemy

Announcing – AAC Certification Course on Udemy

Hello everyone,
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.


Letting Go

Letting Go

During the last week, it seems that everywhere I go, I am running into a constant theme. People around me are letting go. And letting go is one of the most challenging things we do as humans.

My family is in the process of decluttering over a decade’s worth of stuff, and I see first hand how some of these items evoke strong emotions. Take the exersaucer, for example, that was used by my daughter, who is now 5ft 9in. As wonderful as that time in our lives was, we can never return to it. The stations on each side are housed in a white plastic casing that now has changed colors to a light tan.

I jokingly asked Lily if she wanted to give it one last turn. Of course, I got the response, “Dad, that sounds pretty shady to me.” That is her way of saying, stop with the Dad jokes.

It’s not just my household, though. My Mother has the loss of her furry companion; a Yorkie named King who passed at the age of 84 in dog years, 12 in actual years.

And there have been others I’ve helped within the last week, too.

I’ve learned that the challenge of letting go involves some level of the grieving process. It doesn’t matter if the letting go is from a tragic loss, or just from the passage of time and how life causes transitions, grief is often involved, though we may downplay its significance.

Life’s Transitions

So how do we make the transition?

If that question is asked too soon, it can be jarring. The stages of grief should not be circumvented for significant life events. And each stage likes to return to visit us often.

So, I will ask the question again, with that as a caveat. Knowing that change often invokes grief, how do we make the transition?

First, we need to see if we are ready to make the transition. If we are not ready for the transition, we will never accept it. And acceptance is vital because we often need to take action over and over again for a change to take hold.

In my decluttering example, it isn’t just the exersaucer that we need to let go. It’s clothing, bedding, toys, artwork, crafts, and a thousand other items. And it’s not just things involving my daughter.

For me, it’s books. Many of which I intended to read but never did. And now that season of my life when I should have read them is past. They are no longer relevant or timely. As I’ve gone through boxes of stuff that have not been opened since our last move 7 years ago, it is surprising how many books I have that I don’t even recognize, and many must have been from before we married. A good portion of which are of the self-help variety – so much that one visitor looked at my shelves and asked, “What’s wrong with you?”

My reply, “You mean you can’t tell?” Followed by a psychotic laugh, just to see the effect.

One of the books I found was “Who Moved My Cheese,” which is a book that is about … you guessed it … Letting Go. Can you guess what I did with that book?

Yep, it’s been donated.

For my wife, it’s things she remembers from shopping experiences with our daughter. Every so often, I hear the exclamation, “Lily! You’ll never guess what I found. Do you remember…?” Then she tells a story about something she hasn’t seen in years, and suddenly we must keep it.

This makes little sense to my logical mind. But I conclude that Marie Kondo doesn’t work when everything “Sparks Joy.” That and the books explains our storage unit.

Still, no matter what the circumstances, letting go is a necessity. Our ability to let go is directly related to our ability to excel in life. Why? Because letting go of the past is necessary for us to envision a future.

And for myself, letting go involves more than just clutter. Every so often, it is important to take a risk, to change course. And this pandemic seems like the natural time to do that.

The Point

As Business Analysts, we often speak of techniques and skill-sets involved to identify process gaps, requirements management, and the like. There is another part of the job that requires empathy, and empathy is a core part of leadership.

Whether it is letting go of the clutter in our lives, painful events, or letting go of what we have done to move toward a better future, letting go is difficult.

As a business analyst, one of my roles is as an “agent of change.” That means some people love seeing me come because they know things will get better. But others are not ready for change. They don’t see the vision or don’t like the vision they see. For these situations, often reminding of the drawbacks of staying put can help soften the resistance.

But no matter where someone is on willingness to let go, it can always be said that letting go is a necessity for moving ahead. And my job is not just to gather requirements on a product vision; it is to create as smooth a transition as possible. The emotional intelligence of handling change is a huge part of getting a project done.

My job is to help them

It may mean that the vision gets adjusted to embrace the concerns of a group that was overlooked. Great – I’ll pass these changes along and get approval.

It may mean that I need to help people see a vision other than what they know. That’s great too. I can help lower the level of fear involved with change by highlighting the benefits, not only to the organization but to the individuals affected.

What do I do to help? The main thing is to listen. Once the problem is voiced, the fear of it lessens.

I’m very thankful for this past week because it reminds me again just how important it is to help people move toward what is next.

And the real reason I have all those self-help books that I mentioned earlier is because in reality they are more useful professionally than many people realize.

We Are Neo

We Are Neo

Recently I was talking with someone who is transitioning into Business Analysis. One of the things we talked about is “What other job do you know where you get paid to learn from experts.” Our endless curiosity is met by an endless supply of industries, sectors, changing demands, new technologies, and on and on.

There is another side to that. With that endless curiosity comes an endless demand for applying what we learn – and sometimes for what we have not yet learned. Even for seasoned Business Analyst, there are tools and techniques that we’ve heard of but have not personally used.

And that creates a situation where…

We Are Neo

Who told Neo he could stop bullets?
Who told Neo he could stop bullets?

For example, let’s say a client needs to start embracing Agile but is struggling with a history of deciding everything before the project starts. As an Analyst, you may have worked on many Agile projects, and it’s second nature to you that some questions are not ready to be answered yet.

You do some research in the Agile Extension to the Babok Guide and discover a technique called “Real Options.” But you’ve not used this technique yourself.

What do you do?

You sit in the chair had have one of your Ebenezzer crew-mates plug you in to the “Real Options” program. A few minutes later, you know the pros, cons and concepts associated with using this technique.

Actually, that often is not as far off as it sounds. Oh, we don’t have a portal to plug into the Matrix. But we do have tons of articles, books, blogs and videos we can search.

The Choice Between Two Mindsets.

There’s a couple of ways you can look at what I just described. The first way is through the lens of “Imposter.” How can I claim to be something I’m not? They will see right through me.

The other way is through the lens of “Owner.” If I don’t do this, no one else can or will. Let’s try this and see if it works. If it doesn’t, we’re no worse off than we are now. And this stretches my wings as a leader for our organization.

To move forward we have a mindset that it doesn’t matter if I know it already or not. It’s my job to find the answers, not to have them already. So let’s go.

Consider this famous quote from Richard Branson:

If somebody offers you an amazing opportunity but you are not sure you can do it, say yes – then learn how to do it later!

— Richard Branson

There is a difference between this quote and what I’m describing. It isn’t always just presented to us. As Business Analysts, it is often presented BY us.

Goals of Agile Analysis at the Delivery Horizon

Coming into Delivery, the Strategy has identified a need to be met, and the Initiative Horizon has identified a solution and its features. When working as an Analyst in the Delivery horizon, the key is to expend the least effort to discover information and support informed decisions about the solution.

I’m sure you realize it is not easy.  It requires a great understanding of what information is useful for decisions on the solution, as well as how to find quickly, and present it in a timely, understandable fashion.

Someone introduced me to the concept of “Planned Spontaneity”  That is where the person has things set up so that if they want to go on various kinds of excursions, they always have bags and supplies packed and ready to go. It takes a lot of planning to be spontaneous. Or, as Rod Stewart used to sing, “Her adlibbed lines were well-rehearsed.”

So when this “Challenge” involves the least amount of effort, I think that also consists of a lot of planning to make it happen, so that the work at the time it’s needed is minimal. To do this, the Delivery horizon addresses two questions. First, looking at the unfinished but defined backlog, the Analyst asks what has the highest value. Then the delivery team asks how to deliver value most efficiently, with the least waste.

A Ready Backlog

Agile Extension to the BABOK®  Guide – section 6.3.1

In the Agile Extension, there is a discussion of how to know when a requirement is ready, as well as when do you need to have it available.  On the first of these questions, the Extension talks about “Invest” criteria.  For now, we’ll say Invest stands for “Independent, Negotiable, Valuable, Estimable, Sized Appropriately and Testable.” I intend to get to the techniques later and will elaborate more at that time.

Whether you are talking about User Stories or other formats for requirements documentation, the INVEST criteria work well.  The point is that the requirement is well constructed with Clear and Concise acceptance criteria and is achievable and Desired as shown in Prioritization

For the second question, sometimes the requirements should wait and be ready in the near future. Agile suggests having things prepared for near term development. If something has to wait, then having it ready now is wasted effort, which takes away from the closer requirements.

Additionally, some frameworks offer suggestions for how far ahead to finalize requirements, so that you don’t rewrite the requirements as better understanding surfaces.

Prioritization and Sequencing

Agile Extension to the BABOK®  Guide – section 6.3.2

The next element of the Delivery Horizon is Maintaining the Backlog. Here we work with the Product Owner to Set priority and sequence to deliver value quickly. The purpose is to support near term development, and the outputs are decomposed features and refined requirements.

Supporting Delivery

Agile Extension to the BABOK®  Guide – section 6.3.3

The Agile Analyst’s efforts prevent obstacles in several different ways, such as facilitating a better understanding of dependencies, coordinating efforts with other groups, and removing roadblocks.

How do Analysts remove Roadblocks?

This question requires an understanding of the Analyst’s role versus other leadership roles on the team. Then, within the Analyst role, what are the roadblocks that can occur.

The first one is a lack of understanding. If the team does not understand, it will cause churn or will prevent the story from being worked.

Another is the interrelationship between features internal to the solution.  Without these interrelationships being understood so that proper sequencing can occur, you may be trying to develop against something that doesn’t exist.  So when it’s delivered, there’s no way to know if it works.  Remember, we’re delivering working software.

Another is external dependencies, which are much like what was just discussed.

Ensure Learning Happens

Agile Extension to the BABOK®  Guide – section 6.3.4

Next, there is Ensuring Learning Happens in the Agile Context, and in this, we first are talking about Processes. By Processes, we are talking about how the team works, not how the process works, or the stakeholders will use whatever is being delivered. 

The team is observing how well they are working, and can they work better.  These observations include feedback to the Initiative or Strategy Horizons because they need to know how to help Delivery better.

The other learning involves the product itself.  Constant feedback determines whether the value is being delivered and the expected results met.  This feedback may affect prioritization and also other horizons. Here is one of the distinctions between Agile and Waterfall – that feedback from Delivery can affect the other horizons. Waterfall would say, Delivery is the result of planning, so there’s nothing that goes back in time to fix what has been done.  Perhaps that’s a bit oversimplified. The Agile Mindset recognizes this project is not performed in a vacuum.  The speed of delivery affects resource availability for other initiatives and other needs.

Focus on Vision and Value

Agile Extension to the BABOK®  Guide – section 6.3.5

Finally, there is Maintaining Focus on the Product Vision, Customer, and Value. The Agile Analyst’s work continually promotes a shared understanding of how the work achieves the vision. Focusing on value means the most valuable things are prioritized and delivered early.

Goals of Agile Analysis at the Initiative Horizon

From the Strategy Horizon, we understand the overall purpose of an initiative and its intended impact. But there is a lot that remains undetermined at this point. The initiative may have the organization’s backing, but that doesn’t define exactly how it will work, what resources are involved, or how much it will cost. The role of the Initiative Horizon is to fill in those gaps, report back to the Strategy Horizon for decisions to continue or end research, and potentially provide the requirements to the Delivery Horizon.

So, look at this in more depth.

Identify Solution Options

Agile Extension to the BABOK®  Guide – section 5.3.2

One of the primary functions of the Initiative Horizon is to identify options that can potentially meet the organizational need determined by the Strategy Horizon. Implied in this is that there are options – more than one – which have that potential.

In determining these options, a clear understanding of the Strategy Horizon’s intended purpose will have to be established. If that has not happened, the analyst will gain clarification from the decision-makers in the Strategy Horizon. To eventually bring the desired results, clear and measurable objectives are communicated and evaluated here.

We need to consider “what is the shared understanding?” and “what are we assuming?” For example, one assumption may be that there is an affordable, workable solution. The analyst will need to discover if those assumptions are correct or not. If not, then that option will cease to be considered, and that result communicated to decision-makers in the Strategy Horizon.

Other considerations include “What could cause the project to fail, a delay, or a limited function?” To address this, the analyst needs to understand from a high level, what this optional solution does, and what constraints would make it not a viable solution. For example, a vendor product may meet the need, but it may not work in our environment.

Identify Components

Agile Extension to the BABOK®  Guide – section 5.3.4

Another element of the Initiative Horizon is identifying the components needed by the stakeholders and collecting information about its effect on the need, costs, and constraints. Collect enough detail to make informed decisions without wasting effort by going too deep.

The components are something that is reviewed and revised periodically though the duration of the initiative. Also, the components may be identified for all of the options, not just the one eventually chosen. This is because part of the decision will involve which features are included and how much effort those features require.

Size of Items

To determine the size of the items requires that the components are identified. These will often be referred to as Features. Each component needs an approximate size reflecting the expected work effort involved. At this point, it is a very high-level estimate.

Prioritize Components

Agile Extension to the BABOK®  Guide – section 5.3.5

Agile Extension to the BABOK® Guide – section 5.3.5

With those components identified, we need to determine the priorities and sequence components. This will be revisited often and influenced by feedback both from Delivery and Strategy

Prioritization can be impacted by several factors, such as the impact of the feature, cost, how the project is progressing, multiple levels of feedback, and others.

Features may be prioritized for options before a specific solution is chosen because the scheduling of resources required to bring prospects to reality will need to be discussed. Schedule constraints could tip the scales of one option over another.


Agile Extension to the BABOK®  Guide – section 5.3.3

In recommending an option, a simple way of looking at it is, “Which option gives the most for the least and still meets the need and constraints?” To decide that, we don’t need to know everything, but we need to know enough. And since we’re evaluating multiple options, we need to be consistent in what we use to make the decision.

To make the recommendation, confirm that our assumptions are valid. These could be organizational assumptions or assumptions about a 3rd party entity or product. We will need to see:

  • How difficult is it to do what this option requires to get it live. 
  • Are the impacts on the organization, either intended or not intended? 
  • How well does it meet the need? 
  • How high of a price?

Determine When Need is Met

Agile Extension to the BABOK®  Guide – section 5.3.6

The role of the Initiative horizon does not stop at determining a solution. It continues while the product is being delivered to determine when the need has been met. Again though, this is based on analysis, which leads to a recommendation. The ultimate decision does not belong to the analyst, but a responsible decision-maker or decision body.

Each delivered feature is an opportunity to determine if the need is met if more is required if changes are needed or the project canceled. The intent is to avoid waste by only satisfying the need identified by the Strategy Horizon.

Assess Viability

Agile Extension to the BABOK®  Guide – section 5.3.7

Along with determining when the initiative has met the need, a counter analysis also continues concerning the initiative’s ongoing viability. By viability, that not only means whether to continue the initiative, but also whether it needs to be altered in some way.

Agile is called agile for a reason – because it is built to handle change. So we have three options: to Continue, Change, or Cancel the initiative. The basis of that assessment is several factors that constantly change, such as the realized impact, success measures or KPIs, remaining work, constraints, feedback from delivery, and strategy.

How to Avoid Delegation Through Abdication

How to Avoid Delegation Through Abdication

As I am writing this, I have recently finished a panel discussion on Agile Transformation given at my IIBA Chapter. One of the recurring themes of any discussion involving Business Analysis is stakeholder engagement. Lack of stakeholder engagement shows up in a myriad of ways ranging from indifferent behaviors to actual hostility toward anything involving an initiative. It is almost impossible to discuss without this subject surfacing.

One of the most common forms in which stakeholders are not engaged can is Delegation Through Abdication. To give credit where it is due, I am borrowing this term from Larry Hagner, who writes a blog called The Good Dad Project. I think it originated with The E Myth Revisited, by Michael Gerber.

Delegation Thru Abdication occurs when you feel overwhelmed by a subject and want to avoid it in any way possible. Perhaps you’ve been burned in some way. Or you have no vision for it. So you hand it off to someone else. Someone who really should not be responsible for the decisions, or should not be solely responsible for it. So you send representatives to do your job.

Does this sound familiar?

The problem doesn’t go away. If anything, it usually gets worse because, although the delegate may end up handling things wonderfully, the more common scenario is that they don’t. And even if they do knock it out of the park, there’s still the emotional side. You know you’ve compromised. They know you’ve compromised. They’ve lost respect for you. And you’ve lost respect for yourself.

One of the things I’ve learned in Business Analysis is that you cannot make anyone do anything they don’t want to do. The motivation must be within them to do it. But we can encourage that motivation to the surface and grow in strength.

I mentioned motivation, and that is what we need to explore. What causes the behavior? Why does this person want to avoid it?

I have often said when giving talks or teaching that Business Analysis does involve a fair amount of psychology to understand the motivations of stakeholders and help them understand their fears. Those fears represent concerns that need addressing as the project unfolds.

I find that merely asking the question “Why” often opens up the conversation to valuable input for the project. This happens in 2 ways.

The first way is to identify whether the fear is realistic or not. There’s no telling how much we worry about things that will never happen. So having someone with some objectivity to look at the concern and evaluate it can be helpful to let the person go past the fears.

The second way is through mitigation. And this truly is the point of this article in the first place – because someone was abdicating their decisions to someone else, requirements are missed. That creates a self-fulfilling prophesy – “I told you it would never work.”

Of course it doesn’t. Absence sabotaged it.

As Business Analysts, we see that stakeholder engagement is one of the most significant risk factors in project success. I believe it is as essential as the quality of the delivery team. Without that engagement, people will not be able to determine what is needed.

Whether these concerns are realistic or not, they are addressed initially by identifying them. As the saying goes, “A problem identified is half-solved.” The answer can only come once the question is asked.

So, if you want to avoid Delegation Through Abdication, start by asking, “Why do you want someone else to represent your interest?”

BACCM: Impact on Knowledge Area 6. Solution Evaluation

BACCM: Impact on Knowledge Area 6. Solution Evaluation

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.
BACCM: Impact on Knowledge Area 5. Requirements Analysis and Design Definition

BACCM: Impact on Knowledge Area 5. Requirements Analysis and Design Definition

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).

BACCM: Impact on Knowledge Area 4. Strategy Analysis

BACCM: Impact on Knowledge Area 4. Strategy Analysis

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.

BACCM: Impact on Knowledge Area 3. Requirements Life Cycle Management

BACCM: Impact on Knowledge Area 3. Requirements Life Cycle Management

According to BABOK v3, the following table represents the application of the Six Core Concepts to the Requirements Life Cycle Management Knowledge Area.

BABOK v3, Table 5.0.1: The Core Concept Model in Requirements Life Cycle Management


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). 

Many 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.


Usually, 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. 

I 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.


The 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.

BABOK v3, ch5