Month: January 2020

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?”

Goals of Agile Analysis at the Strategy Horizon

When an Agile Analyst is working on the Strategy Horizon for an organization, the purpose is to provide information to decision-makers that relate to organizational goals. This requires a shift in thinking from the analysis performed at other horizons. The shift is partly due to the purpose of the Strategy Horizon, and partly complexities of this early stage. With such complexity, the Agile Analyst needs to have the following in mind.

Breadth of Information

Agile Extension to the BABOK®  Guide – section 4.3

Agile Extension to the BABOK® Guide – section 4.3

I think it should be evident that the Strategy Horizon involves a broad spectrum of interests and concerns. The details are often revealed in the other horizons. However, that does not mean this Horizon is not substantive. So let’s look at the areas of concern for the Strategy Horizon.

In the Strategy Horizon, one of the first things needed is communication channels that receive and give appropriate information across the organization. Items discussed in the Strategy Horizon may affect the entire organization either directly or indirectly. Decisions and discussions may or may not involve a specific operation, but they will impact resource allocations and priorities.

Observations about market changes and trends are evaluated to determine changes in product, features, or the importance of a proposal.

From the external environment, technical or competitive advantages or disadvantages may be leveraged or mitigated appropriately. Changes in societal expectations may also affect the product, and it’s design, features, or priority.

Additionally, internal changes may affect the strategy. For example, changes in the leadership’s vision for the organization may move high prioritized items to non-starters.

Even though we are in the Strategy Horizon, the organization assesses impacts based on feedback from both the Initiative and Delivery horizons. The apparent effect is estimations and projections for projects and required resources.

These play a part in fulfilling the intended purpose of the Strategy Horizon – to prepare the organization to counter a threat or capitalize on an opportunity. Those threats and opportunities should be revealed through the items discussed previously.

Maintaining High-Level View of the Information

Agile Extension to the BABOK®  Guide – section 4.3

For those who have been heavily involved in delivery, there’s a shift in how you approach problems in the Strategy Horizon. That shift in thinking affects the level of detail. So, what level of detail should we view at Strategy?

Here are a few considerations:

  • We aren’t yet ready to get too deep in the weeds. By that, I mean specific items describing the solution. At the strategy level, we don’t care about defining the solution.
  • We are concerned about identifying potential needs. Notice, these are potential needs. They may never be actual needs. An identified risk may never happen, but we need to identify it and think about mitigation against it. An opportunity may be on the verge of appearing, but not quite come to the demand levels or cost levels to make it profitable.
  • We are clarifying the need. The solution will be dealt with in the Initiative Horizon. So, all information that tells what we are trying to accomplish, not how to achieve it, begins at the Strategy Horizon.
  • The focus is on organizational risks, changing priorities, or other conditions and identifying new needs.

Making the Complex Simple

 The ability to take complexity and make it simple is the key to effectiveness as an Analyst on the Strategy Horizon. This ability will likely drive success in the Strategy horizon.

One could ask the question, “What are the indicators which show we need to take action in this area?” Then, “How do we get the information to monitor those indicators?” It sounds like a simple set of questions. But the reality is, there is much uncertainty with the information – especially when it is based on external sources. Add to that, the level of complexity, and the quantities involved.

The Agile Business Analyst will make models to simplify the decision-making process using the information from all relevant sources.

The Three Horizons

When we think of Agile, we often think of solution delivery.

One of the things I’ve observed about IIBA is that it looks beyond the boundaries of the delivery functions. The Business Analysis certifications look before and after the project, to identify activities leading to and resulting from the project.

Agile Analysis is no different. Here, we are looking at what goes on from the very beginning of an idea, through to its delivery. So, IIBA has identified three horizons – Strategy, Initiative, and Delivery.


  • The three horizons allow the organization to have a framework for response.
  • Having multiple horizons identifies the stages and shifts in focus that occur as an initiative matures.
  • To explore the interplay between each Horizon and how they inform each other.
  • To understand a fuller impact on the organization. This gets into why we are doing things in the first place, instead of merely what are we doing.

Strategy Horizon

The Strategy Horizon takes the broadest view possible, looking at the organization as a whole. Decisions made here support organizational strategy and resource allocation. We are identifying opportunities such as products, services or initiatives, or areas of risk and ways to mitigate against those risks.

Risk at the strategy level is different than at delivery. Here we are thinking of risk to the organization, not the project. These risks can include:

  • Regulatory Changes
  • Competitive Landscape changes
  • Disruptive business models that undercut your revenue stream
  • Public Relations issues

At the Strategy level, we are concerned with the overall organizational strategy. With that kind of a view, a strategy is never talking about the immediate term. It takes time to analyze, theorize, confirm, and set a vision for an initiative. Add to that the time to deliver it.

Initiative Horizon

Moving on to the Initiative Horizon, here we become more focused on a goal, initiative, or a team.

So, when I look at this impacts list, and I see a goal vs. an initiative, there’s a distinction. At this time, the purpose has likely been identified, but the means to achieve it has not. So, there needs to be a decision process to determine the solution. That solution becomes an initiative and is further refined until a decision is made to deliver it.

Just because something is in the Initiative Horizon does not mean there is ever an intent to act on it. The same can be said about strategy. But it is a preparation and exploration horizon.

Initiative based decisions include: 

  • Identifying how to meet a goal, which becomes an initiative
  • What is desired for that initiative
  • Identifying needs and options
  • Inform both the Strategy and Delivery Horizons

Delivery Horizon

Decisions made here affect the delivery of a solution and support the delivery time and product.

Delivery also:

  • Identifies the work breakdown, delivery, test and prioritization
  • Focuses on the needs of the stakeholder

3 Planning Horizon

The point of these Horizons is that they are not purely phases or stages. An initiative is not necessarily in one to the exclusion of the others. Instead, influence is bounced between the Horizon as feedback and knowledge are continually gained.

A clearer picture is illustrated below.

Agile Extension to the BABOK®  Guide – section 3.2

As you can see, information is bi-directional. Agile brings news back to the decision-makers from the delivery team. The information exchanged between each Horizon informs the decisions made at the receiving Horizon.

With this level of exchange, the organization goes beyond delivering a solution, to practicing Agility – the application of an Agile Mindset across the organization.