Strategizing with OODA and PDCA loops

Abstract

Concept of practice is central to strategizing. Strategy is defined as facts about endeavour with regards to 5P Mintzberg’s definition of strategy. These facts first forecasted with practice discipline as hypotheses and then produced as a result of performing practice. Produced facts are either support or reject hypotheses. Such verification is evaluated by endeavour stakeholders to the level they shift chances of endeavour success from stakeholder’s viewpoint. Business actors that represent stakeholders deliver and test hypotheses and strategy in specially allocated space-time extents according to prespecified protocols, which is called business interface. Strategy, thus is influenced in discipline change which is described by OODA loops strategizing or by business actor change which is described by PDCA loops strategizing.

Topic starter:

Marcus Guest OODA Loops. Now this is getting interesting. The cycle diagram above though is wrong. For example, if you make faster decisions but they're all wrong you only die quicker. Better to get to grips with the real OODA Loops (plural, not singular), which looks intimidating but is well worth the time to explore as it provides insight into how humans act in an uncertain world without having access to all the information they need -- critical skills in a volatile and unpredictable world

Александр Турханов Of course, OODA as well PDCA is strategizing. Continuous development and implementation of strategy. But when we are talking PDCA we're changing only technology, and when OODA then we can change discipline and practice. That what moves object on wardley/power map between maturity lanes. PDCA progresses object within the lane.

Marcus Guest Alexander Turkhanov components on Wardley/PowerMaps move through evolution (ubiquity over certainty), which I agree that OODA is a major part of. Unlike Wardley though I don’t see OODA as a type of strategising but the DNA of how we interact with the world, often muddling through, while I would agree with you that PDCA is more about tech/process shifts where cause and effect is predictable. Both required — now more than ever as it’s how humans interact with the technology and how these emergent cyborgs interact with each other.

Александр Турханов Marcus Guest I'll address that tomorrow if you don't mind. I have definition of strategizing as practice of how do we change practice. And we have either improvement step (that's PDCA) or development step (that's OODA). And that's basics of decision making because when you need to invest you should consider different options and you cannot do that with PDCA. So, for development part of strategy you need OODA.

Marcus Guest Alexander Turkhanov I agree with that. I’m teaching this next week at MISiS: convergent and divergent thinking. PDCA may be the former but I’d argue that OODA covers both as it’s also a subcomponent of PDCA. Look forward to your further thoughts on it tomorrow.

Thesis:

We perceive about 7% of ‘objective reality’, just an example, large corpus of research is behind this:

https://www.ted.com/talks/donald_hoffman_do_we_see_reality_as_it_is

The rest 93% is our construction of observed world and in systems approach we say that people are stakeholders meaning by that they see objects defined by their ontology. Once you learn new practice and start to see new things in the world and your ontology extends.

Man as a stakeholder is assigned to perform some practice. When he is performing this practice he sees mostly objects defined by this practice and misses the rest of the world. So, when you put professional optics on, you always missing changes of the rest of the world that does this practice does not define. Typical example is ‘missing gorilla’ series of tests. So, your ontology defines what things you can potentially see in the world and your stakeholder position define what optics are you wearing now and what objects are in your attention focus now.

I am operating here and further with BORO ontology and this defines my ontology choices, see slide 30: presentation slides

That basically mean we are using B-theory of time by John McTaggart: https://en.wikipedia.org/wiki/B-theory_of_time

This also knowns as 4-dimensionalism or perdurantism: https://en.wikipedia.org/wiki/Perdurantism

In perdurantism we are not distinguishing future, past and present, they all exist in 4D. Past, present and future are just relative markers that tag event sequence. And we know lesser about the future then we know about the present.

So, what does it say about my definition of strategy?

Practice has underlying discipline that defines this practice. We can say that practice consists of people with disciplinary thinking and technology that supports this disciplinary thinking and domain actions. Discipline is consistent set of theories in certain domain. But disciplines can be of course contradictory and you cannot apply them together. Discipline defines Goals, when you apply finance management practice goals will come from finance controlling discipline, but not from mechanical engineering discipline. Basically discipline is stating facts about the future. There are two ways I can get facts in rational thinking - from observing reality (facts per se) and from discipline (hypothesis). If they match, I say that discipline can be valid, hypothesis is not rejected. It is interesting because in 4D we don’t distinguish between future and present and thus hypothesis are just another fact with just tag ‘future’. You just have not observed it.

So, from one point of view strategy comes from discipline. If you want to set some goal that your current discipline says impossible to reach, you need to change discipline. ‘You cannot reach the Moon, climbing successively taller trees’.

So I define practice as some shared by many people view on how to see and operate the world.

