Why EHS Software Implementations Fail - How to Avoid It

Not using vendor suggested configurations

When implementing a new software, configuring the system around your existing processes seems like a smart way to go. The problem, as many organizations discover, is that automating a bad process simply delivers bad results faster.

Rather than shoehorn your current workflows into the system, be open to changing them. An experienced vendor who works in your industry day in and day out will know the best ways to get the job done, and their software will be designed around those practices. By using the vendor suggested configurations, you'll improve your processes and get the most out of the system.

Too many customizations

Unlike configuration, which involves changing parameters within the software, customization involves making changes to the software's underlying code. Heavy customization can lead to several problems during implementation, and is often a sign that your vendor is looking for quick fixes instead of long term solutions.

To understand why, imagine you're cooking a new dish. Stray too far from the original recipe, and you might have to throw the whole thing out and order pizza.

Similarly, if you customize a software too much, it's no longer the software you bought — and you won't get the results you heard about in testimonials, ratings, and reviews. Furthermore, every additional customization makes it harder for the vendor to maintain and troubleshoot your software, which can lead to higher costs for you.

Fortunately, EHS professionals and implementation partners agree that today's software systems can probably meet 80-85% of most companies' needs out of the box, according to NAEM.

No buy-in strategy

The NAEM EHS Software Buyer's Guide has shown that 71% of organizations expect the EHS function to take the lead in software selection and implementation. Other decision makers include executive management and IT

But in most research organizations, these decision makers aren't the only ones using the software. Getting buy-in from researchers and other employees involves more than just implementing the technology and telling everyone to "get on board". A successful buy-in strategy will have several key elements:

• Commitment: If your team is divided, make sure everyone comes together and commits to the chosen solution prior to the start of implementation.
• Clear success criteria: Define what's important for each role and user persona — not just for the leadership team.
• Realistic expectations: Software offers many benefits, but it's not a magic bullet. Make sure your team is realistic about what software can and cannot do for your organization.
• Role-oriented user testing: After configuration, user testing for all roles and personas provides an opportunity to bring forward any issues before you launch.
• Early adopters: Look for an early adopter user base to roll out the product so you can adjust decisions on a smaller scale.

Poor data integrity

Ever heard the saying "garbage in, garbage out"? It’s not just a myth – a research summary published by the University of Hawai'i found that 88% of spreadsheets contain errors. If you simply import this bad data into EHS software, you'll get bad insights — which can lead to bad decisions.

To avoid this, it's important to make sure the data going into your new system is clean and accurate. While your software vendor can help, ultimately you know your data best and must take charge of your data quality.

On a similar note: Accept that your data will never be perfect. Lab spaces change every day, so talk to your vendor about how best to work with the data you have today.

No vendor-side dedicated project management

Project management is the process of planning, monitoring, and delivering a project that meets specific goals — and it's essential to your software project's success.

For advanced implementations, your vendor should put you in touch with an implementation manager. This person will help outline your requirements, formulate an implementation plan, make sure your project stays on track, and keep the lines of communication open.

Lack of software-side support

When you think of software support, you might envision submitting a help desk ticket when you can't log in. However, good support involves more than troubleshooting.

Does the vendor have a customer support team available when questions arise? Do they have a posted turnaround time for issue resolution? Is their team proactive about reaching out to customers and making sure everything is going smoothly? And perhaps most importantly, do they make you feel comfortable reaching out for help?

No continuity of vendor support

Based on NAEM’s research, it’s not unusual to be back in the market for additional functionality or a replacement within five years of purchasing an EHS software training system.

That's why it's so important to look for a vendor who's committed to your long-term success — not just getting the sale. The vendor's continuity strategy should involve ongoing meetings to ensure the original success criteria are being met, review any changes in your organization's needs or strategy, and make adjustments when needed.

Insufficient training

First: A thoughtfully designed system eliminates the need for extensive training and documentation. Look for software that provides a clean user interface and streamlined workflows so that researchers can get into the system, do what they need to do, and get back to their research in the shortest time possible.

That said, no matter how user-friendly a system is, training is necessary to help your team feel confident performing tasks independently. Find a vendor who offers different levels of training for different users, such as quick start guides (like the ones that come with a new TV), job aides, and other hands-on training.

Long customer time-table

According to NAEM, the process of selecting and implementing a software system takes the average buyer about 18 months. Unfortunately, some teams have experienced implementations that drag on for years or are never completed. Other projects come up, life gets in the way, and your software implementation gets pushed to the bottom of the list.

That's why it's so critical that you and your vendor have a mutually agreed upon implementation timeline. This timeline should take into consideration factors like competing projects, staff availability, and PTO. Once you both sign off, everyone knows that you're driving toward that timeline.

Too much change, too fast

There are two approaches to software implementation: "big bang" or "rolling". A "big bang" implementation — the traditional approach — occurs all at once, which can cause a shock to the organization.

A rolling implementation, on the other hand, occurs one module at a time. This method offers several advantages. As the name implies, a rolling implementation starts slowly and gathers momentum like a snowball rolling down a hill. The success of each module implemented builds confidence and energizes the team, leading to higher adoption rates across the company. And instead of buying every module out of the gate, a rolling implementation lets you dip your toe in and add on when you're ready.

About SciShield's implementation strategy

Our company was founded by researchers, for researchers. We pride ourselves on our product being easy to use, with thoughtfully designed workflows built around industry best practices. We're committed to helping you succeed through ongoing project management, support, and training. We're perpetually learning and improving, so that each implementation is better than the last.