3 ms·
Fascinating. 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 c
by austinjp 9y ago
Fascinating.
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.
- jaggederest 9y agoMy 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.
- JamesLeonis 9y agoI 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.