All Posts in Strategy and Tactics

|In: Strategy and Tactics|Last Updated:

This week I’m declaring my independence from having to write a new KJR entry. Don’t worry, not forever. Just this week, when I’m taking advantage of the KJR Reruns Policy, which states that:

  • Whenever I want I can substitute a re-run for a new column, and …
  • Whenever I substitute a re-run for a new column, you’re free to not read it (which freedom, of course, you also enjoy for new postings).

But I think you should read (or re-read?) this one. It’s from two decades ago, titled, “Battling to achieve strategic change,” and is just as relevant today as it was back then.

I hope you enjoy it and find it useful as you battle to achieve strategic change.

– Bob

# # #

Maybe it’s just semantics.

A bunch of readers commented on my recent column asserting that CIOs and CTOs should spend most of their energy dealing with strategic and tactical matters, delegating infrastructure, (which I equated to the military concept of logistics), to others.

Among the comments: “Amateurs talk strategy, professionals discuss logistics.” This correspondent, along with quite a few others, mentioned a number of examples in which bad logistics lost battles. I agree: Bad logistics can lose battles, as when the Spanish Armada literally ran out of ammunition fighting the British fleet, which was able to re-supply since the entire engagement was fought in the English Channel. But this misses the point. Of course bad logistics can lose battles. That doesn’t mean great logistics can win them.

The lesson for you: Bad infrastructure can make even the best applications unavailable. Great infrastructure is invisible. Do you want to be invisible unless there’s a problem? I didn’t think so. Delegate infrastructure; focus your attention on strategy and tactics.

Or maybe on “Operations” in its military sense. IS Survivalist Ralph Hitchens informs me that military theorists have added this as a fourth level of military planning.

Above it all is the non-military concept of “policy.” “We’re going to stamp out terrorism,” is an example — a national goal which military action can help advance. “Strategy” determines the overall objectives of military action and identifies the major campaigns that should be fought to achieve them so as to help achieve policy. “Operations” decides which battles to fight and how to deploy forces to fight them to win campaigns.

Organizing business change has significant similarities. Enterprise-scale change corresponds to the strategic level of planning. Call the organized effort of achieving strategic change a “program.” Since “operations” would inevitably be confused with running a data center, let’s call the next-lower level of change “business outcomes” and call the organized effort of achieving them “initiatives.”

Then there’s tactics — the specific plan of action military officers create to win battles. What might that correspond to in IT terms?

Tactics corresponds to projects, in more ways than one. In terms of military action, it’s hard to be sure if you’re really achieving your strategy, or even if you’re attaining your operational goals. Likewise in business. Whether the topic is combat or project management, you can be very sure if you’ve won the battle.

It’s up to someone else to win the war.

Comments

|In: Organizational Design|Last Updated:

Speaking of thinking about thinking, it’s time to talk about systems thinking – a topic spotlighted in Peter Senge’s groundbreaking The Fifth Discipline (1990).

Systems thinking is about breaking any whole into not only its component parts, sub-parts, and sub-sub-parts ad infinitum, but also their sub-parts’ interrelationships. It’s a big subject – so big there’s no point trying to provide links to useful sources.

Most likely, you’re already familiar with many of systems-thinking’s tools and techniques. They’re essential for just about any IT-related endeavor.

But there’s a difference between, to take one example among many, using a swim-lane diagram to design a business process and using one to think through who should be responsible for what, to decide if that’s really such a good idea.

What follows are a few tools, techniques, and principles I’ve found useful over the years to help me think things through.

Law of 7 ± 2: This really should be the law of 7, + 2 if absolutely necessary. What it means is that whatever technique or tool you’re using to figure out a system, no representation should ever have more than seven elements in it – nine if you just have to. If you need more, make one or more of the elements more inclusive – a category of elements. Think through its complexity in a separate, cross-referenced diagram that also follows the law of 7, + 2 if absolutely necessary.

Why seven? Humans can easily grasp a collection of seven or fewer items. More than that and we have to inspect. We can verify the correctness of a diagram that obeys the law. With more elements we’re left hoping we didn’t miss anything.

Black box: If you’re trying to understand a business function – a process or practice – black-box thinking is essential. Black box descriptions describe what something does, not how it does it. They cover five subjects (thereby obeying the Law of 7, + 2 if absolutely necessary):

  • Outputs – what the function is for. They’re its products and byproducts.
  • Inputs – the raw materials the function converts to outputs. Any input not needed by at least one output isn’t an input at all. It’s a distraction, unless it suggests a missing output.
  • Resources – the tools the function uses to turn inputs into outputs.
  • Constraints – restrictions on what the process does or how it does it.
  • Controls – mechanisms for adjusting process operation, such as turning a process on or off, changing its speed, or setting a configurable output characteristic.

Relationships: Six ways each system element can influence other system elements:

  • Component – an element could be part of another element.
  • Container – conversely, other elements could be part of the element.
  • Output / Input – one element’s outputs could serve as another element’s inputs, and vice versa.
  • Resource – one element could produce resources used by other elements.
  • Constraint – one element could place constraints on other elements.
  • Controls – one element could affect the operation or characteristics of other elements.

Feedback: A special type of relationship that describes how a process’s output encourages (positive feedback) or discourages (negative feedback) its own operation or characteristics. Diagrammatically, black-box diagrams represent feedback as arrows connecting process outputs to their controls.

As a matter of nomenclature, “positive” and “negative” are unfortunate word choices. They suggest feedback is either complimentary or critical.

From a systems perspective, positive feedback drives a process to produce more of whatever it is that it does; negative feedback causes it to produce less. Positive feedback accelerates a process, negative feedback keeps a process in control.

Output / Input Loops: Not all loops are feedback loops. Some make one or more of a function’s outputs one of its own inputs. The well-known OODA loop (for Observe / Orient / Decide / Act) is an example. Some outputs of its Act sub-function are inputs to its Observe sub-function, and in fact each sub-function’s outputs include inputs to the next sub-function.

Decoupling: Eliminating or reducing the strength of system interrelationships is, as a general rule, a good idea. It makes the system more resilient by reducing the ripple effects of any changes being considered.

Bob’s last word: We’ve barely scratched the surface of systems thinking. It’s a highly consequential subject because without it, it’s all too easy to fall into the trap of focusing on a particular element, optimizing it without taking the change’s ripple effects into account.

Bob’s sales pitch: The next “CIO Survival Guide” is ready on CIO.com for your viewing pleasure. It’s titled “The Hard Truth of IT Metrics,” and I think you’ll find it useful. And as always, if you have any feedback for me (see above), please share your thoughts about it.

Comments