Software suppliers: The 800lb gorilla problem
Your business relies on certain software to function - so what happens when the publisher's interests don't align with yours?
I've visited a lot of businesses over the years and, time and time again, I've seen one particular scenario play out - one I call the "800lb gorilla problem". Indeed, it's not just limited to tech companies: it almost doesn't matter what business you're in.
The official philosophy is that every company is different, and a lot less wisdom than you'd hope is reusable from one firm to another. But then 800lb gorillas don't follow the normal rules. In the words of the old joke: where does an 800lb gorilla sit?
Wherever it pleases. In this case, the gorilla is a de facto monopoly supplier. They crop up in all sorts of industries and, if your business relies on their services, you have little option but to shape your budgets, practices and roadmaps around theirs.
This isn't to say that every sector that's dominated by a single vendor is necessarily toxic. For example, most product designers use AutoCAD, which has an 85% market share in the CAD sector; lots of salespeople won't go to a job where they can't use Salesforce. In both cases, there's a fairly benign coexistence between the publishers and the users of the software. Firms treat the predictable licensing rates as a simple cost of business, and the software houses shape their plans and offerings to fit the market's majority population.
Customers often have little choice but to take on gorilla suppliers' products if they want to compete
One hears plenty of stories about software suppliers mistreating their base of invested users, forcing through unwanted changes to the product or pricing, or ignoring desperate pleas for much-needed updates and improvements. Indeed, once a gorilla company has set its direction, the possibility of a mutually productive commercial relationship often goes out the window. You're no longer dealing with a rational entity that can be negotiated with - not even in its own interest.
That story doesn't perfectly mirror the situation small businesses tend to find themselves in, however, because the consumer market is bigger than any single operator and such hubris tends to get its comeuppance before long. With business software, things are a lot harder: the market is smaller, and the power imbalance is greater, so big players can coast along for decades - and all we can do is put up with it.
Get the ITPro. daily newsletter
Receive our latest news, industry updates, featured resources and more. Sign up today to receive our FREE report on AI cyber crime & security - newly updated for 2024.
Risky business
One experience of mine involved a software rollout project in which the supplier's project manager - a pivotal role - also happened to be a member of Team GB for the 2012 Olympics. For some reason, the software project implementation plan made no specific allowance for his absence during the games: the client simply had to assume and hope that everything would be all right.
In the event, things went very well indeed - for the project manager, who progressed through the heats and the quarter-finals and so on as the Olympics rolled on. The customer, on the other hand, was left sitting wondering whether they would ever see him again. In the end, final implementation was delayed by an entire year, because the chance to cut over from old to new system relied on specific annual dates.
The software supplier is embedded in a specialised industry, and the customer has little option but to take on their product because it embodies all the industry knowledge and expertise that's needed to compete. To the publisher, however, that particular implementation is a low (or non-existent) priority: the implementation team probably had a clearer idea of the impact of the delay than the customer did, but that didn't matter, because there was nowhere else for the customer to go.
Antivirus firm Kaspersky may have been in the news for the wrong reasons lately, but nobody would deny that CEO Eugene is a master of telling customer stories, and he has on several occasions drawn attention to another 800lb gorilla effect that relates to the security sector. Specifically, many businesses are under the thumb of a local gorilla that forces them - likely through inaction - to remain on Windows XP.
When you see a power station or a sewage farm going to extreme lengths to secure its networks, or desperately trying to find a cloud solution to replace its local devices to dumb display status, it's often because they can't get the historic application developers to revisit or update their features they depend on.
At the bottom, the problem of the 800lb gorilla is more a business issue than a technical one. Software developers are often not red-hot profit-making demons by nature; it may well be that they'd love to be more supportive and amenable to their clients, with timely updates and customisations, but find themselves with no revenue stream to support such efforts.
This is a curiously open type of prison. There are many ways of structuring a company that could improve matters. For example, the developer might sell shares to the users, or they could buy a bond with a known rate of return, and receive the software as a separate valueless transaction.
However, most of the IT world is obsessed by "shrink-wrap" distribution, in which software is tangible and paid for up-front - and very few customers want to get caught up in venture capital funding, which places other restrictions on relationships between the provider and consumer.
Doing it the right way
While gorilla suppliers are a real and pervasive problem, let's not exaggerate the situation. Abusive business relationships make headlines: people who just get on with the job don't.
I hear from aggrieved customers ten times for every time a happy, proud supplier gets in touch - and it might not be coincidental that the happiest of suppliers is also the largest, at least if you take the company's own statistics at face value. That's SAP, which hosts an annual ceremony and present awards to its own customers recognising and celebrating the successes they have had with its systems.
Perhaps this is the scale at which software relationships work best, because SAP has plenty of experience in a dominant-player role. Indeed, it may be instructional that the company is used to having a major presence in more than one sector at a time, and fosters a strong internal culture of sharing lessons learned in one sector with teams working in other areas. And it's difficult for manipulative or damaging behaviour to emerge when a typical project requires more than just a single consultant, trainer, project planner and so on.
Of course, if you try to use SAP as the yardstick for every vendor you do business with, you're going to come away disappointed.
Some of the attributes that make up the firm's customer service record are just not going to be available to other sectors, developers and businesses. Indeed, at the time you enter into a relationship with a supplier, there may be precious few clues that it's going to grow into an 800lb gorilla; businesses don't tend to start acting that way until they feel fully entrenched in a market. So while you can look for the red flags, even with the most careful diligence, you may still end up having to cohabit with a gorilla.
How to tame your gorilla
So, one way or another you've ended up in thrall to a market-dominating supplier. What can you do? There's no one-size-fits-all answer, because the precise nature of your gorilla is likely to be sector-specific - and formal resources such as project planning, contract law and human resources don't quite address the relevant issues.
One way to tame your gorilla supplier is to compare notes, and concerns, with other businesses
One idea that came to light at last year's CeBIT expo is to get involved in a forum where businesspeople can vent their frustrations and compare notes with others in similar situations. This may illuminate ways forward, or just make you feel better. Conceivably it could even allow you to join forces and demand change, but don't bank on it - as we have mentioned, gorilla behaviour isn't always rational.
Alternatively, you could play the longer game. Start dipping toes into software development yourself, and run up a prototype or two of the system you'd like to be using, rather than the one that's become the industry default. Gorillas thrive on locked-in customers; you might find that a wet bank holiday with a trial copy of FileMaker Pro is all it takes to put the frighteners on a lazy developer.
Failing that, well, let's not underestimate the challenges of following through, and genuinely developing and maintaining your own bespoke systems. But compared to the privations of living in Gorillatown, it's a possibility that's at least worth exploring.