My experience has been the opposite: the software is easy, but only if you already know what it needs to do. So you have to actually solve the problem first.
> Then if someone has problem with process you tell them "it is software that requires it" and they comply.
How incredibly user-hostile. If they have a legitimate concern, don't leave it unaddressed. If there's something important about the process they're missing, it's a mistake to use the current state of the software as an excuse.
If I would write "I like fight sports" would you write "how incredibly hostile, don't punch people on the streets"?
It sounded to me like the suggestion was to appeal to the supposed inflexibility of software whenever a question about process is raised.
The software is entirely malleable. If the process can't change, explain why. But don't pretend that the software can't change.
Then if someone has problem with process you tell them "it is software that requires it" and they comply.
Organizational problems are mostly problematic to translate to software and make projects die. Because if company is not organized, they won't have possibility to organize their requirements which will lead to problems.