The Point Beyond Which
Business and processes, whatever their nature, act like buffered transform functions. They take some input, and they provide some output which is the result of an internal activity. A bit of an over simplistic and mechanistic take, perhaps, but not necessarily inaccurate. Granted, most of these things are not single-input-single-output (SISO) black boxes, but instead have multiple ins and outs, with strange cross couplings all over the place, and frequently showing complex adaptive behavior. But, if you stop feeding them with what they consume, they sooner than later stop producing anything and go belly up. A startup without funds, a restaurant without customers, a plant without water.
A flawed logic which seems to reign around some managerial circles is that, for every increase at the input, you should always obtain an equivalent increase at the output. As if processes, teams, businesses, will not show any opposing dynamics to these ever-increasing stimuli.
Some practices and methodologies, such as Systems Engineering, have gained themselves a sort of “halo” in certain industries: you just must apply them. Fair, we all agree Systems Engineering brings benefits, lots of them, no doubt about that. But is there a “right amount” of Systems Engineering beyond a point which it can actually become counterproductive? Turns out, there is, at least according to research which even suggests a pretty precise number: a maximum 15% of the total project cost12, or it turns itself against you. Wanna do more? Go ahead, but you are creating more problems than you are solving, and more problems is not something you need in your already troubled project—all projects are troubled. Tricky enough: a problem disguised as a solution. You may even enter a self-destructive cycle where you think that the way out is only by doing more of what is actually killing you.
Too much of anything is bad. You can die of water poisoning for example. Yield, turns out, will inevitably start decreasing sooner than later as you keep on pumping the inputs, all other things being equal. Nothing to see here: just the law of diminishing returns at play.
But explain this to the brainwashed “more is more” decision-makers who believe that things magically expand beyond infinity.
—Diminishing what? Get outta here. Nothing is impossible.
The problem is that most variables around management are hidden variables. You cannot directly gauge them, but only indirectly observe their effects, which can take place everywhere and nowhere at the same time. Therefore, returns are difficult to assess, let alone evaluate their rate of change. And here’s the key: diminishing returns start to show way before the maximum yield is reached—past such point, returns become directly negative.
Undoubtedly, the key lies in the all other things being equal bit. Unless you do something in advance to prevent a process, team or business entering a full stall, you are destined to make things worse while thinking you’re making them better. Laudable, still stupid.
In short:
There will be a point beyond which more people will not improve the schedule (also known as Brooks’s law).
There will be a point beyond which more Systems Engineering will not keep the project costs at bay.
There will be a point beyond which more testing will not improve software quality.
There will be a point beyond which more features will not make the product any better.
There will be a point beyond which more tools will not improve a process any further.
There will be a point beyond which more documentation will not make things any clearer.
(Ceteris Paribus)
Mind this number may vary depending on the context, but the important takeaway is that there is a certain SE effort beyond a point you start losing.
https://www.hcode.com/seroi/documents/SE-ROI%20Thesis-distrib.pdf