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.

PMBOK 4th Edition Features — Data models per process

Scope Defintion section of Scope Knowledge Area -- 3rd Edition PMBOK Guide (Copyright PMI 2004)

Scope Defintion section of Scope Knowledge Area -- 3rd Edition PMBOK Guide (Copyright PMI 2004)

When I saw the pre-release PMBOK Guide 4th edition draft, the new data models attached to each process caught my eye. 

I liked the 3rd edition’s attempt to capture data and process flow.  However, the approach was a bit clumsy, largely because it was done by knowledge area.  To be fair, the 3rd does have a set of process group diagrams in Chapter 3 with a decent overview of the flow.

Scope Definition Process Data Model -- 4th Edition PMBOK Guide (Copyright PMI 2008)

Scope Definition Process Data Model -- 4th Edition PMBOK Guide (Copyright PMI 2008)

While the big picture view those diagrams provided was nice — versions of them exist in the 4th edition — mapping the data inputs/outputs by process is more rigorous and intuitive IMHO.  I was OK with  the boxes listing the data I/O, but the models are much more effective visual representations of the individual processes.

I’ve provided a couple of examples of the different approaches FYI.