Your Tailored Decision Making App – Example

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.

Link to details of the decision making app offer

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.

Reference from page 41 of the Emergency Risk Management – Applications Guide

Emergency Risk Management – Applications Guide.pdf (p 41)Download

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.