Want to jump ahead a few years from Mythical Man-Month? Let me recommend Peopleware by Tom DeMarco and Tim Lister.[2] It's painful that we haven't crawled far out of the 80s practices.
The first chapter says: "The major problems of our work are not so much technological as sociological in nature." Sorry Google Memo Dude. DeMarco and Lister called it in the 80s.
Speaking of DeMarco, he also wrote a book about controlling software projects before Peopleware. Then in 2009 he denounced it. [1]
To understand control’s real role, you need to
distinguish between two drastically different kinds
of projects:
* Project A will eventually cost about a million
dollars and produce value of around $1.1 million.
* Project B will eventually cost about a million
dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really
important for Project A but almost not at all important
for Project B. This leads us to the odd conclusion that
strict control is something that matters a lot on
relatively useless projects and much less on useful
projects. It suggests that the more you focus on control,
the more likely you’re working on a project that’s
striving to deliver something of relatively minor value.
I always think about that when I'm doing a Sprint Review.
Is the A/B situation DeMarco describes about knowing ahead of time that A will turn minimal profit while B will turn maximal profit?
If so, the conclusion reached seems right: tighter profit margins require tighter control. And control requires resource, which is a cost that further diminishes returns.
But if the described scenario is about not knowing ahead of time whether A or B will turn a large profit, how should this be handled? Regular review, and a scaling-down of control as confidence in profit increases?
Of course, profit is only one metric. There may be others that are more critical.
My metric for projects is that if I'm not returning near-term value at least double my billing rate, it's probably not worth doing.
If you are, the difference between 2.2x, double, and 1.8x is pretty negligible - non zero, for sure, but not worth the additional 20% effort to minimize variance.
If you aren't, as he says, no amount of diligence will fix it, because it's simply the wrong project.
It's the classic penny-wise pound-foolish.
So by my conclusion, many of the 'project management' activities that people do are at best wasteful or indeed actively harmful.
I agree with your general point. It's difficult/impossible to get accurate numbers. I would contend that we have a general idea. Management nearly always imposes more control when it's nervous the costs are approaching the rewards. The flip side is Silicon Valley VC investing. Tonnes of money is thrown and very little control is exercised by investors, at least at first, because the rewards devour almost all costs. The programming equivalent might be Big-O notation. We don't know _precisely_ the costs of an algorithm, but we can do general comparisons.
DeMarco also seems to agree.
The book’s most quoted line is its first sentence:
"You can’t control what you can’t measure." This line
contains a real truth, but I’ve become increasingly
uncomfortable with my use of it. Implicit in the quote
(and indeed in the book’s title) is that control is an
important aspect, maybe the most important, of any
software project. But it isn’t. Many projects have
proceeded without much control but managed to produce
wonderful products such as GoogleEarth or Wikipedia.
The first chapter says: "The major problems of our work are not so much technological as sociological in nature." Sorry Google Memo Dude. DeMarco and Lister called it in the 80s.
Speaking of DeMarco, he also wrote a book about controlling software projects before Peopleware. Then in 2009 he denounced it. [1]
I always think about that when I'm doing a Sprint Review.[1]: https://www.computer.org/cms/Computer.org/ComputingNow/homep... [2]: https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...