Now we need to move to pragmatism and find out how stakeholders get disciplinary goals. We model pragmatic approach with concern and assessment, see details further in:

https://ailev.livejournal.com/1429330.html

Stakeholder who is assigned to perform, execute particular practice has concern regarding the system or project. Concern is definition of discipline. For example, if I am concerned whether it is enough money to finish the project, I start looking for some discipline that can predict cash sufficiency and can find few - traditional controlling, lean budgeting or beyond budgeting. So my concern defines discipline and practice I want to execute. Because if I want to cut expenses in half I need to go with lean budgeting because it is impossible to reach such stretched target with controlling. And that will define my strategy. But concern per se does not define goal and we apply assessment to it. For example, the same concern ‘cash flow’ two stakeholders - finance manager and operations manager will assess quite differently. Bean counter will say that cash flow is poor and cash deficit is imminent, but shop floor guy will say there’s plenty of cash. We don’t judge right and wrong in pragmatism, we just need to account for it. So, stakeholder set goals based on their assessment of concern. If money is not enough, goal will be to earn more or spend less. And we achieve that goal through practice.

And we go to the strategy now. I’d say that concept of practice is central to understanding what strategy is. I use Mintzberg’s 5P definition of strategy:

Plan, Ploy, Pattern, Position, Perspective.

Strategy is definition, not description. It obsoletes once been written and communicated. So you need to strategize, it’s like DevOps, you continually redefine and incrementally deliver strategy. It is dynamic goal not static. But how do you know you’re executing strategy? You need evidence, facts that shift stakeholder’s assessment of the overall endeavour closer to success and farther from failure. In practice this means that using discipline from certain practice we set goals that meet stakeholder assessment of concern. And we make hypotheses about the future. We call these hypotheses ‘requirements’. So, requirements are such facts, statements about the future, that currently look pretty challenging to deliver. So stakeholder should be pretty much surprised when she observes the fact of requirement fulfillment. It should be like ‘wow, iPhone 10 Siri is sooo smart’ and not like ‘it has 5 Mp camera on it, duh’. But we can set not only systems requirements, but endeavour requirements, why not? If we say that company should perform unrealistic plan or persist current market position despite fierce competition or any other hypothesis from Mintzberg’s 5P it is definitely strategy.

So, funny thing, endeavour requirements is our strategy. So we can use requirements engineering discipline to excel our strategizing practice. We can discover strategy the same way we discover requirements, we can verify strategy, validate it.

Requirement realizes discipline means that through discipline stakeholder makes hypothesis about the goal that are captured in form of requirement and once we verify requirement, we can test, confirm or reject hypothesis and this test shifts stakeholder’s perception of endeavour/system success. That’s pragmatism, success is defined by stakeholders.

But that’s not all. Meanwhile stakeholder are defining success of endeavour and system, organization consists of business actors and not stakeholders. And this is organization that has strategy and not stakeholder. We need to put that together.

Business actor is any organization: enterprise, department, project team, committee, working group or just single position. Business actors give and deliver promises in orchestrated activity. These promises meet at some point in the world which I call Business interface. Let’s consider practical example. You go to pizzeria and you place an order, you get pizza and pay money. This is you as business actor assigned to customer stakeholder role performing nourishment practice. And there is pizzeria business actor assigned to salesman stakeholder role performing cooking and selling pizza practice. Once I am over with buying pizza be as business actor can switch back to being project manager and pizza guy can switch back to finance manager and continue bookkeeping. Business actor are usually assigned to several stakeholder roles.

Transaction is performed between business actors over the counter, specially located place in space and time, business interface. You cannot get pizza outside, you should go to the counter. You cannot violate practice and pay in Euros. And you expect that check will be exactly as price tag shows. So there is protocol on this transaction.

What is important here is that requirements, hypotheses are tested on business interfaces, strategy is delivered and verified on business interfaces. And business actors deliver promises on business interfaces. May be that is somehow reflected in the language, because we deliver strategy, meaning we produce facts that are out of ordinary and when stakeholder observes such fact she is starting to think “may be they are moving in the right direction”.

So, as we can see from the last diagram, strategy=endeavour requirements can be influenced in two ways: by changing discipline or by changing business actor. Either way it is some development project, which changes people way of thinking and that would be discipline change or changing business actor organization or tools and that is technology change.

Now we back up a little to what discipline is and why do we need it. Discipline is set of coherent theories with which we can make forecasts and plans. If we don’t change discipline, we can plan-do-check-act. But if we change discipline, we cannot forecast very well, we just not familiar with new set of theories, we don’t have enough knowledge of it. So we observe-orient-decide-act.

And that is what I meant when said that OODA is for development step of strategy and PDCA is for excel step of strategy.