There are a number of unanswered questions implicit in what DeMarco has written:
1. How does one actually choose the projects? How does one know that Project A will eventually cost $1million and deliver value of $1.1m versus Project B costing $1m and delivering $50m. What if both cost $1m and deliver value of only $500k each? What if both eventually end up costing $20m each and deliver value of $1.1m each? How many of the last type of projects could a company afford (a normal company - not a company like Google which earns so much from other sources that the cost of failed projects is almost irrelevant). Most organisations do not have unlimited funds, and so must somehow choose between projects. That choice is usually couched in economic terms (the cost of projects versus the benefit (ROI) of a project) but we all know that mostly the real decisions concerning projects are political (of one sort or another. So one could argue that the economics don't count - except that most of the "politics" has the economic impact as one criteria of the politic decision (people want to know the numbers - even if they ignore them!) and thus, the basis of actually knowing how much a project will cost BEFORE it starts needs to be considered. Once again, how does one do this?
2. The implication is that one should just do software until one decides to stop. When is a good time to stop? Once again, it appears that the implication is that one stops when the key decision maker(s) decides to do so - when the money runs out, or when there appears to be enough functionality to satisfice. Unfortunately, the second option requires serious understanding by the decision maker concerning the functionality and effectiveness of what has been produced (acapability not readily available in most organisations). And the first option may easily gazump the second. The money runs out with something that is barely useable, if at all. What then? Ask for more money? Typically yes, which leads to the next point.
3. If some software is needed strongly enough by an organisation, it usually ends up just keeping paying for it, month in, month out, regardless of the original estimates for costs. What starts out looking like a "standard" software engineering project (big plan up front, lots of process and control, big-end methodology, etc) turns into a never-ending "agile" project. Work continues unabated, withreleases popping out on a regular basis, based on the ability of a fixed team of developers to produce within that period, as prioritised by the business (if they are lucky) - and not based on any semblance of specific functionality planned for and controlled in a big-end development process. The afore-mentioned scenario occurs if the organisation is lucky. If it isn't, the software remains as is, under-delivering for the organisation until it is replaced by yet another attempt to get something useful for the organisation.
4. In all the available scenarios outlined above, the only real way of determining the usefulness for some software is after the fact, including determining the cost for the software and the value that it delivers. This does nothing to address the proper concerns of organisations in relation to managing expenditure and investment, and ensuring that the financial position of the organisation is managed and known in advance (particularly important for financial reporting for companies, especially public companies). This is also an important risk management issue for organisations.
5. Which brings one straight back to the question of reconciling the activity of "craftsmen" in a "managers" world - something which continues to be exceedingly difficult. Maybe this is the key question which really needs to be answered in relation to enterprise information systems.
