Unstuck By OODA
By asparks on Dec 09, 2008
[Update 10-Dec-2008 – review comment from Chet Richards added to the text]
The article prompted me to research the topics of cognitive feedback and situational awareness to see how these fields could be applied to the field of Project Management.
On looking deeper into the body of knowledge around situational awareness I happened on the work of the late Col. John Boyd.
This post reflects on how one lesson taken from this obscure military strategist can make a big difference in your handling of interaction with your stakeholders and ultimately your project outcomes. Boyd’s work provides a great explanation of how project teams can come unstuck from their primary stakeholders and ultimately fail, while apparently doing everything “right”.
Boyd and OODA Loops
So what did I discover that got me all excited?
The Experience Trap article in the HBR showed how project management experience is not a guarantor of success in complex projects.
Boyd’s work showed me how how cohesion and rapid decision making in project teams could still lead to project failure if important stakeholders are not kept up to speed with the team’s developments and decisions. Effectively the stakeholders come unstuck and are left behind while the project team disappears off into its own reality.
So what could a military strategist tell us about this situation?
The following text is taken from the Wikipedia article on Col. John Boyd.
Boyd's key concept was that of the decision cycle or OODA Loop, the process by which an entity (either an individual or an organization) reacts to an event. According to this idea, the key to victory is to be able to create situations wherein one can make appropriate decisions more quickly than one's opponent. The construct was originally a theory of achieving success in air-to-air combat, developed out of Boyd's Energy-Maneuverability theory and his observations on air combat between MiGs and F-86s in Korea. Harry Hillaker (chief designer of the F-16) said of the OODA theory, "Time is the dominant parameter. The pilot who goes through the OODA cycle in the shortest time prevails because his opponent responds to actions that have already changed."
Boyd hypothesized that all intelligent organisms and organizations undergo a continuous cycle of interaction with their environment. Boyd breaks this cycle down to four interrelated and overlapping processes through which one cycles continuously:
- Observation: the collection of data by means of the senses
- Orientation: the analysis and synthesis of data to form one's current mental perspective
- Decision: the determination of a course of action based on one's current mental perspective
- Action: the physical playing-out of decisions
This decision cycle is thus also known as the OODA loop. Boyd emphasized that this decision cycle is the central mechanism enabling adaptation (apart from natural selection) and is therefore critical to survival.
OK…please translate into projectspeak…
Organizations that can make appropriate decisions faster will prevail.
By cycling through the OODA loop faster, they will leave adversaries or other elements of the environment behind, dazed and confused.
To understand more about this I bought the book Certain to Win by Chet Richards. It’s about Boyd’s theories and their application to world of business. Richards is a former colleague of Boyd’s and contributed to the development and documentation of Boyd’s theories.
[Update. In previewing this article, Chet made the following comment :
This is good. My only comment would be to emphasize that OODA “loop” “speed” refers more to the time to reorient and then for actions to flow from the new orientation (i.e., you may know what needs to be done, but if you don’t have the training or experience, you may not be able to do it) than to cycling through a true cycle. This is a big difference between the OODA “loop” and the Deming Cycle.]
OODA in Projects
I began to think more about OODA effects that I had personally seen and experienced in project management particularly in the implementation of complex packaged software.
Basically what I saw happening is this:
- Project teams staffed with external consultants and employees are supposed to work closely with the end users to gather their requirements and use them to model the desired business process in the software.
- The project team then starts rapidly cycling through decisions and changes on how to get the software to best model the user's perception of the business process.
- The end users get left behind and confused as the project team often moves into its own reality of groupthink.
- Final result is often project failure through a solution that may or may not meet meet requirements but is definitely not accepted by the end users/stakeholders who have disengaged.
It seemed to me that this is almost a negative kind of OODA loop.
The project team ends up seeing itself as separate from its end users and other stakeholders.
The project team cycles through design options quicker than the users/stakeholders can keep up with. This is reflected in the illustration at right where the axes represent percent understanding of the project team solution as it develops over time. lines represent the respective understanding of the solution as it develops over time. While empirical, it shows how the users come unstuck and are not able to keep up with the project team in understanding the project team’s solution to their problem.
The only mitigation I can see is early emphasis on frequent (as much as high quality) communication to help the users/stakeholders/customer/business follow the design/decision cycles and help them stick with it - rather than being left behind and ultimately opting out.
I discussed this via email with Chet Richards. I quote his reply below.
It seems that the idea of using the OODA loop in project management involves keeping the team's orientation closely aligned with what the users/customers think they want and not so much in rapid cycling through the various stages of the "loop."
What tends to happen, as you well described, is that the team's orientation becomes detached from what the user has asked for (which also changes -- change orders are the bane of the military airplane business). Groupthink then takes hold ("incestuous amplification" as it's known in the trade) where the group convinces themselves that what they're doing is what the customer/user wants or needs, even if the customer/user doesn't know it. They interpret any new piece of evidence through this filter, which means that early indications of failure get explained away, not taken as signs that the team is on the wrong road.
Anyway -- this means that project management must take strong measures to ensure that the groups "common implicit orientation" aligns and continues to align with that of the customer or end user.
Sounds, easy, probably almost trite to an experienced program manager, but actually doing it can be tough, especially where strong egos are involved -- not unusual in the engineering world.
Your idea is, I think, the best one. Some managers have even been known to co-locate the team with the customer, or at least have active customer involvement all along, not just at infrequent and heavily scripted program reviews. Certainly the program manager should be spending considerable informal time with the user/customer, esp. in the early stages.
Summing It All Up
I see my job here as showing the access the advice and experience of men and women wiser them I am.
In this case the message from John Boyd and Chet Richard’s is clear.
You and your project team will be able to make decisions and cycle through design concepts faster than your end users and other key stakeholders can keep up with. If you do nothing to continuously engage your stakeholders in this process they will come unstuck. If that happens you run the risk of project failure, even when you have seemingly done everything else right.
For further reading on John Boyd’s work I heartily recommend Certain to Win (Chet Richards) mentioned above.
Also have a look at:
http://www.chetrichards.com/c2w/ Chet Richards’ website/blog
http://www.d-n-i.net/dni/john-r-boyd/ Also by Chet with compendium of Boyd material
Wikipedia also has a decent into on Boyd and OODA.
Get into it.