- It is often presented that risk is reduced by buying from the largest software vendors.
- This article explains why buying from large software vendors actually increases risk.
After a detailed analysis of this topic, it is clear that the standard approaches to managing risk on enterprise software selection and implementations such as hiring a name brand consulting company, purchasing name brand software or paying for IT analysts like Gartner do not work. This should be entirely obvious at this point.
Some journalists will bemoan the high failure rate of IT projects but will fail to point out the clear reasons as to why. Most of the advice they give and issues they highlight really seem to be just nibbling around the edges of the problem. (Actually, most of them can’t because the entities that are most responsible for the high failure rate of IT projects are major advertisers in the publications they write for). However, the failed approach to risk management is still the dominant approach to managing project risk. This chapter explains why each approach does not work. We will start off with one of the most commonly followed strategies.
The Pattern of Large Software Vendors
The development pattern of large software vendors is a particular problem for the idea of purchasing integrated suites.
All of the tech giants are really built around one item.
- SAP has one dominant item, the ERP system, and then a bunch of wasteful development and acquisitions around it.
- Oracle has the database, and then a bunch of wasteful development and acquisitions around it.
- Microsoft has Windows/Office, and etc…
- Amazon has two competent businesses — the Amazon Store and AWS. But strangely AMZN only makes money from AWS.
- Google has competent items in Google Docs, Google Maps and Google Cloud, but makes 84% of its revenues from the search engine.
These examples work against the idea of using a single vendor for a substantial percentage of one’s IT spend.
The Rule of One
Perhaps applying a heuristic to purchasing enterprise software. Which is that you never buy more than one item from any vendor. The reason being that each vendor probably only has one good item. This does not apply to say a cloud services provider as they are more a retailer (selling mostly other people’s stuff” than a software vendor.
If companies had followed this rule, they could have kept out of a lot of trouble. If SAP customers had stopped at ERP, they would have been far ahead of the game. If Oracle customers had never purchased anything but the Oracle database, they would have been far ahead of the game. If customers had never purchased anything from Microsoft but Windows/Office, they would have been far ahead of the game.
This is for two reasons.
- One, it reduces the account control of that vendor.
- Two, each vendor only has one really strong item. As soon as you move outside of that item, their effectiveness declines.
The Thinking Process Behind This Approach
Strategy 1: Purchasing Software From Large Software Vendors
Many purchasing companies think they will minimize risk by purchasing software from major “brand” software vendors. Both the large consulting companies and IT analysts are major proponents of this philosophy. I quote from the SCM Focus Press book Gartner and the Magic Quadrant: A Guide For Buyers, Vendors, and Investors, which explains this large vendors bias quite clearly:
“I am convinced that Gartner does not alter the numbers in its reports, but rather that Gartner selects a methodology that has the intended outcome of benefiting larger and more established vendors. Repeated observations of this outcome from a wide variety of Gartner reports make this conclusion unavoidable. However, it is unclear if this bias is due (either completely or partially) to the money paid by the largest vendors, or if Gartner is simply representing the interests of large buyers who tend to want to buy their software from larger vendors. Gartner knows its market very well, so it may simply be that Gartner has modeled their methodology based upon the criteria that large buyers themselves look for. To software-oriented people such as myself, the functionality of the application is the main focus, but to large corporations it is not the focus. Many other factors play into their decision.
There are four main reasons that can be reasonably given for Gartner’s large vendor bias.”
1.) Large vendors can pay more in consulting fees and for events than smaller vendors.
2.) Larger vendors can allocate more people to working with Gartner and knowing how to present the vendor’s products to Gartner. The book Up and to the Right—which shows software vendors how to get high rankings—is at least some evidence that a high ranking is not based simply upon the quality of a vendor’s software or “vision.”
3.) Most of the smaller software vendors are also much younger than the large software vendors and are simply not savvy to the analysts’ game.
4.) Gartner appears to base its research upon the preferences of the large buyers that are its core market, causing it to design its methodologies such that larger vendors perform better, independent of the actual software.
Are Larger Software Vendors Less Risky?
Gartner and other IT analysts repeatedly tell their clients that buying software larger software vendors means less risk – but when is the evidence presented to support this viewpoint. This approach is based on perception and the logical fallacy of argumentum ad numerum or argumentum ad populum. There are no studies that demonstrate that software from larger vendors is less risky than software from smaller vendors.
Let us think of a moment of what are the highest failure rate implementations in enterprise software. If there is one higher than Tier 1 ERP (SAP and Oracle) I would like to know what it is. Based upon the risk factor model at Brightwork Research & Analysis, which incorporates both application and vendor characteristics, as a group CRM is quite low, and not as a group, but there are several business intelligence applications that are quite low as well. There are also software categories like master data management, or MDM, whose success ratio is so low that they have ceased to be vibrant or commonly installed applications.
The Actual Success Ratio of ERP Projects
Only rarely is the actual success rate of ERP implementations quoted, and when estimations are made, the quoted figures show a wide variability. According to the publication, The Critical Success Factors for ERP Implementation: An Organizational Fit Perspective, the ERP success rate is roughly 25 percent. So, according to this source, 75 percent of ERP implementations are considered failures. But quoting just one study is misleading because the estimates are truly all over the map, as the following quotation attests.
“A study by the Standish Group estimates that 31 percent of projects are not successful (Kamhawi, 2007). Barker and Frolick (2003) suggest that 50 percent of ERP implementations are failures. Hong and Kim (2002) estimate a 75 percent failure rate, while Scott and Vessey (2002) estimates failure rates as high as 90 percent. Different statistics for the success or failure of ERP projects have been offered by researchers. In addition Bradford and Sandy (2002) reported that 57 percent of the companies they interviewed had not attempted to assess the performance of their ERP systems owing to a lack of empirically effective evaluation models.” – Measures of Success in Project Implementing Enterprise Resource Planning
Various research studies produce different values, but the range is between 75% failure rate and 50% failure rate is a 90% chance of going 178% over the implementation budget.
The Large Software Vendor Disadvantages
As a person who has worked in the enterprise software industry since 1997, and has worked with all sized software vendors, I can say that large vendors actually have a number of disadvantages that increase their risk. First, larger software vendors tend to provide lower quality information to their customers than smaller software vendors. This is estimated by Brightwork Research and Analysis as the “Quality of Information Provided” score that is assigned to every software vendor that is evaluated. Performing a regression between the Quality of Information Provided and the size of the software vendor shows a negative relationship between the size of the software vendor and the quality of the information provided. A major reason for this is a constant need for growth. I once worked for i2 Technologies – a supply chain planning software vendor, and as this company grew, its marketing and what it told customers diverged every more greatly from reality. I2 Technologies had another disease, and that was the disease of acquisition, which is often undertaken simply to meet the needs of the stock market to show growth larger than could be been accomplished with the growth of sales of applications that the company had internally developed. I2 purchased software vendors that appeared to me to be stock scams. One of the most ridiculous was the purchase of a company called Aspect for roughly $9.3 billion in overpriced i2 Technologies stock. Here is the quotation from Sanjiv Sidhu, the CEO of i2 Technologies at the time of the acquisition back in March 2000.
“The merger will create a B2B marketplace powerhouse with unmatched solution breadth and depth of functionality, unparalleled content, and a laser-focus on value creation,” added Sanjiv Sidhu
Actually, it did not do any of these things. The result of the acquisition, a major goose egg. Aspect never contributed to i2 Technologies in a meaningful way, but I was forced to sit through various indoctrination sessions of why there were such tremendous “synergies,” and why content management was so critical to supply chain planning (it isn’t).
The Distractions of Acquisitions
Acquisitions are major distractions for almost any company, however, they are particularly problematic for a software vendor, the quality of output is primarily determined by the organization and cohesion of the company and its ability to bring the right knowledge to bear in the right area in the right time and quantity. Acquisitions lead individuals overseeing, selling and working on applications that they don’t understand. Acquisitions are never pretty internally, as the management of the acquiring company tends to condescend to and dis-empower the leadership within the acquired company – leading many of them to leave. Furthermore, in the software vendors that we track, there is also a relationship between software vendors that grow through acquisition and the reduced sustainability of those companies.
I have also noticed that in the major enterprise software vendors like SAP and Oracle are much more focused on marketing and developing “partnerships,” than improving the quality of their software. This is basically – they are looking to build a social network rather than compete on your software. Marketing is a necessary function, but it can’t be the primary focus of a software company, and the marketing and sales can’t get ahead of the application’s capabilities. This is exactly what happened at i2 Technologies when I worked there. I recall protesting against the tactics that i2 Technologies was using with a person in a senior position in the company, and them answering my argument with
“You have to understand, this is how things are done. This is how SAP and Oracle do things and is why they are so successful.”
Real Innovation or Fake Innovation?
Secondly, large software vendors lag the smaller software vendors in terms of innovation. I have worked with SAP products since 1997. My exposure ranges from SAP ERP to the advanced planning suite – for which I have written five books, business intelligence, SAP MDM, SAP XI, and many other SAP applications. Some may it find it interesting that I have never once in all my work with SAP found anything innovative in the software. If I take the advanced planning suite, it is actually a copy of what I was doing back in i2 Technologies back in the late 1990s. This should not be surprising as SAP developed a “partnership” with i2 Technologies – broke off the partnership and then walked out with a lot of intellectual property so they could build their SAP APO advanced planning suite. Oracle is similarly not known for innovation, and within a couple of years of acquiring a company – and Oracle has acquired quite a few – that application is no longer seen as a leading application. The fact is that as with other monopolies, monopolistic software vendors do not need to innovate and do not need to improve their products because they pay large consulting companies and IT analysts to pitch their software for them. This lack of innovation is explained in detail in this article, Why the Largest Software Vendors Have Little Reason to Innovate.
In the business intelligence space, whatever the major monopolistic software vendors have to offer pales in comparison to smaller vendors like Tableau and QlikTech and of course the cost is much higher. One reason for this is that the major consulting companies, which have both a higher billing rate, as well as a strong tendency to lengthen out the implementations as its more money in their pocket, often implement major brand software vendors. However, the major software vendors have a trump card – they can buy up the best small BI vendors, something that will probably soon happen as the gap between the BI software that the major vendors have to offer and the BI software from the smaller vendors is quite glaring. These applications were themselves acquisitions (Cognos by IBM, Hyperion by Oracle, Business Objects by SAP). However, these applications are now seriously dated because they have not been developed in a significant way since the acquisition by each major vendor (again these vendors specialize in marketing and partnership development, not software development), which means that these software vendors need “fresh meat.”
Larger software vendors translate almost directly to more bureaucracy and slower response times. I work with software from both the largest software vendors and the smallest, and this is entirely obvious after many years of doing this. This generalization applies to every software category because it is the nature of bureaucracy. Smaller software vendors are a pleasure to deal with because you can get fast and honest answers to questions as to how things work in the application and what is coming down the pike. Larger software vendors, on the other hand, are miserable to deal with.
Dealing With the Bureaucracy of Large Vendors
The larger a software vendor is, the more layers and the more bureaucracy they have. This bureaucracy has a serious cost, which ends up being imposed upon buyers. It means the buyer has to be more persistent in following up on information requests. It also means the requests will take longer to receive responses, and on average the responses are less reliable because larger companies are more political. For instance, in large software vendors the support staff – which may, in fact, be outsourced – goes through political training so as to not provide honest answers that might make the sales department look bad. It also means that the buyer must pay more money for consultants to spend more time trying to find the answers to questions. I have been one of those consultants, and I have a Ph.D. in getting the runaround from several large vendors on technical queries. When I work with a smaller software vendor I often know the person in support personally and get a definitive answer many times with a single email. When I deal with a software behemoth like SAP, I contact a support person I have never met, who most often lives in a low-cost country that has English as a second language, and have to go back and forth with them as they describe testing things I have already tested. This second process can take weeks. These support people are in a difficult position because in many cases they are
A wide number of applications have been profiled at this site, and this research is conclusive that not only is purchasing from a large software vendor, not a valid strategy for reducing risk, in fact, the relationship is, in fact, a negative one – in those applications purchased from larger software vendors are on average riskier to implement than applications purchased from smaller software vendors.
Using an integrated suite is primarily a way that companies access a vendor’s worst offerings and how they increase the account control of vendors and consulting companies within their organizations.
The integrated suite concept or “sales pitch” has failed. And this means that decades of highly expensive advice by the major IT influencers has been wrong. The ERP system is the showcase example of how the integrated suit has not worked, but the value outside of ERP systems from vendors like SAP and Infor and Oracle is even weaker than the paltry returns from implementing and ERP system. The more that a company buys from a vendor, the worse the value that each new purchase brings the buyer.
 This logical fallacy appeals to a widespread belief; the fact that many people believe it means it must be true.
 An amazing story of inefficiency and its relationship to software vendors size is Microsoft. Microsoft has 90,000 employees – however, what is the actual output of each employee on average? Microsoft primarily owns a group of applications that it developed years ago. Almost all of Microsoft’s products were copied from other competitor applications (the Office Suite, Bing, SQLServer, SharePoint, etc.); therefore the creative output at Microsoft has always been quite low. Of these applications, none of them improve much from year to year, and they sometimes step backward (as is the case with Windows 8 – an operating system where they had years to simply copy the Apple IOS or Android OS, and still could not get right). This means 90,000 employees – most of whom are well educated and motivated and capable of creative work, do very little of it because of the entity that they work for.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
