New Enterprise Decision-Making - Dealing with Uncertainty

A few years ago I was asked by the CIO of a company I was working for if we should invest in a particular technology or not. When I answered “probably we should”, he asked me what was required for me to be 100% sure. “Well”, I said, “I will be sure that was the right call after we implement it and are using it successfully for several years”. Suffice to say the answer was not well received,  the organization at that moment in time, was neither tolerant of uncertainty, nor was I able to objectively classify the degree to which that particular selection was better than the alternatives.
I asked myself: “How can I prevent these situations in the future?”

To answer that I needed to understand what forces are in play when making a decision based on incomplete information.

Autonomy and Decision

In an era where autonomous teams are the norm and something that most organizations are pursuing, the boundaries where  decisions can be made within teams need to be defined.

In my opinion, teams should be able to make decisions autonomously as long as:

• The decision only affects that teams’ own scope;
• There is no unnecessary duplication of capabilities or created (if another team is using a tool that fulfills the requirements, then there might not be a justification to introduce another new tool);
• There are no noticeable financial implications (this includes not only licenses but also operational costs, infrastructure, etc. ).

Should the constraints above be exceeded, then the decision should not be taken autonomously but instead as a group. 

Uncertainty Factors

Experience has shown me that the following factors affect an organization’s uncertainty tolerance:

A - Past unknowns

Past unknowns try to capture how accurate initial historical assessments have been and the degree to which they have been off-target. This may sound like a contradiction of agile methodologies, but in fact, it is just a measure of accuracy and nothing else. I’ve been in situations where a decision taken is faced with new facts that fundamentally questioned the validity of the decision. If this sounds familiar to you, then you must factor this in. Please also consider the experience of the people involved in the process as these sorts of estimations are as much an art as a science. The more experience they have with a topic the less likely unknowns will arise.

B - Market instability

The usual geopolitical and macroeconomic factors must be taken into account here. Please also factor in  direct competitors and market disruptors (if any).

C - Internal Politics

Decision making is heavily hampered by internal politics, since failure may lead to a loss in the strength of individuals and departments. You need to be aware of these limitations and be prepared to act on them. If the domain that the decision is going to affect is under scrutiny due to recent and relevant failures, then certainty needs are likely to be higher than if the domain had recently risen to resolving a particularly important challenge. On the other hand, if the department has a new leader, it may be more open to experiments and be willing to try out new things. Most of the companies that are shareholder-centric are risk averse and require special attention when dealing with uncertainty.

D - Company Inertia

Typically higher in older companies, company Inertia has a lot to do with the type of organization and the type of industry in which the company operates. Traditional industries have typically more inertia, while a startup has low inertia. Inertia is also affected by legislation and regulation. The more regulated an industry is (like banking) the more inertia there will be.

Calculation

All of these factors influence the tolerance for uncertainty that an organization will bear as part of decision making. By capturing these elements, we can calculate the % of uncertainty that an organization can tolerate. 

For simplicity, I tend to apply a simple scale of 0 to 20 for each element, where 20 is less tolerant of uncertainty and then sum them up (adding 20 as a base certainty requirement) giving me the % of required certainty.

Current organization required certainty (CORC)= (20+A+B+C+D)%

The higher the result, the more need for certainty and the lower tolerance of uncertainty there will be.

Example

Let’s say that we are employed by a retailer in the Netherlands and are part of an online unit and we just failed to meet our growth targets, whilst the rest of the organization achieved them. The CORC Calculation would be something like:

A = 15 (a so-so result in growth targets)

B = 5 (the market is actually quite stable)

C = 20 (the department is under scrutiny)

D = 15 (because it’s a traditional retailer)

CORC = 20 + 15 + 5 + 20 + 15 = 75%

This result represents an average degree of uncertainty tolerance. In a startup, you would normally find a lower value, mostly influenced by the lack of internal politics and company inertia. In a government organization, you would find it higher value for opposite reasons.

A very high result does not necessary materialize into a very high need for certainty before making your decision, since there is another critical element that influences the need for certainty, that element is scope.

Scope

There are three crucial factors to take into account when defining the certainty level required for a decision to be taken. The scope in terms of breath of the decision; the scope in terms of time to live of the decision; and the financial scope of the decision.

A decision that affects a small area of the organization for a short time with a need for modest investment is naturally a decision that can tolerate more uncertainty than one that affects multiple areas, has a longer time to live or a higher financial impact. 

Again for the sake of simplicity we just apply the following calculation:

1. Breath of the decision factor = number of resources or people affected by the decision / total number of resources or people available (where resources can be servers, applications, services, etc. depending on the decision topic).
2. Financial factor = TCO / yearly budget on Capex
3. Time to Live factor = number of years the decision will have effect / X (where X is the age of the oldest assets still in use ))

The total value of “scope” of a decision is then the simple sum of these individual factors.

Scope factor = i + ii + (iii/2)

Please note that the time to live factor is, in my opinion, the least relevant, and therefore I have reduced its weight by half.

Example

Continuing with the previous example, the decision is to potentially move the customer-facing servers to a cloud provider, keep them in the retailer’s data center that requires an upgrade, or adopt a hybrid model where some components will be moved to the cloud and other will remain on-prem. Making up some numbers, let’s say that we are talking about 20 VM’s on a universe of 100 VM’s, that the TCO is 400k, the budget in infrastructure is 1M and that the Time to Live is 3 years while the oldest server we have is 6 years.

