Why isn’t the complete specification of critical expectations usually done in ERP projects?

Well, it is usually done – just not with commercial software. The same company that is content to demand “an inventory control module” or “a cash receipts function” will insist on the most detailed specifications before signing a contract to buy, say, ball bearings fit for a particular purpose. It does that because it knows all too well that some ball bearings will not be suitable for its needs. What it fails to recognize is that there are at least as many inventory control modules that are perfectly fit for many purposes, but not for its. This is reinforced by the buying company’s confidence that it knows what “inventory control” and “cash receipts” mean to it – and by its comparative ignorance of what they also mean to other people. And on top of that is their true and accurate belief that purchasing and implementing an off-the-shelf software product ought to be simpler than many of their own core business functions (which, after all, are what distinguish them from their competitors). So why should they pretend otherwise? Why pretend (because this is what it feels like to them) that buying software is as complicated as making the next difficult improvement to their product or their factory? But it is just as complicated. It’s just complicated in different ways.