Why Custom Development Should Be Expected for Nearly All Applications

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Package vendors and consulting companies overstate the degree to which package software can meet requirements.
We cover an assumption of the percentage of requirements that are covered by package software.

Introduction

Vendors and consulting companies present a false assumption. This assumption is that package software meets most to nearly all of the business requirements. This is part of the sales process and is an assumption that tends to be unquestioned by customers. IT analysts like Gartner and Forrester never question this assumption, as vendors pay them.

How it Works

If you look at vendors, they will typically say that their application does it all for the customer’s requirements. I address this in the article When to Buy Package Software Versus Custom Development.

But since I wrote this, I now consider using a packaged solution without custom development as just a fantasyland expectation. Nearly every requirement — unless it is something very narrow like an invoicing system, should expect custom development.

Then the customization shows up as a surprise during the project. I have come to think of all applications as just starter kits. But this is repeatedly hidden from customers during the sales process.

We have an application for forecast error measurement and MRP parameter maintenance. However, when I receive requirements that don’t fit with what the Brightwork Explorer does all the time. And I normally can’t find fault with them because they are typically well-founded.

How Vendors and Consulting Firms Gaslight their Customers and Clients

The standard vendor approach is much different than this. Usually, a vendor will try to push requirements that they can’t cover into their application or say the requirement is not valid. SAP is expert at doing this, using the false construct of “best practices” to try to convince customers that any requirement that is not met by SAP’s functionality is a false requirement and is an error on the part of the customer. We cover this in the article How SAP Uses Best Practices to Control the Implementation.

It’s a type of mind control. Like if one were a car dealer that only sells sedans and a person wants a 4×4, you say

“Well, you can put big tires on this sedan, and it will work.”

This is driven by what the car dealer has to sell, not what the requirements are. The salesperson may say you don’t actually need anything but a sedan in the first place.

The Assumption of Custom Development

This way, we add custom development and then build a new application to address that requirement.

I just received a requirement for aggregated cross SKU EOQ that no packaged vendor offers. We are going to create a demo of that functionality. The funniest thing about this is the person making the selection expected a vendor to provide this. He could not believe it when I said it has to be a custom development.

The reason for this is simple. I don’t think there is a general understanding of how generic the functionality in supply planning applications actually is. Most of the differentiation is at the procedure, and it turns out that most of the complex procedures or highly differentiated procedures don’t work very well in practice. Once you look behind the scenes in the various applications, most vendors are offering something very similar. But it means cutting through the marketing hyperbole to figure it out.

Once you include the reality of implementation, the differentiation becomes far less than the actual development.

This same approach applies to any vendor. The vendor should only be expected to meet a percentage of the requirements. There will be custom work required. Should the vendor with the highest percentage match be the winner?

Not necessarily.

Some vendors are going to try to overconsume the company’s IT spend with account control tactics.
Some vendors are untrustworthy.

Some vendor may have a 60% coverage versus a 50% coverage for another vendor, but the second vendor’s application is much easier to use, and much less expensive and offer better terms.

When we make a software selection, we start with requirements. We work off a Google Sheet so that anyone in the client who is part of the selection can see it as it is built. The selection includes all of the requirements, and each would be coded for which each application meets, and then which is the custom development. Then the sheet would be scored, and then the pricing included so we can come to an overall estimate for implementation and maintenance costs. Each cell would be a rating, so 1 to 5. When summed, it would then come to a quantitative score.

How to Work This Assumption into Software Selection

As soon as one moves the mindset to a “percentage” of functionality covered, from getting a “total solution,” it changes the software selection process’s interpretation.

When I wrote a book on software selection, I did not think in this way, so I did not address this issue. Instead, the book’s focus was on how to protect oneself from the input from consulting firms and vendor salespeople, as these entities provide unreliable information.

If we look at the major consulting firms, they guide their clients using the same illusory assumption — that there is the best vendor that covers nearly all the requirements.

When I have brought up shortcomings in the past to consulting firms related to functionality or other gaps, they don’t typically have a good response but tell me to…

“not be negative.”

And that…

XYZ vendor is very large and is, therefore, “approved.”

These are canned responses that are intended to suppress the analysis rather than realize the implications of gaps. The role of consulting firms is normally to partner with a vendor or set of vendors and then act essentially as brainless cheerleaders for that vendor.

Covering Up for Custom Development

Vendors and consulting companies rephrase or recategorize what custom development is. Relying on Excel, custom reports, etc.. are merely different ways of accounting for the application’s inability to perform the requirements, which means there are gaps.

Go to top

Conclusion

If a vendor and consulting firm tell me that 90% or some high percentage is “out of the box,” I know that this will turn out to be inaccurate. It is fool’s gold to expect anything but the most narrow applications can be used independently of custom development.

Article Comment

When sharing this article, it was pointed out that many CIOs know this.

However, I have been in several sales presentations, and I have not seen the “90% out of the box assertion by vendors challenged.”

I advised a company that did not realize that they would get completely ripped off by SAP’s HEC, as I cover in the article Our Comparison of SAP HEC with Virtustream Versus AWS Analysis.

That should have been obvious, I laid it all out for the CIO, but they did not want to hear it. There is very little interest in fact-checking on the part of CIOs. And this extends to how much of their application purchases will require custom development.

Educated CIOs?

I also question whether many CIOs either have the time to educate themselves or if, in many cases, they sell out the interests of their companies for their own careers, as I cover in the article To Whom Does Your IT Department Owe Its Allegiance?

Finally, if CIOs had figured out that best practices are fake and large amounts of customization, they would not accept the project estimates by vendors.

I have a series of timeline estimators and TCO estimators at this link, The Brightwork Project Planning Packages and The Brightwork TCO Calculators. They are based upon long-term research, and they do not comport with what the vendors say their TCO and project durations are.

If I were to present these estimates to a customer or prospect and worked for a vendor, I would be fired from that vendor. So I think we have to ask if a significant percentage of CIOs are so well informed, why do things seem to repeat themselves continually? This is particularly true of ERP systems. Sales had personally pressured me to minimize the duration, and even when we presented unrealistic plans. I don’t recall the CIO or director pushing back. I was told on several occasions that all the salesperson would need to do was say I was standing in the way of the sales, and I would be immediately replaced.

CIO’s Pushing for Unrealistic Expectations

CIOs are often presented as the mature people in the room that help moderate salespeople’s influence from the vendor. However, this characterization is unwarranted. In most instances, they also push the sales team to see if they can get it done “faster.” Which, of course, assumes very little custom development. CIOs average a 3-year tenure at companies. This is enough time to make a major selection, have the implementation run into problems and the go-live disappoint users and then move on to the next company. They lack a long-term incentive to buy applications that work versus adding vendors to their resumes.

How Much Media Focus is on The Degree of Custom Development?

You will notice that none of the opinion-shaping entities from IT media to Gartner/Forrester will admit or focus on this subject. And the reason is simple — vendors pay them, Gartner is paid over $1 billion per year from vendors. Overall the amount of custom development on projects is hidden. And it has been since packaged software first began to be sold.