“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.
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
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
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).
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
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.