4 ms·

If you work in software development for a decade or more in a corporate environment, you will encounter a surprising number of stakeholders who would like for t

by unoti 13y ago

If you work in software development for a decade or more in a corporate environment, you will encounter a surprising number of stakeholders who would like for the software project you're doing to fail, and will do everything they can get away with to make it fail. I did ERP implementations of Oracle ERP and SAP for many years, and saw this often. This can happen when the system you are replacing has the developer who wrote it (or a set of close allies) working on the transition project, which happens often when there is a system originally written by an in house IT team being replaced by third party software. It can happen when certain in house people did not want to replace the system, or for whatever reason predicted the new system would not be good-- people want their prophecies to come true, and they want to be consistent, so it can be difficult or impossible to convince them the system is good. There can be bad people, and not just programmers, involved in any business enterprise. I try to look out for them and see what's coming when they want to sink a project I am on. I have also found that there are plenty of people who will not acknowledge the simple truth that I am talking about. They will say, "that is insane; how could any actual stakeholder want to see the project fail?" The answer involves looking at the various definitions of evil, which is a fascinating exercise. Sometimes people want to see harm come to others for various reasons, and that is the real world, sometimes.

hga 13y ago
I've seen a similar thing in projects that are in trouble: the relevant manager demotes the person responsible for the failure but leaves them on the project. Only your failure can validate their failure. In your examples, if their ERP software is being replaced, I suspect it's hard not to see it being declared a failure. Another thing I've heard about what some called the "Procrustean bed" of SAP is that it can get terrifically resisted by stakeholders because it insists on rational business processes, and plenty of companies aren't run very rationally. My family saw that while computerizing one doctor's office in 1980: after the data entry was done, the printer would just not stop in the first accounts receivable cycle. Turned out the office workers sent out a fixed number of bills per month (something like 200?), no matter how many actually needed to be sent. They didn't totally understand what was happening, but they knew "the computer would tell all".
- unoti 13y ago
  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.
  - hga 13y ago
    Indeed. My family's doctor's offices computerization effort succeeded because they got buy-in from all the other ones, this was going to make life easier (without I believe any layoffs, there was still plenty of work to be done including envelope stuffing and the system enabled better scheduling and less inadvertent doctor downtime). In the one recalcitrant office the workers never got a chance to really sabotage the effort, since temps did the big block of one time data entry and specialists set up everything. Because the conversion revealed they were in the process of making the office fail due to laziness they were sacked and not in a position to sabotage the system afterwords.

by unoti 13y ago

hga 13y ago

I've seen a similar thing in projects that are in trouble: the relevant manager demotes the person responsible for the failure but leaves them on the project. Only your failure can validate their failure. In your examples, if their ERP software is being replaced, I suspect it's hard not to see it being declared a failure. Another thing I've heard about what some called the "Procrustean bed" of SAP is that it can get terrifically resisted by stakeholders because it insists on rational business processes, and plenty of companies aren't run very rationally. My family saw that while computerizing one doctor's office in 1980: after the data entry was done, the printer would just not stop in the first accounts receivable cycle. Turned out the office workers sent out a fixed number of bills per month (something like 200?), no matter how many actually needed to be sent. They didn't totally understand what was happening, but they knew "the computer would tell all".

unoti 13y ago
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.
- hga 13y ago
  Indeed. My family's doctor's offices computerization effort succeeded because they got buy-in from all the other ones, this was going to make life easier (without I believe any layoffs, there was still plenty of work to be done including envelope stuffing and the system enabled better scheduling and less inadvertent doctor downtime). In the one recalcitrant office the workers never got a chance to really sabotage the effort, since temps did the big block of one time data entry and specialists set up everything. Because the conversion revealed they were in the process of making the office fail due to laziness they were sacked and not in a position to sabotage the system afterwords.