1. Breath of the decision factor = 20 / 100
2. Financial factor = 400 / 1000
3. Time to Live factor = (3 years / 6 years) / 2

Scope factor = 0.2 + 0.4 + (0.5/2)= 85%

Certainty required

Now we can calculate the certainty needed to take a particular decision by finding the average of the CORC and the Scope factor:

Certainty required = Average (CORC, Scope Factor)

Example

Certainty required = Average (75%, 85%) = 80%

Evaluating the options

Since we are trying to make a decision, that must mean there are options to consider (even if the options are to do something or to do nothing). Simon Sinek once stated, “There is no decision that we can make that doesn't come with some sort of balance or sacrifice.”

The best way to go about evaluating the options is to identify the set of parameters you can use to compare them. Here you will have two alternatives: 

• A direct comparison between the options. Things like:
  • Comparable performance
  • Feature coverage
  • Option Risk
  • Synergies with other things in place
  • Costs and effort to realize
  • External dependencies 
  • An overall business case of the option
  • etc.
• An abstract evaluation towards the enterprise vision/strategy. Things like:
  • Maximize benefit to the enterprise
  • Business Continuity
  • Adaptable and independent components
  • Secure and compliant by design
  • Data Driven
  • Limit duplication and technical diversity
  • Ease-of-Use
  • etc.

No matter how you choose to evaluate the options, you and your team should assign a value from 1 to 10 for each parameter (where 10 is the best). 

You should avoid binary situations where there are only two (often opposing) options. Try to have three options to evaluate as that will likely break up any polarization of viewpoints.

Setup the evaluation group

If you evaluate the parameters by yourself, your subjectivity, bias, preferences etc. will influence the decision. If this is not mitigated you risk making the wrong decision, to avoid that, gather input from other individuals. Setup evaluation meetings with the working group, debate the options and all their parameters, letting everyone express their point of view (time-boxed for efficiency). Note that you are not looking for consensus, nor to convince people of a certain benefit or pitfall. All you are doing is making sure that everyone is aware of each other’s points of view, the arguments and crucially ensuring you have more input than just your own. 

You should aim to have representatives from all of the teams that will need to interact with the outcome of the options you are evaluating (developers, managers, operations, etc.). Please avoid having people involved that will not be directly involved in the implementation and operations of the option. Also avoid having a “top-heavy” group where you have an over-representation of managers.

Once you have covered all the parameters for all the options, simply let each person cast their rate for each parameter and option (again 1 to 10 where 10 is the best). Keep it simple, distribute pre-prepared sheets with the options and parameters and let each put the rate on each cell (more often than not, post-it’s work just fine).

By summing all these, you will get the option score.

One extremely important element that you should not neglect (at least on high scope decisions) is to document and make transparent the results of your evaluation and decision. I would nevertheless keep the personal scorings anonymized, but captured, so in the future, when someone wishes to question the decision, you know who was involved and the result of the scoring.

Example

Let’s assume there were 5 people in the working group and that you had 5 parameters to measure:

Making the decision

Now that we have the Certainty required and the options score, all we need to do is to multiply the best scoring option by the Certainty required. If the result of that calculation is higher than the score of the 2nd better-scored option, you have a decision outcome. Otherwise, you have not been able to provide the necessary degree of certainty to make that particular decision, at that particular moment of the organization.

Example

Certainty required = Average (75%, 85%) = 80%

Score of best Option * Certainty required > Score on 2nd best option

182 * 80% > 142 

145,6 >142 - decision taken.

Resolving uncertain results

If you find yourself in an uncertain situation, you will need to:

• Change the Current organization required certainty (CORC). This is very difficult to do but can be achieved by either addressing internal politics or waiting for an improvement in the market stability.
• Reducing the scope factor: either by reducing the breadth, time or effort you will reduce the scope factor, making the Certainty Required decrease.
• Add more parameters to the evaluation: if the evaluation results are too close, it will make the decision making difficult. You can address that by adding parameters to the evaluation that will increase the gap between the scores of the options.

Follow up

When a decision is made it does not become the past. Quite the opposite, this is the time to keep an eye on it. This should be done in order to:

• Enable course correction as soon as possible in case new findings that challenge the decision.
• Improve the decision process by adjusting the factors or adding new ones, etc.

Even after the decision is implemented, there are lessons that can be learned and applied. Do not neglect to revisit them.

With big decisions, consider having re-evaluation points (perhaps every year or every 6 months). Revisit the decision and include any new insights that have been acquired, for example new market trends, new technologies, etc..

Final Notes

Decision making is by nature, subjective. It is based on the knowledge available to those evaluating the options at a specific point in time. By applying this method (or similar) you should be able to abstract individual subjectivity and bias by diluting it, allowing you to make quantifiable evaluations that are adaptable to the scope of the decision. 

One other thing: keep it simple. If the scope of the decision is small, please consider the overhead that even a simple method like this will bring. In my experience, a small scope decision, as long as properly documented and communicated, is usually ok, while a big scope decision, requires the involvement of several stakeholders that have different objectives, making this method a valuable tool.

About the Author

Alex da Costa is currentlyworking at RTL Netherlands as an Enterprise Architect. Formore than 18 years, Alex has been leading the formulation of technology strategy, solution design and software implementation for multiple large-scale operators in diverse sectors.