No, they aren't.
> It doesn't fail because of the product; it fails because of the people and politics of the organization.
Essentially all project failure are for that reason. (Including ones where one intermediary step on the route to failure was that the people and politics in the organization ended up selecting a solution that was a poor fit for the problem.)
It was $110m down the drain on the first product, then another $80m to purchase the second, plus the cost of my consulting time to create custom solutions.
People and politics are the hardest part of any technology implementation. Any article I see blaming SAP, IBM, Oracle, HP, etc of botching a multi-million dollar public project, I always have to wonder: who went wrong... not what went wrong.
The company culture is a central piece of any business problem you are addressing, if your solution doesn't address it, it isn't addressing the actual problem, but at best a lower-dimensional projection.
Interacting with the cultures of some companies is like trying to treat the mental illness of someone in a dissociative fugue state. You might have a solution that fits how things are on the inside—but how are you going to even get through to them to communicate that, when they can’t hear or see you and are instead lost in their own little world?
I think you mean correcting culture to some preferred ideal, and that's likely true.
But what I'm saying is that institutional culture is a factor of every problem facing the institution, whether is a thing to fix as part of the solution or a constraint on viable solutions.
What happened afterwards? Did this trigger management to consider why the purchase was the wrong one? I.e. was it a $110m lesson? Or was it really wasted money?
My company did cut a deal on the consulting for Product B since we had already been working for them on Product A, but the products were charged at full price and to my knowledge none of the cost of Product A was returned to the customer.
As far as management was concerned, Product A was a failure because it was old and inflexible. Management was super happy to see every screen of Product B with their logo on it, which we put on there because we had to develop those screens from scratch anyway. Product B didn't have their logo in the upper right corner, it only had their logo on the printed output.
The only lesson learned was "ask your engineers what product they recommend", which I guess is an important lesson regardless.
In the specific case of SAP, if the problem is "we want to automate our processes" then it's probably a horrible fit.
If, however, the problem is "we need good automated processes", then it can be a great fit.
