Buyer's remorse haunts 3 in 5 business software purchases Three in every five software purchases are regretted by IT departments for a variety of reasons, including unforeseen costs. This is according to research involving 3,400 software procurement heads at 3,400 international businesses, conducted by market researchers at data cruncher and consulting house Gartner. Some 60 percent …
they're selling a customer experience
They advertise heaven, install hell and take divine payment.
And that on top of the fact that those who actually understand IT are never part of any IT decisions, which makes advertising heaven easier, installing hell easier and optimizes divine payment.
'And that on top of the fact that those who actually understand IT are never part of any IT decisions, which makes advertising heaven easier, installing hell easier and optimizes divine payment.'
Swings both ways. Plenty of IT types dont involve the business. The results are usually similar.
"perhaps the software company salespeople could focus less on their quarterly targets and more on selling solutions that genuinely address the needs of end customers"
In the late 1980 and early 1990's I gained a reputation around our county.
People would ring in to the computer dealership (remember them?) and say they needed a computer.
I would go in an spend 1/2 day or so going through their needs and in at least 50% of the time, I would show them how to streamline their current processes to continue for longer without having to buy a computer and all associated expenses at that point. (Almost always the streamlining of the processes made it easier to move to computerisation later.)
I told them exactly when (based on their growth) it would be appropriate to start using a computer, and almost every one contacted us again at that point and we sold them the computer, printer and infrastructure they now needed.
I had a boss who was very onboard with this approach, and his reputation in the 'clubs' he was a member of rocketed as a result of these honest appraisals.
In the 8 years I was there, we had very few questions after I had installed the equipment and provided some training, and certainly no customer complaints.
A certain premium could be sought to provide that level of long term customer engagement, but these days everything is about the short term bottom line and IT supply has been reduced to little more than box shifting.
C-Suite buyer's remorse only kicks in when it affects their bonus.
I have seen some insane (to me) decisions to purchase software/services that were not required, purely to satisfy some budget fuck-wittery.
Over half a million pounds on virtualization software that added nothing but grief. 2 large systems, only capable of running a single very large VM each, no capacity for failover. Buying software licences for an insane amount of money that were never used - along with the systems and associated infrastructure required to run said software that was purchased at the same time. Just 2 of many cases.
Go to them to get funding for business critical fixes and you get nothing "because it's not been budgeted for" - and is usually the first thing to get cut from any budget request (had that happen several years on the trot, despite the critical failures being experienced on a depressingly regular basis).
I'm the OP.
You'd think, right?
Identified the issue, in advance, and suggested that the software/hardware get replaced. Ignored for a number of years until critical failures started surfacing. 6 YEARS of continuous issues/failures. Every one of those 6 years I added a budget request and it always got removed. After being outsourced, numerous project requests were put in to address the problem. Guess which project got denied.
Funniest time was being in a meeting where I reiterated for the millionth time the need to address the issue (with some very senior people present), during which the service failed again and took out a large portion of the estate. I just sighed, said "See - I told you so" and went to go fix the mess. They *finally* stumped up some money to make a start, but I left not long after.
During that time, they wasted amounts of money that would make your eyes water on shit they never even used. I couldn't even begin to work out how much money they lost due to service outage.
> I couldn't even begin to work out how much money they lost due to service outage.<
You might want to befriend some bean counters(*) and see if you can get them to conjure up those numbers for you
If you can provide a (colo[u]rful and easy to read and impressive looking) report of all the costs of the outage and how much they would be probably reduced by your proposed project it is much easier to get a budget approved.
(*)Sometimes you just have to deal with the devil
"You might want to befriend some bean counters"
and ask them about the difference between CapEx and OpEx (capital expenditures and operating expenses) and how each one affects taxes and the quarterly and annual report status of the company. Some are loathe to make capital expenditures (new equipment) while happily paying multiples of the same price toward operations to keep the company ratios looking good for the investors.
No one ever thinks about how to make the Shiny New Thing work happily with all the other upstream and downstream systems at contract signing time.
I've been in quite a few situations where the IT manager rushes into the room and declares gleefully "All you weirdo developers can fuck off now, we're BUYING an application and it does EVERYTHING!!!".
What they fail to realise is that our shitty home grown software by definition already knows how to talk to all our other shitty home grown software whereas the off the shelf package he's just been demoed in a clean room environment will take at least 5 years of hitting it with a big stick to get the most basic functions flowing end to end
The developers continue to collect their salaries for as long as it takes to jump ship to a shop that values their skills and the contractors parachuted in by the vendor bleed the first company dry. Then said IT manager turns up at new company...
Ah, yes.
A former employer of mine used to have an ancient but reliable minicomputer running PICK for their stock control system, accessible from simple dumb terminals.
They replaced this with a Windows-based system that was so proprietary and opaque, they found it necessary to employ temporary staff to do nothing but recreate verbatim on the new system every SKU that existed on the old system by retyping everything from printouts -- there was simply no way to import data from a text file generated by plugging the serial cable that would have gone to the printer on which they had been printed into a PC and casually asking it to run off a report. (And yes, by the time cast-off 80286 PCs had begun replacing some of the dumb terminals, some of the shop floor staff were writing their own little BASIC and C programs to simulate keystroke sequences to the stock control system and capture output from it.)
Nobody actually liked the new system, and I left that hellhole shortly after the full changeover had been postponed for the second or third time.
On the other hand, I've had a bunch of instances where managers insist on using shitty home-grown software to inplement (badly) what the external software already has built in because "we don't want to be totally dependent on that package" (result: man years wasted and the job still not being done properly by the internal stuff)
#1 Stakeholder, end user and employee engagement are critical at every stage of the process.
#2 Always request a full featured POC driven by the ultimate process owner.
#3 Start small in both scope and license count.
#4 Always ensure you have support and develop a solid relationship with at least one of the engineers. Befriend them.
#5 Educate your vendors and provide as much insight into your internal processes as it is allowed.
#6 Think about tomorrow when deciding to lock-in with a vendor.
#6 Is there a possibility for OSS alternatives?
#7 But always calculate your ROI and listen to your engineers.
#9 have a plan to extract your data from this application and move to a different application.
Really, this needs to be core to all IT solutions. You don't need to know what that other application might be...but if you can't extract your data and move it to something else, you just hooked the future of your company to a company you have no control over (and statistically speaking, may not outlive your company).
I know this will never happen because there's a whole cottage industry around configuring people's SAP instances for them, but SAP should consider offering this service directly for their cloudy versions. They send a couple people to you and they collect various requirements. Then they go back and they configure an instance of SAP for you and then provide someone to train you on how to use it.
Not just SAP
One of the utterly worst systems I can think of (payroll, purchasing, etc etc) is built around Oracle and resulted in more staff being taken on to deal with it than the old systems it replaced
(This is at a Russell Group University. Anon for obvious reasons)
Considering the number of companies I've seen where managers make decisions based on what they can stick on their resume as something they oversaw for their NEXT job, and how eager they are to blame the underlings for failings rather than accept that a bad decision was made by them...I am just amazed the reported numbers are that high.
In the few cases where someone actually talks to another company for their experience implementing and using a product, it is usually to the person who made the decision, hardly an unbiased opinion. How likely is the CIO to say, "Yeah, well, that was a bad decision I made"?
I'd be surprised at a 20% *reported* dissatisfaction rate, based on what I've seen.
(and yet, sometimes things go well. I had a job where our company supported an application (written elsewhere) that was a total s***show -- old PL/1 code written by people 30 years ago by people long gone or dead and new Java written by seeming idiots. And from my side, it was obvious how bad it was. But...while doing some maintenance with a new customer who had just converted their old core application over to "ours", they told me, unsolicited, "we really love your system, we are so glad we converted, it is so much better than our old one". This was just a trench-level grunt talking to another trench-level grunt, not a C-level trying to justify their decision...and I'll admit, it really made my day.)
I'm not stunned.
The buyer's remorse doesn't necessarily mean the person being surveyed says "I regret this purchase I personally approved" it means the person being surveyed regrets a purchase that the company he works for has made.
i.e., he might be the new guy after the resume booster you mention has implemented business software package X and has to deal with package X's shortcomings all the time. Or even if they don't necessarily regret the decision itself they regret how it was implemented (SAP can be great, but it is so complex most implementations fall well short of fully utilizing its capabilities and for that reason falling well short of fully replacing everything the previous system(s) SAP replaced were capable of)
There are levels of shitfuckery in software. I've seen bad systems and I've seen much worse ones.
If you already have an utterly atrocious system then moving to one which is merely "bad" can seem like (and often is) a vast improvement even if there is still room for better software
Interestingly, much of the really bad software is both hideously expensive and has high licensing fees - C-levels assume that the high price means it's better (The Remington model)
One wonders how many of the regretted software purchases were voluntary and how many were forced because the current installation had become unsupported.
I do have one memory though. I was (unusually) put on the group to visit a reference site for some piece of software, I forget what. When the vendor rep was out of the room for a minute I popped what I thought was the obvious and vital question: "OK, with the full benefit of hindsight, would you buy this product again?" My colleagues were horrified, and told me I shouldn't put them on the spot like that. "Why not?", I said, "its what we're here to find out isn't it?". Apparently not, and I was very rarely asked to go on such visits again!
I've been retired for 5 years but when I was working, one of our divisions used to sell software and services cheaply knowing they would make a fortune on change requests.
An example: Back in about 2010 (or thereabouts) they sold a government dept 2 HP superdomes knowing well that the design would only work if they had 3 of them. But, of course if they'd specced that up front, another companies offerings would have been cheaper.
And yes, the dept paid up to get a system that actually worked.
I honestly cannot understand why anybody, in this day and age, would choose to pay for software.
When I don't pay for a piece of software, I get the full, annotated Source Code; the rights to enjoy the use of it, study its internal operation, share it with my neighbours and adapt it to my needs; and its developers treat me as an equal. And if the practical exercise of any of these rights requires a little more skill than I can muster, I have the right to employ someone to help me. If I try it and discover I don't like it, all I have lost is the time taken finding out.
If I were to pay for a piece of software, I would get told exactly what I could and could not do with it, how many people were allowed to use it, and possibly even how powerful a computer I could use it on; I would not get the Source Code; I could not share the software with anyone else; and I would have to alter my workflow to match the software because I am neither allowed in principle, nor (for want of Source Code) able in practice, to change the software. And if I decided I did not like it, the vendor will not usually offer a refund; the only way I could recoup some of my losses would be by selling on the software to some other mug punter. Some vendors no doubt would even try to prevent me from doing that, if the Law of the Land did not make it crystal clear that they were not allowed to.
It boggles my mind that a a person could have so little respect for themself as to put up with all those restrictions, when there are alternatives out there.
The article is not clear.
It sounds like they canvassed 3400 "software heads", i.e. the person in a company in charge of buying software (and implementing it I guess).
But these people generally end up buying more than one package in a year. So having 60% of them with regret, sounds like at some point in the year the person bought at least one package that was more complicated to get running than they expected.
I doubt we're talking about something like Windows. Although getting that running on a dozen models of computer from three different manufacturers (such as with my company) involves a lot of complications, some of them quite unexpected.
For instance in one install a while ago, the manufacturer-supplied audio driver on one model interacted with MS Access such that playing music could corrupt a database. We had a lot of MS Access databases at the time, so the computers were silent until they could give us a fixed driver.
If you don't expect complications in a large company buying lots of different software, you're just not competent. It's why they pay you after all, rather than giving it to the student intern.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
