Companies recognize the need to become more agile so they can respond to the accelerating pace of change and increasing levels of complexity. In Part 1 of this series, we introduced the concept and framework for a fluid prioritization model to help organizations anticipate and respond to internal and external change used to drive priorities (decision making). In the second part of the series, we explore some of the scenarios faced by organizations already overwhelmed with information and complexity so they can gain a better appreciation for the need and urgency to address these challenges while time permits.
WHY Invest in Fluid Prioritization model
The opportunities for applying a fluid prioritization model are significant and range from tactical to strategic. The model can be implemented on any scale and within any area of an organization. This is not a one size fits all approach. Rather, this is an organic solution that will scale to meet the needs of the organization. The full realization of its value will become increasingly apparent as the various data sources and algorithms mature. Over time, the model will become a core input for decision making across the organization. Gradually, the business will become increasingly agile as change (and complexity) become much easier to manage. Below are a few scenarios where an organization can apply the fluid prioritization model:
Strategic Scenarios: (subset with sample context & impacts)
Execution Scenarios: (subset with sample context & impacts)
Operational Scenarios: (subset with sample context & impacts)
Taking a deeper dive into the challenges facing organizations trying to prioritize change and direct resources as part of the continuous transformation to keep pace with accelerating change, reveals the following common hurdles:
Prioritization is typically fragmented across each organization
There is no collective understanding of impact from demand, therefore there is no way to properly prioritize responses to demand
Let’s walk through an example where prioritization exposes a few challenges associated with an event (triggering change) and a few demands resulting from the change:
Change: Fire at Notre Dame cathedral (okay, big change !)
Demand: Preserve as much of the structure as possible
Demand: Extinguish fire at quickly as possible
Response 1: Dump water from plane or helicopter on fire to extinguish fire faster
Response 2: Pour water from a few fire hoses on structure
Decision: Evaluate Pros & Cons for each option (response)
Demand is continuous, suggesting a need to apply concepts in fluid dynamics versus discrete analysis used for bounded events which can be evaluated in isolation. The dynamic nature of change is not well understood in most organizations, so changes are typically managed by separation of concerns to focus expertise on categorized sets of demand. When demand items overlap with other areas of concern, meetings are used to facilitate discussion and outline scope, boundary points, and explore options to respond.
The challenges with reliance on meetings to address points of overlap are numerous:
First, it’s not scalable. The number of people (resources) with the requisite knowledge to contribute and/or make decisions is limited.
The same people often contain domain and/or legacy (tribal) knowledge about the systems, processes, and past history around demand items and their relationships to other demand items and impact on the organization. So, they become a constraint on analysis and decision making.
Second, conducting analysis to establish root cause and/or mapping relationships across other demand items takes time and may not be possible due to the lack of formal data and metadata around each demand item (in each demand repository and/or list) across the organization.
Third, there are no consistent factors used to evaluate the impact of each demand item across most organizations, so this obfuscates any analysis performed on-demand items across the organization using discrete analytics.
Fourth, few organizations have the ability to perform impact analysis of options (responses) within the scope of the problem space for a given demand item let alone conduct the larger assessment of impact across strategy, execution, and operations.
As companies incorporate new processes, automated workflows, and processes (RPA, micro-services, and emergent processes) with a growing number of service providers (tool vendors, cloud-based services, and human resources), each decision point in these processes introduces expanding levels of complexity.
As more services are added to the mix from existing or new sources, the decisions about which service to initiate at each point become increasingly difficult. More services will be available in the open market where automated agents (bots) may actually “bid’ for the right to complete a given service (for a fee).
There are cost considerations, capacity concerns, risks that may need to be evaluated and mitigated with each decision. The expanding set of unknowns will create uncertainty, risk, and increasing levels of complexity that impact the decisions and processes, which need to be evaluated as part of an expanding prioritization model.
The number of scenarios and factors that need to be evaluated (measured) will quickly exceed conventional rules-based decision logic and IT staff will become overwhelmed with the pace of change and volume of changes required to handle the expanding set of scenarios (use cases).
Options for addressing the above challenges are not piecemeal nor are they as simple as applying some form of AI to “magically” discover how to prioritize demand. While there are many factors that appear to have more importance in triggering one or more points of causality, it is important to resist the temptation of selecting one of these factors in isolation or suggesting that “If we just solve this issue, then most of the symptoms will be addressed”. Often times analysis is based on a few known factors and decisions are made based on bias or an incomplete understanding of causality, leading to spurious results upon which key decisions may be based.
“Correlation is not Causation”
In future parts of this series of articles, we will introduce some of the design considerations for establishing a prioritization model and address a subset of the above-mentioned scenarios to help illustrate its value.