Are you ready?

Over the past months, I have been working on an obective method to communicate the readiness of an organization for diffferent forms of recovery. In my last blogs on BCM, I already showed some of the things I played with, like the dependency graph. But in order to help management decide and communicate how an organization is doing, more comprehensible tools are required.

Many organizations immediately go for publicly available things like the NIST BCM framework . I get that. These come from reputable organizations with a lot of background knowledge and is surely is beneficial to read up on those sources.

After reading NIST, my conclusion was that it is shaped like the usual consultancy maturity scan tool. It states what must be done, leaving the how to the reader. This is good practice and if you dive into all the documents organizations like NIST provides, you'll most likely find a solution that fills those blanks.

Communication is key

There is one drawback though. In-house experts exerience this approach as "just another opinion from people who did not bother to find out what we know and have".

As a consultant I do not want to create paper solutions. I want to do stuff that matters, that adds value. So, I had to take a different perspective. One where I start with a group of internal people, determine which aspects they feel are important for their field of expertise. I can add to the list based on frameworks like NIST, my own experience and knowledge I gathered. Because it is a joint effort, there is time to present different perspectives and discuss the overlaps and gaps. This makes the acceptance of the conclusions a lot easier.

In order to prevent a situation in which I have to work with enormous groups, I work with architecture domains. I use 9:

With the Enterprise/Domain architects we determine the relations between the architecture domains and the dependencies.

For each architecture domain, we organize sessions with subject matter experts. With them, we create the lists of aspects relevant for the architecture domain. Then we determine per aspect the requirements per maturity level. This is not a single session: it is more advantageous to give the team time to read up on certain areas and then - together - determine the requirement that should be met for a certain maturity level of an aspect in one or more follow-up sessions. After all, the organization did not come about in a single day either, you need time to think and digest.

In the paragraph above, I purposely said requirement as singular: you want to prevent a situation that in order to attain a certain maturity level, you need to realize a long list of requirements. Lists of requirements tend to change over time, making the effort of increasing maturity akin to firing at a moving target: a lot more difficult than it has to be. Keep it at one to three requirements maximum.

Requirements should be realistic for the group present and their organization. A requirement like: "Ocean is boiling" should be avoided. When you order that in increasing complexity and take dependencies into account, you can create a list of steps to take for every aspect to increase maturity. The highest defined level for an aspect is the maximum attainable goal.

A matrix as described may look like this:

In the image above, documentation, software, security, automation and testing are the aspects you want to investigate. Per aspect, there are a number of maturity levels (11 in this case), determined by the maximum defined level of all matrices.

Take documentation as an example (Name column):

1. Global Design/High Level Design. The Global Design provides the guardrails for whatever you are creating
2. Detailed Design. In this document you make sure what you want is actually working and all the details are known.
3. Service definition. With the designs made, which is where most organizations start, you can define the service that you want to offer with the design. A lot of organizations are missing this and expect that "if you build it, they will come". Unfortunately, it does not work that way.
4. Change Design. From the Detailed Design you can start creating the CRUD processes and document those in state machines, sequence diagrams and pre-post conditions that can be tested upon.
5. Business Impact Analysis. Now you know all the things that will come out of the designs, you can assess the real impact of the proposed change on the business of the organization (some organizations begin with the BIA and update it later)
6. Operational Impact Analysis. With the designs and Business Analysis done, you can start assessing the Operational Impact. From the BIA you get scale and speed of adoption, from the change design the amount of work per sold item and from the DD the exact details on the implementations.
7. As an example, I entered a Documentation Portal and generated documentation as the highest maturity level.

The columns MoSCoW and Status indicate where the organization stands with regard to the implementation. I connect a score to each of the MoSCoW and Status fields combined wth the maturity. This culminates to a maturity score which you can draw in a spider chart:

The advantage of such a spider is that communication is easy: the difference between green (maximum score) and blue (actual realisation) gives an indication of the amount of work that must be done. The matrix on the top of this article shows an example. Because the teams themselves have created the matrix, it is clear to them what they must do and goals tend to be realistic.

Management can prioritize one aspect over another, influencing the order of improvement.

Auditing is easy too. Auditors can validate the aspects investigated and indicate if there are missing or incorrect views, requirements or MoSCOW/Status assesments. Their SME can validate the requirement set and the values to be attained with external parties. Missing aspects, additional requirements and/or ordering of the requirements are a relatively small adaptation of the work your people have done themselves.

Have fun figuring out what is important to you.