The cargo cult of business jargon

Flight of boarding!

My first thought when I saw this post by Glen Alleman was “cargo cult“. 

I’m wary of concepts from hard sciences that find their way into business jargon, largely because the concepts become incantations.  It feels like we’re appropriating the prestige of science, just like a cargo cult’s “focus on obtaining the material wealth (the “cargo”) of the advanced culture through magic and religious rituals and practices.”

In other words, I cringe when I hear incantations like — “complexity”, “emergent”, etc. — as if the words in and of themselves suffice.   It’s nothing but meaningless superstition without insight and actions that solve problems or exploit opportunities.


Using analogy to communicate complexity

Glen Alleman posts here on the need to ensure that analogies fit the domain.  He notes a common problem with metaphors, especially those adapted from math or science.  They sound right to the layman, but are off-key to the expert.

This insight provoked a few thought on analogies in the ERP world.  We often use analogies to convey the complexity of ERP: changing the engines on an in-flight 747 is very popular.  It sure sounds tough, doesn’t it?  And the image is powerful and vivid, but does it have anything to do with how ERP really works with your business?  Also, who has ever done something like that?

I’ve found that it is much more effective to leverage metaphors that are a bit more concrete.  For example, I’ve found that a conversation about ERP as “a model of your business that operates in real time” gets me down a better path.  We can then move on to concrete visualizations that model — from Tinker Toys, to Lincoln Logs, to K-Nex, to Lego, to Erector Sets, to HeathKits — that come from the participants, not from me.

Big picture = big map (HT @galleman)

Now that I’m somewhat out from under, I’ve caught up with some of the usual suspects on my reading list.  Glen Alleman is timely with another reminder (here) that an integrated master plan is essential.

Program-level plans are as welcome in IT circles as garlic on a Twilight movie set, and I’ve never quite understood why.  As Glen notes elsewhere, you need a map to know where you’re going.  But too many IT folk believe that such “high level” pictures are only needed because their managers as pointy-haired buffoons.  These “detail” men believe that the only valid plan is one derived from detailed task-level plans.

But consider the map metaphor.  How many of us would try to assemble an itinerary from the individual turn instructions?  We wouldn’t, naturally.  We pick where we want to start, how we want to travel (boat, plane, car, or on foot makes a difference), and where we want to end up.  Paper, Google, and program maps get built the same way: you need to know where you’re going to know when to turn (or not).

The only time Crossderry will beat Herding Cats

I found out that Crossderry was named to another one of those best PM blog lists (here).  Thanks Nicole…

One must, however, wonder about a list that has me listed above Glen, Bas, Rich, Elizabeth, and Craig.  I appreciate the mention, but I’m afraid my ranking may overpromise and I’ll underdeliver!

Structuring that presentation story

Leave the branding to me...

Leave the branding to me...

My last full post — on effective presentations — highlighted the “Post-It” method for composing and arranging one’s story.  There are other techniques that help to structure one’s story line and its foundation.

I’ve found affinity diagramming an essential tool for brainstorming.  The process is can be really just as simple as outlined in the affinity diagram wikipedia entry (here):

Record each idea on cards or notes (Post-It’s work great)
Look for ideas that seem to be related
Sort cards into groups until all cards have been used.

There are a number of ways in this basic process can be refined.  In particular, I like to conduct the basic process in silence, which encourages participation from less vocal members.  Discussion can resume once it is time to label groups, tag folks with follow ups, etc.  As you’d imagine, affinity diagrams on Post-It’s can easily be transformed into a nice presentation story flow.

Glen Alleman outlines an even more story-oriented approach in his comment to my original post.  While I’m not familiar with the author he cites, the idea of adapting the classic “three act structure” to presentation structure is outstanding.

Was software engineering ever alive?

The third phase of reanimating Crossderry

The third phase of reanimating Crossderry

The second phase of reanimating my blog is to re-start reading other bloggers. I gravitated back to Glen Alleman and Herding Cats, where his post Software Engineering is Dead? caught my eye.  Two comments:

Google and Wikipedia are the “shining” examples used by detractors of planning and controls.  Funny that they never reference Technorati — any blogger will tell you how unreliable it is.  Nary a word about the issues with cloud computing reliability that Dave Rosenberg notes here… 

Second, has there ever been widespread use of engineering principles in software design?  Sure, I saw it at SAP and I’m sure Glen sees it in A&D. But is software engineering really engineering?

The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. 

Great post/thread on Mathematics, PM, and complexity

Glen Alleman and a number of commenters contributed to a great thread on math, PM, and complexity (here). 

I try to keep the ideas of complexity “science” in mind when planning strategy and its execution.  In particular, I have a deep respect for the power of self-organization and the need to create flexible rather than brittle management systems.

However, I’m not sure how powerful CAS really is as a theory, at least w/r/t/ project management.  For example, how do its predictions advance my estimation approach beyond what we’re doing w/ probability distributions (e.g., Monte Carlo simulations via Crystal Ball)?  To I really need math beyond that to get “good enough” estimates?

%d bloggers like this: