We all know that processes, methods, and practices need to scale to fit project circumstances. But often I hear this lament: this process doesn't scale!
The nature of scale
First and foremost scale is about the overhead imposed on processes and procedures as size and scope changes. This overhead is sensitive to the amount at stake and the complexity of the endeavor. This overhead is, itself, process and procedure, and is purportedly responsive to policy, regulation, and sometimes just plain bias.
As we scale up to larger stuff, we take on a disproportionate increase of process and procedure (pp) to include unique pp that are not invoked at smaller scale. In other words, scaling is not linear. Overhead increases faster than scope.
Scaling down
But what about scaling down? Having become accustomed to all the up-scale process and procedures is it then possible to retrace your steps back down? Alas, usually not. Going up and coming down don't usually follow the same path.
Whereas process and procedure may lead you up scale they often lag coming down scale. It's a matter of hysteresis. Consequently to operate more efficiently at smaller scale is often all but impossible because of the lagging residue of process and procedure no longer needed.
For example, having withdrawn certain authorities and moved them up the food chain, at lesser scale we then have to reestablish these authorities at lower levels, often without a track record of performance at smaller scale. This requires trust, and that may be hard to come by.
In effect, this is the hysteresis of scale and anti-scale. They simply are not overlaid, one on the other.
Floating apex
There may be entire jobs, some of them exalted and executive, not needed at smaller scale. To retrench on scale is make such jobs redundant, thereby creating the floating apex problem: former leaders with a great pyramid beneath them, only to find the pyramid gone and they are the only remaining artifact.. a floating apex looking for justification. The justification is found in retaining the overhead in spite of smaller scale.
Complexity
Then there's the complexity thing. Emergent and unpredicted behavior, friction, and impediments come out of the woodwork as scale goes up. We all know about the non-linear communication phenomenon whereby communications between staff goes up exponentially. We may also be familiar with Brooks Law: adding staff to a late project makes it later
But friction goes up also; that manifests itself in heat: wasted energy that does not go toward project outcomes, so we get less out as we put more in... diminishing returns, in other words.
And, sometimes the machines, computers, and networks simply fail under greater load. Robotic processes are as elastic as human processes, etc.
What to do?
- Break things up to remain "within scale"
- Decouple so that problems don't propagate (create interfaces, in other words)
- Add redundancy and reserves to guard against unwitting fragility
- Spread things out to remove friction. No point in putting energy into heat, unless you're trying to heat the building (as some do)
