Better, faster, cheaper decisions and justification
Making good decisions when there are many factors involved can be hard, slow, and complicated to justify. The is all the worse when the decision has high value, involves more than a few people, and has to be done in a relatively short time frame.
In many large enterprises, group decision-making involves from 5-20 people who end up meeting for an hour a week over a period of months to come to a resolution. And worse than that, the decision often involves only a few tens or hundreds of thousands of dollars. Do the calculation: 10 people meeting for 1 hour a week for 10 weeks comes to 100 hours of effort. For relatively high level people in the US, their time comes to about $125/hour, so 100 hours costs $12,500. So they spend $12K for a $10K decision. It might be better to just buy whatever it is and pay the $10K than to make the decision to not buy it.
Justification
The literature on decision making has historically indicated that justification of decisions consumes more than 50% of the effort associated with those decisions. The so-called rational decision-making processes we often see detailed in decision support articles and technologies are, in many cases, really just ways to justify the decisions already made. By choosing the metrics we use and the questions we ask, we can get the answers we want from the providers we like, and use that to prove our decision was good.
In corporate environments, the documentation associated with decisions often becomes a driver for major parts of the effort. For liability reasons, documentation is often minimize so as to not provide evidence of the basis for a decision. In this approach, the reasons for a decision can be detailed if necessary when the time comes, and the lack of contemporaneous notes leads to a lack of evidence for any rational other than the post-hoc rational at the time of litigation.
However, in many cases, there is plenty of documentation leading up to the decision, including internal memos, emails, chats, and other records that lead to liability because they are never explained in terms of the actual decision. Internal justifications are often provided at many levels, even if not at the top level.
I am not a lawyer, but as I understand it, there is a duty of care...
The claim "nobody could have known..." or "we didn't know..." is readily countered if there is evidence that the party in fact knew, and this is where internal documentation justifying decisions (such as whether to add a safety feature or not) comes in.
Making and justifying decisions
There are two very different approaches to decision-making that are widely used. One is where you conceal the nature of decisions and obscure them for potential future purposes, and the other where you seek to document your decisions and make them transparent and reviewable. I lean toward transparent and explainable.
One of the results of this is that when I undertake due diligence, I expect the CEO of a company to be able to explain what they did and do, how and why, and to be able to explain it relatively quickly and clearly. But that takes a good deal of time and attention, and it may gum up the work of too much time and effort is spent on this effort.
How do you efficiently make and justify and document complex decisions?
I have started to embrace the use of some forms of generative AI to aide in this effort. And this article represents an example of how I have been doing this with the Decider tool we use for this purpose.
The first step is to write down the purpose of the decision. What are you deciding? I prefer short simple descriptions. In essence notes rather than complete paragraphs and sentences. And that feeds into my approach. Here is an example:
Because the output will look something like this:
{"Network Bandwidth Requirements": "The expected data transfer rates and volume required by the factory's operations, impacting router and switch selection.",
"Scalability": "The ability of the network equipment to expand and support increased load or additional devices over time.",
"Reliability and Uptime": "The expected dependability of the equipment, as any downtime could disrupt factory operations.",
"Latency Requirements": "The acceptable delay in data transmission, which is critical for real-time applications in industrial settings.",
"Redundancy": "Equipment features that support failover and redundancy to ensure continuous operation in case of hardware failure.",
"Vendor Reputation": "The manufacturer's reputation for quality, customer support, and durability, influencing trust in the product.",
"Total Cost of Ownership": "The combined cost of purchasing, installing, maintaining, and operating the equipment over its lifecycle.",
"Power Consumption": "The energy efficiency of the equipment, which affects operational costs and environmental considerations.",
"Space Requirements": "Physical space needed for installation, especially important if rack or cabinet space is limited.",
"Compatibility with Existing Infrastructure": "The ability of new equipment to integrate seamlessly with current network systems and devices.",
"Management and Monitoring Tools": "Availability of software tools for monitoring network performance, configuring devices, and troubleshooting.",
"Security Features": "Built-in security measures like firewalls, encryption, and access control to protect against cyber threats.",
"Quality of Service (QoS) Capabilities": "The equipment's ability to prioritize critical traffic, ensuring optimal performance for essential applications.",
"Vendor Support and Service Level Agreements": "The level of technical support available from the vendor, including response times and resolution commitments.",
"Firmware and Software Updates": "Availability and frequency of firmware/software updates to keep the equipment secure and functional.",
"Lifecycle and End-of-Support": "Expected lifespan of the equipment and when vendor support will end, which affects future maintenance plans.",
"Initial Deployment and Configuration Complexity": "Ease of installation and initial setup, impacting deployment timelines and resource requirements.",
"Resilience to Industrial Environment": "The equipment's durability in potentially harsh factory environments, like resistance to dust, temperature variations, or vibration. "Interoperability Standards": "Compliance with industry standards (e.g., IEEE) to ensure compatibility and integration with other devices.",
"Warranty and Replacement Policy": "The warranty duration and terms of replacement in case of equipment failure.",
"Latency and Throughput Requirements": "The need for fast data processing, particularly for time-sensitive applications in the factory.",
"Port Density": "The number of ports available, which affects the number of devices that can connect to the network.",
"Load Balancing": "Ability to distribute network traffic evenly to prevent bottlenecks and maintain performance.",
"Budget Constraints": "Financial limitations that may restrict which equipment options are feasible.",
"Lead Time for Delivery": "The time required for the equipment to be delivered, impacting project timelines and readiness."
}
Now that the LLM has created some initial reasonable information, I can add additional factors, remove ones I don;t like, and edit the details for the purposes of my use. But it's important to note that I just took about 10 minutes to do what used to be an hour of work.
From there, I can resort the items ranking them by importance. I usually do this with a group of folks working on the effort so we can discuss it. And they can also add or change factors along the way. We do it in an online meeting, and once we are done, we have resolved this part of the decision-making process. For more complex situations, we let everyone sort them their own way after we have the list of everyone's factors and explanations. If we end up with 50 of them, that's fine. Because after we bring them all together sorted by each individual, we then combine them to do a voted version of importance. Everyone can keep their own view, and I will use the combined view. That way, they can look at the results from their own perspective and see how it looks to them as opposed to others.
Next we find the facts about how the products operate with respect to the factors. We can ask the vendors to fill out a form, or we can look it up on the Web for the first shot at it. The important part is that we put the information into the decision tool and rate the different factors by how favorable they are with regard to the situation at hand. These are not perfect numerical answers, they are initial judgments based on the factors and the tools at option. Each one will end up with a picture that looks something like this:
In this case, once we have the data, the comparison takes a few seconds.
What we see here is made up example, but what is clear is that out of about 20 alternatives, about 5 of them are worth more detailed review. In most real cases, there are 2 or 3 final candidates. But one way or another, we have eliminated the vast majority of options quickly.
Depending on the situation we might test the best ones, do a more detailed review, or whatever process we wish to differentiate the final options. But it's important to note that up to this point it usually takes less than a week and only perhaps 1 or 2 group meetings. That's for a group of 10-20 participants deciding on a purchase.
The result of the drill-down will be an updated version with only the few remaining candidates and more specific information on them. The notes taken along the way will not be lost in the process either. And that's important for the next step.
The decision is ultimately up to the people in charge, but to help them along the way, the system can provide details explanations of why to select which ones and comparative rankings in graphical output form. This is done by generating a prompt for a large language model to go an explain the reasons behind the decision made and the alternatives.
When it comes to making up sensible sounding justifications, very few things can beat modern LLM. The too generates the prompt, and the LLM of your choice generates the full text explanation, along with an introduction and summary. but BE CAREFUL. Read the output, edit it to make it factually accurate, and then format it to make it look good for the boss. This takes less than an hour, most of it spent in checking the results for sensibility and formatting to your company standard. Doing this manually usually takes at least a day or so.
This comes with pictures and arrows and numbers, and so forth. But really, it's just the same thing you would do otherwise in way less time and effort and usually with better results.
Do I really recommend and use this?
I do indeed. It's not as good as spending a month of effort for a team of 20 people. But for most decisions, it is better, and the results are satisficing. More importantly, the justification process, which takes most of the time in most cases, is faster and usually a bit better than I would get from any but the best experts out there. And that goes to the cost of decision-making and justification.
More information?
If you want more details, join us on our monthly free advisory call, usually at 0900 Pacific time on the 1st Thursday of the month:
and we will be happy to answer any of your questions.
In summary
Better, faster, cheaper decisions and justification - better life through automation.
Copyright(c) Fred Cohen, 2024 - All Rights Reserved