1. The people who build them are told it's fine that they suck. People who "own the process" (or whatever) don't know anything about software and discount programmer warnings -- "Don't worry, that's not a concern, we aren't here to worry about that." "It doesn't matter if the interface is confusing, because the users will be trained." "As long as there's a workaround, it doesn't matter." "If that button crashes the client, the users will figure out not to click that button."
Sometimes it's just basic stupidity. I know of one case where programmers on a data entry system accidentally implemented a use case that took ten minutes instead of twenty seconds. No problem; the fix was simple. However, they weren't allowed to fix it, because it wasn't "a primary use case." And it wasn't: the users were executing hundreds of use cases per day, and only about five would take ten minutes. So they deployed the software to dozens of hourly workers, who of course ended up spending almost an hour a day, on average, staring at their screen waiting for that use case to complete.
2. Regardless of policy, requirements are almost always gathered from users' managers instead of from the users themselves. Many managers of hourly workers think they know every detail of the jobs under them, but they often don't know the latest details and policy changes. And that's the best-case scenario. A more typical scenario is that a manager comes in with a vague "management overview" idea of what her workers do and a condescending attitude that anything more specific is inessential.
Couple this with the tendency to keep enterprise programmers on a short leash, implementing only the features that were specified in the design process, and you get a result so incomplete that sometimes the only way to avoid rolling back a software release is to remake business processes and policies to fit the software. On the bright side, this can result in simplification and streamlining. On the not-so-bright side, you alienate customers because you suddenly can't serve them the way they've come to expect.
3. The process is single-shot instead of iterative. There's no user testing, and not even any before-the-fact observation of users. Managers don't make any attempt to distinguish between legitimate user complaints and the normal, perennial "OMG something changed" office worker whining. This is especially true when the users are low-paid and not highly educated, which is a shame, because those are the ones who do simple mechanical jobs where their interaction with a software system can materially affect their productivity.
I know of one case where there was a "testing link" from one screen to another that had been accidentally left in the software by a programmer. It turned out to be crucial for workflow, and when it was removed in the second release of the software, productivity plummeted. The workers immediately alerted their manager, but they were ignored. Instead of asking for an immediate bugfix release, the manager waited until several months of metrics piled up demonstrating a massive uniform 20% productivity loss among her workers.
All these point to three problems:
1. The software development process is controlled by people who don't understand software or don't take it seriously.
2. Software developers have no credibility inside the corporation.
3. The corporation always respects the pretense that managers know more (and better) than workers, especially low-paid, uneducated workers, even when this pretense is obviously false.
I was just going to say, "enterprise software sucks because the people who approve its purchase dont use them". This is a great elaboration of that point.
1. The people who build them are told it's fine that they suck. People who "own the process" (or whatever) don't know anything about software and discount programmer warnings -- "Don't worry, that's not a concern, we aren't here to worry about that." "It doesn't matter if the interface is confusing, because the users will be trained." "As long as there's a workaround, it doesn't matter." "If that button crashes the client, the users will figure out not to click that button."
Sometimes it's just basic stupidity. I know of one case where programmers on a data entry system accidentally implemented a use case that took ten minutes instead of twenty seconds. No problem; the fix was simple. However, they weren't allowed to fix it, because it wasn't "a primary use case." And it wasn't: the users were executing hundreds of use cases per day, and only about five would take ten minutes. So they deployed the software to dozens of hourly workers, who of course ended up spending almost an hour a day, on average, staring at their screen waiting for that use case to complete.
2. Regardless of policy, requirements are almost always gathered from users' managers instead of from the users themselves. Many managers of hourly workers think they know every detail of the jobs under them, but they often don't know the latest details and policy changes. And that's the best-case scenario. A more typical scenario is that a manager comes in with a vague "management overview" idea of what her workers do and a condescending attitude that anything more specific is inessential.
Couple this with the tendency to keep enterprise programmers on a short leash, implementing only the features that were specified in the design process, and you get a result so incomplete that sometimes the only way to avoid rolling back a software release is to remake business processes and policies to fit the software. On the bright side, this can result in simplification and streamlining. On the not-so-bright side, you alienate customers because you suddenly can't serve them the way they've come to expect.
3. The process is single-shot instead of iterative. There's no user testing, and not even any before-the-fact observation of users. Managers don't make any attempt to distinguish between legitimate user complaints and the normal, perennial "OMG something changed" office worker whining. This is especially true when the users are low-paid and not highly educated, which is a shame, because those are the ones who do simple mechanical jobs where their interaction with a software system can materially affect their productivity.
I know of one case where there was a "testing link" from one screen to another that had been accidentally left in the software by a programmer. It turned out to be crucial for workflow, and when it was removed in the second release of the software, productivity plummeted. The workers immediately alerted their manager, but they were ignored. Instead of asking for an immediate bugfix release, the manager waited until several months of metrics piled up demonstrating a massive uniform 20% productivity loss among her workers.
All these point to three problems:
1. The software development process is controlled by people who don't understand software or don't take it seriously.
2. Software developers have no credibility inside the corporation.
3. The corporation always respects the pretense that managers know more (and better) than workers, especially low-paid, uneducated workers, even when this pretense is obviously false.