I wasn't saying that this design decision didn't cause the performance problem. I was instead saying that without a detailed post-mortem, you shouldn't conclude that it was that. Personally I'm never comfortable with conclusions unless I have been balancing at least three theories. One theory is usually prejudice. 2 gets me into binary thinking where I have a hard time really thinking through the merits of either. 3 seems to be my threshold to really start breaking things down and identifying what is going on.

Also when a project goes wrong, it usually goes way wrong. My suspicion is that the database decision is more of a symptom than a cause. The poor understanding of user requirements is another symptom. Firing the project manager is suspicious. I'm sure that if I knew more about the project failure, I would come up with lots more symptoms.

Symptoms of what, though, is a different story. Were key people not properly prepared for their roles? Does the company have a command and control philosophy which results in more CYA than useful early feedback about potential problems? Was the wrong kind of project structure for the problem in use? Did you have a deathmarch? (These are not mutually exclusive possibilities...)

There are plenty of classic books from Peopleware which have lots of useful stuff to say on why projects fail and what you can do about it. But without knowing some details, there isn't much that you can concretely say about what should have been done better on any given project.

Which is why I limited myself to pointing out other possible technical performance problems other than the obvious which plausibly played a role.