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
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?
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!
- 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.
- 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
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog