Unstuck By OODA

cover1

[Update 10-Dec-2008 –  review comment from Chet Richards added to the text]

An article in the February 2008 Harvard Business Review (The Experience Trap by Kishore Sengupta, Tarek K. Abdel-Hamid, and Luk N. Van Wassenhove) led me on a treasure hunt of new concepts.

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.

slide1

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.

Comments:

Good stuff. The value of having Chet Richards to help us make Colonel John Boyd's brilliance "come alive" is simply invaluable.

However, when you talk of Project Management, there is but one master practitioner: Tony Rizzo. He was trying to teach me Boydian concepts for years. Applying the OODA Loop to make real progress in projects. Rizzo's Total-Matrix approach takes Goldratt's Critical Chain Project Management (CCPM) and Boyd's efforts to the next level.

What Rizzo discovered, and is missing in this article on communications within projects, is the primary system's invariant. The true key to project results.

-ski

P.S. See Rizzo's breakthrough here: http://tinyurl.com/5nh6qz

[Nice one! Getting constructive criticism and new ideas and sources is exactly why I started blogging. Thanks. AS]

Posted by Jeff 'SKI' Kinsey on December 15, 2008 at 05:57 AM CET #

I have been mulling over a communications theory for large scale project management. I recently discussed the topic with Gregg Howe, who specializes in Lean construction management. Gregg pointed me to Boyd.

Here is (roughly), the project management problem I am trying to solve. Say that you have a software development project with coders in multiple countries, time zones, and cultures. How does the project manager direct and control a project without lengthy status meetings at ungodly hours? We need a system that does not require direct communication or direction - this is where OODA helps. Next we need clear ground rules for team participants. This is the theory I am working out. My draft nickname for this system is "Two Yeses".

The Two Yeses theory can be explained with fish that swim in a school and can near perfectly respond to external changes (big sharks). Each fish uses OODA to make individual decisions based on stimuli around them (Boyd's Orientation). Here's the kernel of the Two Yeses idea. In order for a fish to move, they need two "yes” votes from a fish on their right and left. If one fish says "Big Shark" but the other does not, then the fish does not move. Both right and left fish schoolmates must agree to the threat for our fish to move.

The translation to large scale software development is that each resource (programmer, subject matter expert, tester, etc) is preset to watch two other resources. Near constant communication is required. Once a resource hears two yeses from their two designated sources, they change they behavior. So the communication is based on Two Yeses and the decision making is based on OODA.

My hypothesis is that the combination of these two ideas could create a system that would never need a status meeting and that change and knowledge would be distributed at near instant speeds. I recently worked out the geometer for this communication, but have not written up the idea formally. Someone smarter than me has probably already thought of this. Let me know if you have heard of this somewhere else.

Posted by Christian A. Salmon on March 12, 2009 at 05:52 PM CET #

First off, great comment - thanks!
I think your post unpacks several interesting points that might need some dialog to surface all of the issues and key points so let me take a first bite at it and let me know your thoughts.

I have not personally seen a "Two Yes" theory on response to change but I am sure we could check further in the network (I'll help with that) to search further. Certainly the Second Opinion ethic might be relevant here.

My thoughts are as follows:

In a project setting you would have to be careful about where you get your two yeses from. The danger of course is that your yeses or noes all come from within the project team, whereby you run the danger of being subject to groupthink. An example is where your offshore development team based in Zenda (hypothetical country) goes off the ranch because they're all convinced the changes they're making are the right ones, while forgetting to check with the PM and the customer. This is why projects need to formalize change control so that key stakeholders are kept in the (OODA!) loop and the team doesn't come unstuck from them. Also requiring costing and a business case is a good discipline for sanity checking all those good ideas.

In line with this point I would be skeptical about any process eliminating the need for project meetings or documentation of issues (above a certain size/impact) and decisions. Some decisions can have significant financial/commercial impact for project stakeholders so a swath of (unarchived?) IM posts or Tweets won't cut the mustard of legal folks get involved. IT project failure does not normally cost people their lives - but it can cost livelihoods.

So having sternly made these points...

Formalizing change control does not mean killing everything with bureaucracy. This is where you need to dig into Boyd a bit deeper to also understand additional concepts come into play. Chet Richards is an authority on this subject - look at his blog post  OODA loop “speed”.

What OODA Loop “speed” is all about is keeping one’s orientation well matched to the unfolding reality (...) while having effective actions that can flow from one’s orientation via the “implicit guidance and control link” most of the time.

That way, one can operate at a faster tempo or rhythm than an opponent when such a course would be advantageous (see, e.g., Strategic Game, 44), or do nothing if that’s the best option at the time.  But in any case, your real OODA “loop,” the one between your ears, is going flat out.

Boyd expanded on this by describing 4 characteristics of a organizational climate for successfully dealing with change, creativity and initiative. The concepts are from German because they sum up the concepts in a more compact way than English (and you have to think a bit more about what they mean). The concepts are (again, borrowing from Boyd & Richards):

Fingerspitzengefühl - Superb competence, leading to a Zen-like state of intuitive understanding. Ability to sense when the time is ripe for action. Built through years of progressively more challenging experience. Magic.

Einheit - Unity. Has the connotation of "mutual trust" and implies a common outlook towards business problems. Built through shared experience. Fingerspitzengefühl at the organizational level.

Schwerpunkt - Any concept that gives focus and direction to our efforts. In ambiguous situations, answers the question, "What do I do next?” Key function of leadership.

Auftragstaktik – Convey to team members what needs to be accomplished, get their agreement to accomplish it, then hold them strictly accountable for doing it - but don't prescribe how. Requires very strong common outlook.

Translating these concepts to the scenario you outlined (multi-team, multi-timezone project) it is about creating a (project) climate of trust where the (remote) PM trusts the local team lead & staff to make the right tactical decisions about changes within agreed boundaries (this is the implied negotiated nature of Auftrag) while they keep the end-goal (Schwerpunkt) in mind. This is not in conflict with my first bullet - but nuances it. It means the local teams proceed adaptively while not having to go back to the PMO  for every little thing. However formal approvals or decisions should happen when needed. Conversely the PM can/should unobtrusively monitor tactical decision making to check that his/her trust is justified.

Alternatively - the two yeses might apply when qualifying whether a change should be formally considered or not...

OK - enough for a first reaction. Your thoughts, Chris...

Posted by Andrew Sparks on March 13, 2009 at 07:00 AM CET #

Andrew,

Great post, and very interesting follow-ups.

Communication between users and the project team is really the key. To facilitate this, I've found it helpful (where possible) to have one or two key users "embedded" in the core project team. Their main function being to keep the rest from going off on interesting but (very likely) irrelevant tangents.

Regards,

Kailash.

Posted by Kailash Awati on May 14, 2009 at 06:03 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Projects have become a lifestyle in business. Lets get good at them.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today