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