Sounds like a dozen things I've seen! The people using a system can make that system fail if they want, and it happens so often. I wrote software for printing

Sounds like a dozen things I've seen! The people using a system can make that system fail if they want, and it happens so often. I wrote software for printing press operators that lined up what jobs they should do based in minimizing how many times they need to change ink colors in their presses, and other optimizing factors. They made the system fail hard, because they'd been printing for generations without a computer telling them what to do. So they'd tell the computer they had completed jobs when they hadn't, and when the job queue was empty, they'd proceed to print whatever they wanted. The chaos this caused with the data they then pointed to as an indication that the system does not work. That and a dozen other things like it taught me the importance of making sure the users at the lowest level are really on board. If they want it to fail, you're better off solving that problem, because delivering a working system won't be enough: the people are part of the system. I recognize that it's up to the managers to straighten these issues out, but they are people too, and often have their own agenda not perfectly aligned with the success of the project.