Linking Design and Action: How to Say what to Do


Published on

Language offers excellent opportunities to jam square pegs into round holes. But unless you're a poet or a salesman, doing that is probably not the best idea you've had.

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Linking Design and Action: How to Say what to Do

  1. 1. Linking Design and Action How to Say what to Do An archestra notebook. © 2014 Malcolm Ryder / archestra research
  2. 2. “Do As I Say” Communicating requirements effectively is, we usually agree, the first step in having execution predictably generate the desired results. In fact, the whole idea of “predictable” – literally, to “say beforehand” – presumes that people who were spoken to understand what was being described. So, we might say that when execution failures to “meet” requirements, the root problem is that the understanding held by the speaker was not the understanding held by the listener. The challenge of communicating requirements exists not only between customer and provider, but also between manager and worker, or instructor and student, where the issues are about how to make something correctly, and how to make something work.
  3. 3. Connecting the Dots It’s easy to appreciate what happens when we try to make complex things without a “blueprint” or some other instrument of design. The risk of failure easily outweighs the likelihood of a satisfactory lasting result. Bringing in an architect directly addresses the challenge of translating the idea of the desired result into a reliable version of the desired result that can be produced. Because of the effort of architecture and design, we presume that the version will not have missing parts, wrong parts, or parts that don’t do anything. And because of that same effort, we presume that the parts included and used are ones that unambiguously work together according to their purpose. So… when we are communicating, why is it that, despite the above benefit being common knowledge, we so often skip that intermediate step of applying precision in selecting and representing what is involved? It’s an odd oversight that occurs in casual discussions (even amongst experts) but also in the most important things that we try to do (even including strategy).
  4. 4. Crossing the chasm Without deep drilling, we can appreciate that Strategy “communicates” through a Design for operations that gets realized with Processes. And, we can readily appreciate that not having a strategy can mean not having operational designs, and/or not having processes that are clearly relevant to high-level goals. We also find that a workgroup (of whatever size) may say or show what it calls strategies, designs, and processes – even when these things are not actually getting connected to each other. In other words, parties generate these things, because they think they are important; but, too frequently, the connections between them go missing for one reason or another. A frequent reason is because the things the workgroup shows as strategies, designs, and processes cannot rationally be connected. They were not derived from each other, and/or not selected for each other, when put in place. An equally frequent reason is because the things being shown as strategies are not actually strategies; likewise, some things are incorrectly being called designs or processes. The inability to correctly distinguish things by type has led to using the wrong things in given circumstances, preventing proper alignment and co-operations. When authoritative speakers repetitively call things by the wrong name, it decreases the audience’s understanding of how things can work. This makes terminology itself a focal point that must not be ignored.
  5. 5. Taking a shot at solving it… In this example as shown, common terms are in a layout that is logically hierarchical. In that configuration, we can see that just because something has a shape does not yet mean it is organized; that because it has a form does not yet mean there is a pattern; etc. To get from point A to point C, you don’t skip point B. Value Achieved Guides Action Has Logic Model Method Has Function Template Technique Has Arrangement Pattern Process Has Boundaries Result Form Procedure To Organize To Shape To an important degree, these separations are validated by two “normal” recurring issues. (1) How do we build something? (2) If something stops working, what aspect of it needs to be fixed? If you either have those responsibilities or teach them, you cannot afford to confuse the distinctions that correctly answer those questions. © 2014 Malcolm Ryder / archestra research A great example of how we should attack this problem is to examine ways that we tell people how to do something, including identifying what they rely on to do it.
  6. 6. Herding the Cats • With precision restored to the terminology, we can understand that “strategies” generally refer to the functional logic being applied against a goal; “designs” generally represent the guidance that prescribes or documents the arrangement of the functionality; and “processes” generally refer to the activity that executes the functions in an orderly arrangement of effort. • That is, we can see which of the more specific terms might reasonably “fall under” the cover of each of those general ideas. • The fact remains, however, that such generic references are inadequate to key efforts such as development, management, support, and evaluation; and what will make matters even worse in those efforts is arbitrarily or poetically using individual terms as synonyms for the generalizations, instead of as pointers to important specifications. When authoritative speakers repetitively call things by the wrong name, it decreases the audience’s understanding of how things can work. This makes terminology itself a focal point that must not be ignored. A limited vocabulary, carefully distinguished, provides its own best argument for being used consistently. It’s hard to understand how blurring the distinctions “adds value” to discussions that ask for serious attention to the subject. The two most notable exceptions have reasons for being less precise: (1) starting to lead an audience from words it already likes to use, to a correct understanding, and (2) marketing, where the objective is to appeal to whatever already seems attractive. © 2014 Malcolm Ryder / archestra research
  7. 7. Making complexity safe Architectural complexity is a great reflection of how we eventually see the whole problem to solve. It becomes evident that when we are building a given complex structure, or a given complex statement, we may use and cross multiple dimensions of references. (control) (operation) So for example, we can see that “construction”, “operation” and “control” are different dimensions. It can be that a technique in control is dependent on a process in operations, and that the process in operations is dependent on a method in construction. What we do not want to see, in execution or in explanations, is those distinct factors being mistaken for each other, nor being referenced without context (dimensionality). In our example, the need for a “method” in construction is not a specified need for a “method” in control. The inability to maintain this kind of clarity is a leading cause of failures in explanations and execution. (construction) A given result may require precision in different dimensions of its composition. The composition may require that certain relationships across dimensions be supported, such as an action in one dimension being a “constraint”, “prerequisite”, or “cause” of an action in another dimension. © 2014 Malcolm Ryder / archestra research
  8. 8. © 2014 Malcolm Ryder / archestra research