We’re now over halfway through the Beta testing of our soon to be available agile software. It’s aimed squarely at simplifying. A “no fuss”, “no frills” approach focused on asking the right questions for you and your people to consider, respond to and rebound from disasters. So this update lays out what it does and how it does it in a bit more detail as we move towards our May 28 launch.
A big thank you for your early feedback which has commended the software and the approach for being intuitive, logical and supported by robust thinking. Plus, for giving us “positives out of negatives” on communication – by pointing to where and how we can improve our instructions and our clarity. How does that old joke go? “Why are instructions written by people who already know how something works? Their blind sidedness makes them assume too much.” For “their” read “our”, for “them” read “us”. Guilty. We will apply Rule 101 – assume nothing.
Words and their meanings
Language is important. It is important to use certain words and concepts in agreed and consistent ways. The language and definitions from appropriate International Standards provides value in the set of “keywords” displayed below. In AgileBCP we use these words to support the process and structure of how we assess, strengthen and rebuild the resilience of organizations. They provide the core language underpinning the methodology.
A key distinguishing feature of our approach is our focus on vulnerability. The three aspects of vulnerability we leverage are criticality, susceptibility and impact. Before impact, vulnerability is a function of criticality and susceptibility. After impact, vulnerability is a function of criticality and impact. These three criteria can be adjusted by the users to agreed thresholds which reflect their context. Your “soon” may not be our “soon”. As a set these criteria provide a consistent framework for criteria based conversations and decision making.
The above introductory comments set the scene by providing definitions and conceptual frameworks. Such things only exist in order to serve good practice. The driving force – before, during and after disruptive events – is always groups and teams of decision makers working together. Asking the right questions, considering what their reflections mean, and implementing actions which address the problems at hand.
Populating the organization’s profile by focusing on the resources underpinning each critical activity can be a tedious task. To get the best value from this step it is recommended that it centre on “what if” conversations. Conversations where teams brainstorm the resources which might be impacted under different scenarios. This should be done as frequently as necessary to build capability and a strong information base – database – mapping the organization from products / services, through the activities which ensure the delivery of those products / services amd sequentially, the resources underpinning each prioritized activity.
Attributing levels of criticality and suscetibility to each resource underpinning prioritized activities is best done by teams. This generates conversations throughout the organization which validate (or challenge) the attributions and endorse (or not) the recommended mitigation initiatives.
A trap for the uninitaited is to see the above process as an administrative task. A filling out of forms and ticking of boxes. If the administrative approach is adopted the result will be a document written in a silo and sitting on a shelf with no ownership and commitment. It is crucial to make planning an active process involving all stakeholders. Planning trumps plans. It results in agreed arrangements towards which there is a whole of organization commitment.
The investment in planning before impact is “rewarded” when it enables an agile response to impact – from any disruption. The impact scores immediately trigger conversations asking the right questions and exploring the range of options to address the issues.
Please feel free to provide feedback.