Search Our Other Software Risk Content
Enterprise Software Risk Book
Enterprise Software Project Risk Management: How to Control the Main Risk Factors on IT Projects
What the Book is About
This book is tied to the book Enterprise Software Selection. This is because the first place to manage risk is during the software selection phase, which is the opportunity to connect the best available application to the business requirements. There are of course many other risks that require enterprise risk management after the software is selected and implementation has begun. This is the first book to focus on the interpretation aspects of enterprise risk management in term of the information that is received from the main information providers such as consulting companies, vendors and IT analysts. The book explains how to triangulate on data sources, and is less about the mechanical aspects of enterprise risk management — which is covered in other books and online material. It is much more focused on providing practical information from years of experience in enterprise risk management and seeing the how companies can often struggle to find accurate information and unbiased advice on the topic of enterprise software decision making. Surprise, not all information providers in this area actually lead companies to risk-appropriate decisions, and the book covers how many of the techniques that implementing companies use as shortcuts.
This is the first book to focus on the interpretation aspects of enterprise risk management in term of the information that is received from the main information providers such as consulting companies, vendors and IT analysts. The book explains how to triangulate on data sources, and is less about the mechanical aspects of enterprise risk management — which is covered in other books and online material. It is much more focused on providing practical information from years of experience in enterprise risk management and seeing the how companies can often struggle to find accurate information and unbiased advice on the topic of enterprise software decision making. Surprise, not all information providers in this area actually lead companies to risk-appropriate decisions, and the book covers how many of the techniques that implementing companies use as shortcuts to reduce the risks of their projects actually increase the riskiness of their implementations.
- Vendor Risk Management
- Enterprise Risk Management
- Risk Assessment
- Client Specific Risk Assessment
A Book Based in Reality
The book provides many examples from real life project experiences, the emphasis being on the reality of planning projects.
Interconnected to Web Information
In order the keep the book at a manageable and easily readable length, the book also provides numerous links out to the Brightwork Research & Analysis site, where supporting articles allow readers to get into more detail on topics that interest them.