Project Management: Clash of the OODA Loops

by dj on December 17, 2004

Judging from the feedback on my last essay with regard to software development/project management, I got points for being readable but more than one reader thought I was overly sarcastic. I promise that in this post that there is no danger of excessive sarcasm or perhaps even readability. Unfortunately, only wonks may find this subject matter appealingt however one reward I can offer to the persevering reader is that once you understand (or even begin to acknowledge) the impact of OODA loops in project management, then a lot of (dyfunctional) behavior all of sudden becomes understandable and even predictable.

First, in any large organizational or logistical undertaking, the tasks or actions can be divided into three subsets: Policy, strategy and tactics. This is a hierachy, with policy at the top. Roughly speaking, policy is why you are doing something, strategy is what you are doing, and tactics are how you are doing it. One example is Allied behavior in WWII. The policy of the Allies was unconditional surrender of the Axis powers. The strategy of the Allies was engaging the Axis powers on the battlefield and bombing their cities in a war of attrition. A tactic that the Allies used in their strategy was the employment of the seaborne invading forces as in the cases of Sicily and Normandy. Another example of the policy, strategy, tactical heirarchy: It is the policy of Microsoft to make money by selling software. One of the strategies employed is their leveraging of their dominant marketshare of OS sales to invade other product niches. One of Microsoft's tactics is to group most of their developers in one physical location to maximize communication between the product groups.

Policy always dictates strategy, and strategy dictates tactics. However, there is some duplexing in this hierarchy. Strategic consideration can cause a change in policy: For example, the policy of victory on the battlefield may be reconsidered if you face an enemy that outnumbers you 2 to 1. Microsoft's strategy of dominating the OS niche was nearly altered by tactical considerations with regard to anti-trust lawsuits. However, it's still a hierarchy: Only logistical constraints should interrupt the dictation of the top layer to the junior layer.

OODA stands for Observation, Orientation, Decision Action. A more complete explanation of OODA is here, and you should take time out to read it.: For those of you too lazy to link & read, OODA loops are (vastly over-simplified description follows), a decision-making cycle. Every project of moderate complexity goes through a number of OODA loops, whether people acknowledge it or not. The spiral methodology used in a lot of software development projects (like Prinergy) could be classified as a specific kind of OODA loop. Every good project manager understands one big thing about OODA loops: The quicker you execute one, the better. Another interesting tidbit aboutOODA loops that they are not always executed to the point of success. That is to say, sometimes you execute a (cheap) OODA loop to reach a failure point, or a "negative discovery" rather than to be successful. But "negative discoveries" is an idea that is worth discussing in it's own essay, so we'll cut short that tangent.

Okay, so what is the causal relationship between the policy/strategy/tactic hierarchy and OODA loops? Well, keep in mind that policies must have the longest OODA loops in the hierarchy, and consume the most resources. The next longest is strategy followed by tactics. That is to say, to successfully conclude one policy loop, it usually transpires that your strategy or strategies have to undergo a number of OODA loops. Ditto for strategies with regards to tactics. Follow me so far? Well, okay, in theory there should be no organization that attempts to have a policy OODA loop that is shorter than a strategic OODA, otherwise you have dysfunctional chaos. But of course, this is what happens so often in the real life.

The most obvious examples of clashing OODA loops occurs in the realm of politics: A left-wing political party takes office and dictates a policy of reducing economic inequality in the population. A number of pieces of legislation are drafted and introduced, several strategies are debated and put in the process of implementation. An election is called, and the right-wing political party takes power and changes policy. By this time, the civil service that has put so much effort into the legislation & regulation of the previous party's policy, resists the new policy because the OODA loop for reversing the policy is probably longer than the results of the next election, when the left-wingers get back into office.

Another example could be in software development: Some bright-eyed and bushy-tailed project manager/project engineer decides that the company software development division should adopt a strategy of every programmer working in C#. But 40% of the programmers use Java. More importantly, the lead project manager position in that company tends be a bit of revolving door, with new project manager/engineer every year. Most programmers think the new strategy won't last until Christmas. Bingo, too bad for the project manager, the OODA loops are clashing, so what do you think is going to happen to his initiative?

The great lesson to be learned once you understand the concept of clashing OODA loops is that it's really dangerous and risky to screw around with policy changes, because that leads strategic changes which leads to tactical changes and so on. And it's REALLY risky to continually change your policy. As a matter of fact, it almost always leads to a dysfunctional organization ie the lower tier not listening to the upper tier anymore. Most good corporate leaders understand this: In his 28 years at the helm of General Electric, Jack Welch implemented a grand total of 4 major new initiatives, or one every seven years. Lou Gerstner, when he took over IBM in the early nineties, when it was teteering close to bankruptcy, famously said "the last thing IBM needs right now is a vision."

The great lesson to be learned for project managers is that you will not be successful in implementing new strategies unless you've been around the block a few times at that particular company or there is some great crisis and it's pretty darn obvious that things have to change. However, I would not bank on the latter. There are lot of companies that have managers who believe in "manufactured crisises" as a method of getting people to change tactics. And quite frankly, it's a sign of a bad manager, as continual operation in crisis mode burns people out and induces a culture of cynicism. A much better method is to take into account tactical considerations, then formulate a strategy that is synchronised with the policy of the organization. I fell upon this method quite by accident when I was a rookie manager. I was assigned a development team in Israel. In theory, a project manager is supposed to dictate tactics to make a successful strategy. In this particular example, the development consisted mostly of veterans that didn't need a rookie like to me to tell them anything. And to be frank, there was fat chance that they WOULD listen to me if I tried to tell them how to do their jobs. I may have been pretty green back then, but I wasn't totally dumb. After awhile, I figured out what they really DID need was for their project (which was to connect hardware made in Isreal with software made in Vancouver) to be validated, or that the organization would think of it as a valuable project . So I championed the strategy of Canada/Isreali cooperation, got buy-in from the various support teams in head office on the strategy, and once a week I got on the phone with them to ask how they were doing. I gave them whatever logistical help I could scape up. And I didn't tell them how to do a darn thing.

When I left Creo, I got more than one e-mail from Israel saying how upset they were that I was leaving. I was pretty proud of that. Israelis have a well-deserved reputation for not putting up with incompetent leadership (that's probably due to the fact that if they had bad military generals, they wouldn't have a country.)

In conclusion, there's lots more that can be said about OODA loops, I hope I have hammered home the essential thesis of this essay: Clashing OODA loops lead to dysfunctional behaviors in any large organization.

Comments on this entry are closed.