The cargo cult of business jargon

Flight of fancy...now 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?

More on estimation principles

I saw this comment by Dennis Stevens (Dennis’s blog is here) on Glen Alleman’s post on software estimation practices (here).  His comment hit on two points that stood out.

Effective estimating requires a strong understanding of variance in estimating and how to account for/govern this variance.

Ditto and amen… my experience in implementing logistics optimization (I worked for formerly-independent component of Descartes) helped me get comfortable with the fuzziness of estimation (e.g., variance).  Two b-school courses were also helpful: mathematical modeling for marketing and applied multivariate analysis (I keep the latter’s textbook by my desk). This background may not make me an expert, but I have a decent estimation BS detector.

Politically driven estimates are just irresponsible management. I remember a conversation with an executive where I told him “This is a 46 week effort. If you need to say 32 to get funding, then you can say 32 and deliver 14 weeks late – or we can say 46. It’s up to you.” We presented at 46 weeks, got the funding, and delivered on time. If an organization can’t afford to do a project, it shouldn’t be done based on false estimates – this is malfeasance.

As Dennis suggests in this case, pretending that the earlier delivery target does not compromise the product or mean inevitable delays is foolish, even unethical.  My experience is that this self-sabotaging approach happens because the project can’t or won’t demonstrate the impact of such decisions on the initiative’s business case.

To that point about the business case, I’ll use a future post to lay out how we used a simple illustration of our business case to justify an internal program’s proposed release schedule.

Deliverables, work packages, and the schedule

This temptation to fix a schedule and get to work is constant in enterprise IT.  It is particularly alluring for any application tied to a SOX-compliant landscape — some governance models only allow two opportunities/year to deliver — where project durations strongly suggest themselves and time is always “a-wasting”.

Of course, as Glen Alleman reminds us here, starting with the schedule  is wrong.  I won’t recapitulate his post here, but I’ll borrow from his comment to another post which points out the fallacy in this kind of thinking:

[M]any…process improvement projects have failed, along with Enterprise IT, because the WHY of the effort is not established or well understood. The principles establish WHY we should be doing something. The practices of course tell us HOW.

This rush to “get working” short-circuits on of the most important functions of a WBS: stakeholder management.  Properly defined deliverables and work packages aren’t simply inputs to the schedule, budget, etc.  If nothing else, a WBS  is the most accessible framework for a discussion with one’s stakeholders that ensures that the what of the project supports the why of the project.  Wouldn’t it be a good idea to make sure that why and what are elaborated and priorities agreed upon — even at just a couple of levels — before getting down to who, when, where, and how?

Methodology Scaling/Selection Outline

Or maybe I should say “Methodology Scaling/Selection Graphic”… Glen Alleman’s recent post on PM and Agile (here) reminded me to post this picture (click to enlarge) of a slide we use when discussing which methodologies to use for which project.  Note that we do not directly oppose “Agile” vs. “Waterfall” in our continuum.  Sure, SAPScrum is pretty pure agile, but that doesn’t mean that ASAP doesn’t contain agile concepts (e.g., emphasis on iteration short cycles during the Realization phase). 

methodologyscaling

Also, we’re emphasizing that initiative leaders must be comfortable combining philosophies when implementing solutions, which is why we’re driving program management knowledge out to our general PM community (as implied in the bottom box).

Follow

Get every new post delivered to your Inbox.

Join 2,518 other followers

%d bloggers like this: