Musings on project management: What price complexity?

Saturday, March 1, 2014

What price complexity?

Complexity: the myriad interactions and influences between pieces and parts that gives rise to performance and functionality not discernible from just an examination of the pieces and parts

As an aside, keep the idea of complexity and complicated separated: Complicated is a bunch of stuff, but if the interactions are minimal, then something really complicated may not be too complex.

Three questions that should come to mind:

Are the effects of complexity in this project predictable?
Should we -- the PMO -- count on some effects always being amongst the unknowable -- and thus, unknowable risks? If so, how much reserve to set aside?
How do we -- the PMO -- plan for the effects of complexity?

Fair enough: It's all well and good to have three questions, but here's the important point: You can't just end it here... Some action required! And, as you might imagine, this stuff doesn't come free.

So, here are a few answers:

To point #1:

The only way to predict complexity is to build it or simulate it -- presumably at moderate cost and effort. Build it: prototype, or some such; simulate it: various action models, like a Monte Carlo, for dynamic behavior.
Of course, in any simulation, some calibration is required, especially if a model is involved -- to wit: you don't want to have model artifacts mixed in with the real predictions.
If the system is biological or chemical, then complexity may include dynamic adaptation, popularly called "complex adaptive systems" (CAS). Probably nothing but a small scale but fully functional prototype is going to do the trick
If the system includes a "human-in-the-loop", then some of the CAS behavior may be in the offing... humans are very adaptive and quite unpredictable when not scripted. This where testing for error traps is really critical, because we humans do the damnest things!

To point #2:

In a word: Yes, especially if your project and its deliverables are complicated. Latent complexity is likely lurking! Of course, you can't be lazy about this. You should expend effort trying shed light on latent effects. Again, prototypes and simulations are the best tools.

To point #3:

First, you don't want the project or the system to be fragile -- that is, unable to absorb shock. So, you need some redundancy
Second, you don't want all the eggs in one basket where there could be catastrophic damage: thus, diversity (distribution of risk into independent containers or to independent actors -- and the stress in on "independent")
Third, if the bad stuff happens, you want it contained: thus, loose coupling! (In the sailboat racing analogy, sailors build sails with "rip-stop" seams that contain a failure to one section of the sail. See also: Titanic, for watertight compartments, an example of the violation of the "independence" principle... there was coupling between compartments that was unforeseen)
And last: there's a hidden cost: integration cost arising from complexity

There's not much point in raising these questions if PM's can't deal with them in some practical way day-to-day. Recall my favorite way to get started with both architecture and estimates: the Box Model