There are a lot of unknowns when it comes to buying enterprise environmental, health, safety, and quality (EHSQ) software for the first time. You’ve embarked on an ambitious project that will have far-reaching positive impacts across your organization. But the truth is, software system selection is more than just a project. You’re choosing a technology partner that will help you digitize and digitalize your processes, which will become the backbone of your programs as well as play a critical role in your organization’s overall digital transformation initiative.

But, for most of us, software is nebulous until we get our “hands on it” and begin to explore the system ourselves and start understanding the connections. This only makes your journey to procuring a new solution harder. During your evaluation process, you’ll frequently wonder if the software will work for your company.

If you’re just starting your software journey, you’ve probably got a lot of questions and a long list of worries. You’re not alone. Many EHSQ professionals we’ve spoken to have dealt with (and successfully overcome) first-time buyer fears.

Let’s walk through five of the most common first-time buyer fears and discuss what you can do to overcome them:

I’ve never bought enterprise software before and I’m not sure what steps to take. 

 This is probably the most common fear for any first-time buyer. It can be an extremely confusing landscape to understand and navigate. There are likely internal IT and procurement processes that must be followed and stakeholder buy-ins to secure. You are balancing these requirements while, at the same time, technology vendors are vying for your attention and trying to get as much detail as they can get about your project. And let’s not forget, you still have your actual day-to-day activities and responsibilities to manage.

Take a deep breath, exhale and relax. You’ve got this. Don’t be afraid to lean on your IT team for guidance, knowledge, and project management skills. They know software, but they may not know your business processes and workflows. This is an opportunity for knowledge sharing and collaboration. It’s important to remember that this process is not linear. Below are a few key steps in the process, but it’s important to remember that there will be points where these steps overlap or you’re working in parallel on a few of these steps.

• Identify your requirements and project scope.
• Get buy-in from executives and peers.
• Build your business case and gain the required approvals.
• Shortlist vendors and demo their products using your data and use cases.
• Select your vendor and begin contract negotiations.
• Develop your implementation plan and begin to implement the software.

For an in-depth discussion about the process of buying enterprise software, read our Ultimate Guide to Buying Software eBook.

I’ve heard that so many software projects fail. I don’t want that to happen here. 

Projects fail for a myriad of reasons, including poor planning, misunderstanding of the problems you’re trying to fix, scope creep, budget issues, and, sadly, a lack of buy-in from employees. It’s always beneficial to seek an executive sponsor to help navigate through the challenges of competing projects, employee buy-in, and budget constraints. Another way to counteract these risks, is to have a solid project plan that lays out the business case (pro tip: your technology partner can help you with an ROI calculation), current issues, what it is that needs to be improved or enhanced, and how you’re going to accomplish this with technology. By creating this document, you can avoid scope creep (i.e. adding in additional functionality that isn’t needed now or that was never scoped out as part the original requirements). Doing these things will reduce the risks to your project budget and timelines. Your project plan should also include a formal communication strategy to get buy-in from employees; however, the best way to get buy-in is through strong leadership from senior management and executives. If they are onboard and visible, employees will be too.

I’m stressed about budget overruns and hidden costs. 

First, let’s talk about budget overruns. This is a huge concern for everyone who has ever implemented software. You should always build in project contingencies into your budget so that you don’t have to go back to executives and ask for additional funds. You may also want to consider asking your technology vendor and any third-party implementation partners for fixed pricing. This will shift the budget risks to them.

Second, and most importantly, if your project is properly scoped out, and you have a vocal executive sponsor, the risks of budget overruns will be small.

Hidden costs on the other hand can derail your project quickly, especially if they are part of the annual licensing agreement. Meaning, these extra costs won’t be covered under your initial project budget. Unfortunately, many EHS professionals learn this lesson the hard way. According to NAEM’s latest research, many organizations are now considering replacing their existing EHS software systems as they feel they were oversold or misled during the initial purchasing process regarding customizations and other hidden costs. To avoid ending up in this situation, you must read the fine print. Are there data storage fees? If you’ve chosen a cloud solution, are there fees for using too much bandwidth or data center fees? Is your solution True SaaS or are there hidden costs for upgrades? If you have an IT project manager, make sure you ask them to review and identify those services.

What if we end up with something we don’t use? 

There is no reason this should happen, but it does. All. The. Time. The first thing to assess is whether executives are committed to change? This is where the power of an executive sponsor really comes into play. Your sponsor should be evangelizing the initiative across the organization, removing roadblocks, and securing commitment from the C-suite to the shop floor.

The next way to ensure you avoid this issue goes back to your change management process. To avoid this, work with your technology partner to setup a proof of concept trial. If you’re convinced that the technology solution fits with your company’s processes, consider phasing the project in by setting up pilots at key sites. This will enable you to get feedback from users and identify gaps in the technology, your processes, and training before you roll things out to the entire organization.

What if the software doesn’t meet our needs?

Part of your buying process should include a demo of the software in action, so you can ask questions and get a better idea of what the solution can and cannot do. After a successful demo, you should also consider checking references. You wouldn’t hire a new employee without doing a reference check, so why should software selection be any different? Be sure to ask your intended technology partner for references from similar sized organizations in similar industries.

While no technology solution is perfect, if you have properly scoped your project, there’s no reason the technology shouldn’t be able to meet your organization’s needs – especially if it’s an integrated EHSQ solution (as opposed to a configuration of SharePoint, Lotus Notes, or a specific point solution that gets sold as an enterprise platform). Good technology partners are always willing to listen to client feedback and look for solutions to problems either through simple configuration changes or more detailed product enhancement projects. Enhancement requests can be especially beneficial to the technology partner if they address critical functionality that is a gap in the application. So, if you’re not satisfied with the application, don’t be afraid to discuss the issues with the technology partner. Remember, this is a partnership: your success is their success.

Summing Up 

Software implementations can be complex, but you can reduce the risks involved with solid planning, strong technology partners, and solid change management processes. Look for vendors with a proven implementation track record (and be sure that this includes companies like yours in your sector).

Understand that not everything will go 100% smoothly and build contingencies into your timeline and budget to address these risks. Your IT project manager should also be able to help you identify other contingencies the project should have to ensure successful implementation and long-term use. They can also help you defend against things like scope creep, resistance to change, and unknown functionality gaps in the software. Leverage your executive sponsor and keep all stakeholders up to date. All these issues can be planned for in advance at a high level so that you’re able to confidently mitigate them if they should come up.

Next Steps 

For more information on how to navigate the procurement process and ensure a successful technology program, download the eBook, The Ultimate Guide to EHSQ Software Success.