Our example with “Customer A” is demonstrated below to show how they facilitated tailoring their decision-making app – to support a consistent, quality approach aligned with their values.
Customer A built on established disaster management decision-making criteria as a springboard for their people to consider, because disaster management is characterized by the need for crucial decisions.
Customer A used an approach which engaged their people to generate their preferred decision criteria by reflecting on the set of criteria from the disaster management reference set (above).
The senior management team of Customer A then clustered “like with like” and filtered out some suggestions.The validated list was then subjected to “Pairwise Comparison”.
Note: Pairwise comparison generally is any process of comparing entities in pairs to judge which of each entity is preferred, or has a greater amount of some quantitative property, or whether or not the two entities are identical.
The Pairwise Comparison Grid
The Pairwise Comparison Outcome
Score / Weight from the Pairwise Comparison
To validate functionality, each Option was then scored against each Criterion. (For transparency and supporting evidence, a rationale can be recorded for each attributed score.)
When the scores are graphed they stimulate a conversation around the rationales for the differences.
In the process of validating Customer A’s algorithm we used only two options as this was sufficient to demonstrate functionality.
Note: In the world of real problems and opportunities, constructing a context of only two options can be limiting (although even with only two options, a thorough exploration of the decision criteria against two options may suffice). It is generally better to allow for multiple options to emerge during conversations in the decision making process.
Customer A decided to keep the structure of their plans simple (see below) as it met all of their requirements.
For Customer A, focusing on “what needs to be done” and “what is needed to do it” covered the necessary and sufficient elements to inform action. Monitoring “track, budget and time” was similarly considered adequate.
Customer A chose to retain all fields for reporting – on the basis that reports can be adequately tailored by deselecting appropriate information fields.
Disclaimer: This website is provided for general information and as such, should not be relied upon for any particular matter. John Salter provides this information as a general reference source only and has taken all reasonable measures to ensure that the material contained on this site is as accurate as possible at the time of publication. However, John Salter makes no representation and gives no warranty about the accuracy, reliability, completeness or suitability for any particular purpose of the information. To the full extent that he is able to do so in law, John Salter disclaims all liability, (including liability in negligence), for losses and damages, (including indirect and consequential loss and damage), caused by or arising from anyone using or relying on the information for any purpose whatsoever.