While your suggestion at the end fixes the theoretical, statistical problem, in practice I don’t think it would actually resolve the specific example question. The trouble is, you don’t know what’s wrong with the requirements until you’re well into the project, so asking at the start about requirements quality would not help. An alternative approach in this case would be to balance the biases by asking the people who gave the requirements what caused the project to fail. You would probably get a different answer, validating the point you’re making if so and providing further insight into the real problems.
Although what you suggest might at least qualitatively answer a probably more useful question: “In how many cases could examining the requirements more carefully have identified significant issues?”. Just as there’s no point using requirements as a scapegoat, there’s also no point being aware that they’re a real potential problem unless you can actually identify and fix them in time. Really what people need are the top “avoidable sources of project failure”, which is not the same as the top set of things to blame in hindsight even when it is valid to do so.
While your suggestion at the end fixes the theoretical, statistical problem, in practice I don’t think it would actually resolve the specific example question. The trouble is, you don’t know what’s wrong with the requirements until you’re well into the project, so asking at the start about requirements quality would not help. An alternative approach in this case would be to balance the biases by asking the people who gave the requirements what caused the project to fail. You would probably get a different answer, validating the point you’re making if so and providing further insight into the real problems.
Although what you suggest might at least qualitatively answer a probably more useful question: “In how many cases could examining the requirements more carefully have identified significant issues?”. Just as there’s no point using requirements as a scapegoat, there’s also no point being aware that they’re a real potential problem unless you can actually identify and fix them in time. Really what people need are the top “avoidable sources of project failure”, which is not the same as the top set of things to blame in hindsight even when it is valid to do so.