Something I came across recently is the OODA Loop, created by Colonel John Boyd (born 1927). I would like to say when he came up with the model but details on its evolution are sketchy. The OODA loop is like an ancient artefact containing lost wisdom in that the knowledge is indisputable but the history of it is less understood.
Boyd created it to understand how decisions are made and how to ensure you make better decisions than your enemies, presenting the ideas behind it in military briefings. Because it was born out of the air force and not out of business, Boyd is relatively unknown, despite an idea as powerful as anything Porter came up with.
OODA: The Quick Version
In short, Boyd classifies the process behind continuous action as a cycle of four stages:
- Observe: Look at the situation
- Orient: Interpret the situation
- Decide: Make a decision based on the conclusions
- Act: Do something based on the decision
The results lead to a new environment to observe and the cycle repeats.
This one idea is applicable to any area where decisions need to be made based on incomplete and dynamic information such as sports, litigation, and business. For this blog I am applying it to a series of CRM design workshops which is described well by the idea of imperfect, continuous action.
For military purposes, if you can go through the OODA cycle faster than your enemy, you leave them making decisions based on invalid assumptions and stuck in a process of re-evaluation and inaction.
OODA: The Longer Version
This is Boyd’s more complex representation of the OODA cycle calling out inputs and outputs into each stage of the cycle.
Let us work through this in the context of a CRM System Design. In my example I am thinking of a common situation where you have, say, a week of workshops with different stakeholders and overlapping requirements e.g. all of the stakeholders need activity management and user security. Each OODA cycle will be a day speaking to a different set of stakeholders and, for the sake of the feedback loop, configuring a demo system for review the next day.
In the Observe stage we are taking in all the information we can. Boyd splits this into:
- Implicit Guidance and Control: This reminds me of the idea of the ‘zone’ and refers to moving directly from observation to action. This is ‘acting without thinking’ or what Neo does at the end of the first movie to Agent Smith when he is wiggling his arm around.
In the case of our workshop, I see this as knowing how something should be done in CRM even before the workshop starts. From experience, it becomes clear there are good ways to do things in Dynamics CRM and not so good ways. For example, you should never use the default publisher for configuration. As CRM MVP Julie Yack says “friends do not let friends use new_”
Implicit Guidance and Control is the distillation of experience of working with CRM and knowing what works and what does not.
- Unfolding Circumstances: Often in workshops not all questions can be answered, because they have never been asked before or some aspect the project relies on is in flux. A common example is upgrade initiatives happening in the organisation. In a workshop this week, I wanted to know if the client was using Office365. They were not but had good intentions of doing so in the near future and knowing this had a material impact on my design. As the cycles of design continue, the incomplete information becomes clearer and this will modify our approach.
- Outside Information: This might be Microsoft’s Release Preview Guide for CRM or feedback from Microsoft on specific license requirements for the client, for example.
- Unfolding Interaction with the Environment: This is asking questions in the workshop to gather information. It is also ‘reading’ your audience to understand their attitudes and desires. Knowing one of the participants has no interest in seeing a new system implemented could be the difference between project success and failure.
In the Observe stage we use all channels available to gather the information for processing, which happens next.
This is the distillation of the information into a meaningful format. In the language of Business Intelligence, this is where we transform data into insight.
The pentagram in Boyd’s diagram refers to the filters all of us have when processing information:
- Genetic Heritage/Cultural Traditions: In our case this does not translate directly but refers to the world view being shaped by nurture/nature. The closest analogy for us is the idea that different types of consultants will interpret the observed information differently based on their background. For example, Developers and Functional consultants each have their traditions when it comes to design and this shapes their view on how things should be done
- New Information: As information is processed, other information comes in which needs to be factored into the conclusions. Maybe questions asked in the workshop were taken offline and answers have come back.
- Previous Experiences: Whether it is previous experience with the client, with the software or with the situation at hand, this will influence the conclusions drawn.
- Analysis and Synthesis: The key to Orient, according to Boyd, is to have many mental models to work with to apply to the information, mixing and matching the models, as required. Probably the most famous mental model for design workshops is the People, Process, Technology model but there is no reason why other models cannot be brought into play and combined with each other. Ideas such as force models from physics or interacting ecosystems from biology are excellent models which can be applied to business processes and the structures within organisations. In our case, this can also refer to document templates which shape how we treat and interpret the information we have.
There is not a lot in the diagram on the Decision stage and there seems to be little written on it by Boyd himself other than the idea of taking the conclusions of the Orient stage, considering all possible actions and then applying one based on the best possible hypothesis.
In the case of our workshop, we have gathered all the requirements, distilled it down and we now decide whether we use Option Sets or Tick Boxes, Queues or Teams, go on-premise or online.
The Action (Test) element here is following through on our hypothesis and seeing if it worked. In our example, we get the design from the workshop and apply it to our demo system. In the case of integration, implementation or development, we might run it past the project team to validate our approach.
Once this is done, we can check our results and begin the cycle again.
Finally, the cycle becomes part of our observations for the next cycle. Boyd refers to three feedback mechanisms:
- Feedback from the testing: The first line of feedback is in testing our design and expectations. Perhaps we had a dashboard with too many elements on it or the developer determines our coding approach is based on a flawed understanding.
- Feedback from the testing (Unfolding Interaction With Environment): This feedback, rather than testing our expectations, refers to what really happens. Perhaps the developer identifies an undocumented bug in the product, preventing our otherwise sound approach or we find an incompatibility in going on-premise with the client’s infrastructure, or the client simply hates the design.
- Feedback from the hypothesis: In this case, rather than feedback from testing, it is feedback from our underlying hypothesis. If not invalidated through testing, the hypothesis will carry on through to the next cycle and shape the information we gather and what we do with it. For example, if we decide to deploy on-premise, this may affect the design of the system in the other workshops and lead to different lines of enquiry than if it was an online deployment e.g. is Exchange online or on-premise? Do you have servers to support an on-premise deployment?
Whatever we discover through these mechanisms, this will shape what we do as we meet the next group of stakeholders and look to meet their needs. So the cycle repeats.
I really do like this model and see it having application in terms of Agile development, competitive selling, and bug fixing, to name a few. In the case of a seasoned CRM consultant, a lot of OODA cycle for workshops is intuitive but for consultants new to design workshops, perhaps this can serve as a framework for the process and also as a guide to the kinds of things to consider when designing a Dynamics CRM system. If this is you, I wish you all the best.