IIBA IIBA-AAC – Initiative horizon

1. BA role on initiative horizon

So you have finished with this strategic horizon. Well done. Now let us move on to the initiative horizon where a lot of fun happens. The purpose of analysis at the initiative horizon is to inform decisions regarding solution options, features, priorities and lifestyle. That’s the definition from the agile extension to the Bible guide. Essentially, business analysis at the initiative horizon. Horizon is concerned with defining and delivering a solution that satisfies a need identified at the strategic horizon. So what are some of the expectations from a business analyst? First of all, to use business priorities to define these solution options, second, to help scope initiatives, and third, to use feedback to identify if the solution is producing the anticipated outcome. In a nutshell, that’s the scope of expectations from aba on an initiative horizon.

Let’s have a closer look. From your strategic horizon, you would have identified your prioritized needs that you need to satisfy. These needs are used as an input to your initiative horizon. The key goal of analysis on this horizon is to help deliver a solution in a way that minimizes output but maximizes outcome. As such, analysis on this horizon helps the business to answer the following questions what solution options satisfy the need? Which solution option appears to provide the maximum outcome with the minimum output and fits within the given constraints? What are the solution components as described by features of the preferred solution option? What features should be delivered now, next and later in the future? Has enough value been delivered to satisfy the need? And based on ongoing feedback and learning, should this solution continue, change or be canceled?

2. Elements of the initiative horizon

Most solutions that we are talking about are complex enough that there are multiple solution options that can deliver the same result to the business. It is the art of analysis to decide which one is better and choose the proper one. More than that, each solution will consist of multiple solution components, sometimes referred to as features of this solution. These are all the elements of the initiative horizon. So let’s have a look. The first one is to identify solution options. That’s one of the first things you do on the initiative horizon.

Then you go into recommending solution options based on your analysis, which one of the identified options might be better and why. Then you go into identifying solution components. What are the features that constitute your solution? Then you go into prioritizing of the solution components. Which of the features identified need to be delivered first and why? Then you go into determining if the need is satisfied. Every time you introduce a solution, you introduce it in response to a business need. So it is important to keep track whether your solutions actually satisfy the need sitting behind them. And finally, ongoing assessment of viability going forward, is your solution still a viable option?

Now let’s have a closer look at the elements. The first one is to identify solution options which are worth considering for implementation. The multitude of options allows the team to analyze each one to determine whether it is viable or not. The team needs to have a shared understanding of both the need to be satisfied and the desired outcome to be achieved in order to do this efficiently. This includes having clear and measurable objectives because those objectives will be used to do an initial viability assessment of your solution options. There are a couple of things to consider. First of all, make sure that the team has shared understanding of the need. Understand what are the assumptions made about a solution being viable? What makes your solution viable? Consider the known risks. Try to identify new risks in the process. Have a broad description of all the solution options so you can present it to the team and compare and understand your constraints.

What is the landscape that you are working with and what are the things that you cannot change? This process, by the nature of it includes the discovery of previously unknown information to land on the solution options worth considering. The next one is recommend the solution options based on which solution option provides the maximum outcome with the minimum output and fits within identifying constraints. The business analysis role here is usually advisory, which means you are not the decision maker in the process, but rather you are the person who provides all the data for the decision makers to do their job. These are the steps for recommending solution options. You start with validating any assumptions. Then you identify the methods of assessing the implementation practicality.

Once the methods are identified, you consider the information about the people, processes, tools, organizations, systems, vendors, any other external entities that are impacted by the solution to identify potential conflicts or risks. After that, you assess the solution’s projected impact on the identified need. Then you estimate the cost of each solution option in terms of time, money or any other resource relevant for the team. Finally, you consider experimentation, whether you need to run a controlled experiment to identify which solution option would work better.

The next element is identifying solution components. Solutions will be composed of multiple components and some teams call them as features. This is how you do it. First, each identified component will be evaluated in the context of the desired outcome, costs, impacts and constraints. This will create a list of components which could be used to develop the selected solution option. Essentially, this is how you create your first version of the backlog. And then when you analyze the details of those components, you add more details to the backlog.

Identifying and clarifying the solution components is an ongoing iterative process. You don’t do it in one go. You start with baseline, then you look at it again, you reiterate you iterate again. And as you start delivering things, you are revisiting the items remaining in the backlog. Once the potential solution components are identified, you will prioritize and sequence the backlog. This is often called backlog refinement. The decision maker responsible for this solution generally makes the decisions on the priorities. This person is often called the product owner. So what do we need to consider when prioritizing solution components? First, the impact that each solution component has on the overall odd outcome.

The cost either actual or in terms of team capacity in implementing the solution component, the current state of the initiative, the feedback that you receive from the stakeholders, the current performance towards the desired outcome, and finally, the current understanding of the constraints and risks. All these elements need to be taken into account to make an informed decision about the priority of elements of your backlog. This process is an ongoing process. It doesn’t happen once. It happens throughout the whole initiative.

To determine if the need is satisfied, you assess if the outputs delivered meet the desired outcome. This is validation process, not verification process of the solution. So you do not compare the solution against your specification or set of features. You compare it against the need that was the cause for the initiative to start, whether the solution as a whole is fit for purpose. So how do you do it? First of all, you do it every time a solution component has been delivered and feedback has been received. You need to analyze this feedback when you receive it, not wait till the end to collect all of the feedback for all of the entire heavy backlog.

This process reduces the risk of producing more output than necessary to meet the need, so it reduces waste. Once the desired outcome is achieved, efforts can be shifted to meeting the next identified need. If the desired outcome has not been met, you need to consider whether you want to continue this initiative, change it, or maybe cancel it altogether. It is expected that you will continuously assess the solution to understand if it is delivering the desired outcomes and sufficient value or not.

You need to base your judgment on the identified measures of success as well as the feedback that you receive from your stakeholders and end users. If the answer is yes, you will need to continue to refine and deliver solution components as previously planned. If at any moment in time the answer becomes no, you need to change the solution by adding or removing solution components or changing the priority and sequencing of solution components. Alternatively, you may recommend to cancel the initiative so that the resources can be redeployed is more efficiently.

3. Time frame of the initiative horizon

Compared to strategic or delivery horizons. The initiative horizon looks into the midterm future. But what midterm means will depend on your organization and your context. At the initiative horizon, the time frame is scoped by answers to these three simple questions what outcomes are we driving right now? What outcomes will we be addressing next? And what outcomes will we be addressing in the future? Basically, the initiative horizon is operating in terms of outcomes.

It looks at what outcomes you work on right now, and then it looks for one or two steps in future. It doesn’t go beyond that. This is when your strategic thinking comes into play and it doesn’t operate in terms of immediate features, functions, and deliverables. It talks in terms of outcomes, in terms of needs that are being satisfied right now because the rest of it is looked after. On the delivery horizon.