Let’s face it: shopping for enterprise-level software is hard. One moment you’re looking for more information on a tech firm’s offerings, the next you’re being dogged by salespeople calling, emailing, and sending smoke signals from your office parking lot. It’s enough to make you cave to the first reasonable offer – but there are far too many reasons why you shouldn’t.

Buying a solution off the shelf isn’t right for everyone. Likewise, building a homegrown solution isn’t a good fit for every company. There are a number of considerations to take into account before you dive into back-to-back sales meetings with technology partners or sign a contract for custom development.

Here are just a few questions to ask before making a decision in the Build vs. Buy debate:

  • Will the solution make you change your business processes?
  • How customized are your needs? Can off-the-shelf products meet them?
  • Do you need a modular solution (i.e., one that allows add-ons and expansions)?
  • How many employees will use the solution, and how will you coordinate training?
  • Does your team have the expertise to build what you need?

It’s important to form your expectations based on your unique limitations and requirements. If you’re operating on a tight budget, you may need to stick with a spartan-yet-functional solution from the App Store. If you’re seeking novel features for a highly specialized use case, you may end up paying a lot more than a monthly software subscription fee.

Expectations vs. Reality

Even the biggest companies with burgeoning budgets see their internal software projects fail to deliver. According to the 2015 Standish Group CHAOS Report, out of 50,000 companies reviewed, fewer than 30% of large-scale IT projects are delivered on time, within their budgets, and with satisfactory results. With a failure rate that high, why do companies both big and small still try to do it all on their own?

They aren’t oblivious to the pitfalls of internal development; the problem is that they start by asking the wrong questions and supplying the wrong answers. For example, when setting a budget, a company that specializes in EHS may be familiar with end-user software prices, but estimating development costs is well outside their wheelhouse. When they ask what a realistic budget should be, they compare it to the market rate of third-party developers or finished products.

Similarly, you shouldn’t expect an IT department whose primary focus is the maintenance of commercial applications to create a homegrown solution from scratch. Although your IT crew might have a wealth of coding experience, managing a project in IT is incredibly time-consuming, labor-intensive, and prone to delays. When inexperienced IT departments bite off more they can chew, it means hiring freelancers to pick up the slack – usually at a costly and budget-bursting premium.

The Prefab Problem

When companies consider buying a prefabricated solution or hiring a third party to build one for them, budget usually isn’t the primary concern. They want software that functions as expected with assurances of quality, reliability, and dedicated support. What they forfeit in flexibility, they gain in confidence. At least, that’s what they think they’ll get. In reality, out-of-the-box solutions often cause more problems than they solve.

First, there’s the cost of ongoing maintenance and “hidden fees” for additional development and functionality. Some enterprise software companies won’t even attempt to accommodate novel or unique use cases. They expect you to add even more software to your tech stack if you need solutions outside of their focus: if it’s not on our feature list already, it’s not our problem. Simply put, most off-the-shelf solutions are built to add just enough value to make a sale.

Second, many solutions are unable or unwilling to meet your current process halfway. Instead of integrating your existing methods, databases, and EHS strategy, they force you to adapt your operations to their software. That requires re-training your workforce, painstakingly converting all your old data for their new system, and lengthy troubleshooting sessions. Even some platforms that boast easy database conversions won’t provide perfect-fit, one-to-one ratio digital versions of your current forms, processes, and workflow.

Finally, besides the growing pains of change management, out-of-the-box solutions are routinely inflexible. The go-to-market approach for some tech developers goes like this: “To catch the most fish, we’ll cast the widest net.” As an end user, that typically means the product you receive is shallow, basic, and only suited for the lowest common denominator in your industry. These solutions rarely merit the moniker of “jack of all trades” and more commonly align with “master of none.”

The 80/20 Methodology

By now you might be asking yourself: “If both approaches have so many pitfalls, which one is actually right for my company?” The good news is that it’s not an all-or-nothing decision. There are options along the software development spectrum that allow you and your IT department to be as involved or absent as you wish. In my own experience, I find that large companies benefit most from the “80/20” approach to enterprise software development.

The 80/20 methodology is a hybrid approach that neatly dovetails the best of both out-of-the-box solutions and fully homegrown development. The initial responsibility rests on the software provider rather than their client: they supply a solution that already meets 80% of their customer’s needs. During early development, they work hand-in-hand with the customer as a technology partner, taking the time to understand their unique processes and challenges.

It’s during this early phase where the 80/20 approach easily outclasses homegrown software in terms of visibility and flexibility. Even if your use case is entirely unique, you can still work with an already functional framework. Likewise, while 80/20 development may not have every module in place at the outset, its open-handed approach to add-ons and configurable elements means that whatever features you want can still be added.

EHS software providers who emphasize partnerships over products and renewals over one-off sales will strive to keep your business by meeting your requirements and listening to your needs. If you’ve ever tried to use an EHS solution for “off-label” purposes just to avoid adding another service to your tech stack, you know it’s like forcing a square peg into a round hole. That’s why your software should be flexible, adaptable, and reflect your company’s real needs and challenges. Most importantly, it should continue to add value over time instead of nickel-and-diming you at every turn.

Conclusion

The 80/20 approach is a foundation for success, but you shouldn’t cave on critical requirements or functions simply because a seemingly flexible software provider claims to have your best interests at heart. If you need specific features, such as on-premise server hosting or offline-first mobile functionality, don’t be afraid to ask the tough questions: “We need this feature. Can you implement it or not?”

A good EHS software company will be honest with you. They might say it’s impossible, but they can offer a better, more optimized approach to your organization’s challenge. At the end of the day, it’s impossible to know whether a solution is a good fit for you until you see it in action. Whenever possible, demand proof. Get your hands on a demo, critique it, and request revisions. A company that is willing to understand your organization’s unique challenges and technology goals is one that will continuously improve to offer value for years to come.