Why EHS Software Purchases Stall (And How to Get Unstuck)
If you've ever watched an EHS software purchase quietly lose momentum, you know the problem isn't usually the technology, it's everything around it. We explored this in a recent webinar, where Catryna Jackson, Global Sustainability and Environmental Product and Solutions Advisor at Evotix, covered the vendor perspective and we dug into the organizational dynamics that cause these projects to stall. You can watch the full recording here.
Below is the practical framework from our side of the conversation, whether you're just starting an evaluation or stuck in the middle of one.
Most Organizations Do Not Fail Because the Market Lacks Capable Solutions
We say this a lot, and we mean it: most organizations do not fail to select EHS software because the market lacks capable solutions. They fail because they approach selection as a feature comparison exercise rather than a decision architecture problem. We get on meetings with potential customers who are asking detailed questions about whether a platform can do a specific bullet list of things they have seen elsewhere, instead of really examining how they are going to make this decision in the first place.
The questions that actually move you forward are different. What are the problems we need to solve? Where would failure be most costly? Can this system evolve with us? What decisions are we trying to enable? And critically, what is the role of this software for our organization? Is it just safety software, or will it also encompass workers' compensation, occupational health, and contractor management? That last question matters more than people realize, because those functions often have their own budget line items. If you can bring multiple departments to the table and split the investment, your business case gets significantly stronger.
Problem First, Tech Second
Regardless of whether you are talking about software, wearable technology, or AI, if you are going into shiny new object syndrome and looking at tools because they seem interesting but they are not tied back to a business problem, you will struggle to answer the most basic question: why are we doing this? That answer needs to be something your entire team can state clearly, not just the person managing the project.
We recommend building a steering committee early. You need an executive sponsor, a project champion who is running the day-to-day process, a few people from different levels within the organization, and one or two cross-functional stakeholders from IT or other departments that will be affected. Everyone on that team should be aligned on the top three to five problems you are trying to solve. It does not mean there are not more problems, but you want to be able to tell a cohesive story.
A practical tip: when you are having pre-demo conversations internally, whether through surveys or Zoom calls, record those conversations and run the transcripts through an AI tool. You will quickly see three to five issues that everyone keeps bringing up. We suggest the transcript approach specifically because what someone writes in a form is often very different from what they say out loud, and the spoken version tends to be more honest about what is actually broken.
Be Open to Changing Your Process
One of the biggest things we work through with clients during requirements gathering is getting them to explain their current process and then asking directly: are you open to change? Specifically, when your investigation process requires five levels of approval before it can be closed and you have not built in severity levels to differentiate those steps, you are going to fixate on how customizable the system is. There is definitely a threshold where a platform should be flexible enough to accommodate your needs, but that cannot be the single deciding factor in whether you move forward.
We always tell clients that most of these platforms do fundamentally similar things at this point. You could take the logo off of a proposal response from three different vendors and probably not be able to tell the difference in terms of available features and modules. So instead of trying to make the platform fit an inefficient process, step back and ask whether this is an opportunity to streamline. Be willing to shift left and remove some of the clutter from your workflows before you start scoring vendors on customization capabilities.
Diagnose, Triage, Act
We use a three-step framework with clients who are stuck: diagnose where you are, triage what needs attention right now versus what can wait, and then act on the fixes. The triage step is important because not all blockers are equal. Some will stop your project entirely, and some are speed bumps that slow you down but can be addressed over time.
Showstoppers that require you to pause and fix before moving forward:
- No problem statement. Saying "we need software" or "we have been doing it on Excel" is a starting point, but it is not a problem statement. What is one step back from that? We are using Excel and we have no clarity on where people are getting hurt. We cannot track contractor activity because they do not have company emails. Problem statements do not need to be detailed, but you need to start naming them.
- No decision authority. Someone needs to be able to say yes or no. Legal, finance, IT, whoever is signing on the dotted line, you need to know who that person is and what the approval gates look like based on the amount you are trying to spend.
- Executive sponsor turnover or champion departure. VPs move around frequently. We have seen projects where the executive sponsor who was fully bought in left the company right before the finish line, and the project champion had to start over convincing a new person. This is also why shared buy-in matters so much. If the institutional knowledge and enthusiasm lives in one person's head, the project is fragile.
- No validated budget. If you are afraid to ask your VP for the number, you are probably not ready to buy. These things cost money, and in the current economic environment, budget assumptions can shift daily. Make sure you are validating frequently, especially if you are not at the director or executive level where you would naturally be aware of changes.
Speed bumps that slow you down but can be resolved:
- Requirements that keep changing. Freeze your must-haves after the shortlist stage. New ideas and feedback are valuable, but they belong in a phase two backlog, not in your active decision criteria. If you keep adding requirements, you will end up in demo purgatory and never be able to make a decision.
- Overloaded demos. We typically do not do full demos until we are at a shortlist of three to five vendors. Sitting through ten or twelve demos exhausts your stakeholders, confuses the comparison, and signals to vendors that you may not be serious. If you must do a large initial round, keep it very small (just you and one other person) and focus on evaluating the user experience rather than trying to cover every module.
- Stakeholders who do not know the project exists. This one bites people during implementation. If no one told IT that you will need API integration support, or that the people team needs to help with HRIS and SSO configurations, those conversations need to happen during the sales process, not after you have signed the contract.
- Overemphasis on future-proofing at the expense of current needs. "What are you doing with AI?" is coming up in every vendor conversation right now. Every vendor is at a different maturity stage, and marketing will make you think one is far more advanced than the others. Focus on your core needs first. Having AI-powered suggestions in your software is not going to solve your occupational health problem if the fundamentals are not in place.
Actions You Can Take This Week
If you only do one thing after reading this, pick the blocker that would unlock the most progress and start there.
For problem identification: Start documenting what is broken, organized by user group. Quantify the impact where you can. Run those verbal transcripts through AI to surface recurring themes, and then share what you find with your steering committee for feedback. Get confirmation from your executive sponsor (in writing, even just an email) that they agree with the problem statements and the estimated cost of staying in the current state. That documentation will be critical when you present to the final decision maker.
For decision authority: Meet with your executive sponsor and ask directly who makes the final call if the team cannot reach consensus. Document it. Communicate it to the team. Everyone needs to understand that while their feedback is valued, someone will ultimately make the decision and the project will move forward.
For budget: Ask for confirmation of your number early. Start building the business case from day one, not at the end. Let it be messy and flexible at first. It will take shape over time, and building it incrementally feels far less overwhelming than treating it as a separate deliverable at the end of the process. Become a partner to your procurement team early as well. We have worked with companies where the procurement queue alone was three to six months, so getting into that queue sooner makes everything flow faster.
For evaluation: Build a scorecard. Must-haves are pass/fail, nice-to-haves get a one-to-five scale. Ask the vendor to score themselves against the same criteria. Write a demo script based on real scenarios from your organization and use the same script for every vendor so your stakeholders can make direct comparisons. And do not just look at licensing costs. Model the three-year total cost of ownership, including implementation, data migration, internal resource allocation, and scaling. We have seen technologies where the pilot looked great but the three-year cost to roll it out to a hundred additional sites was so far out of budget that it did not matter how good the product was.
If You Have Budget Constraints, You Still Have Options
If the budget conversation is not going your way, consider what tools your company already has. If you are on Google Workspace, there are Apps Scripts and automations you can build. If you are on Microsoft, Power Apps offers a way to digitize processes beyond Excel without a formal software purchase. The reason we mention this is that these interim steps can actually strengthen your case for dedicated EHS software later. When you can demonstrate that a digital process is working but you have pushed it as far as the tool allows, the argument for a purpose-built platform becomes much more concrete and much harder for leadership to dismiss.
Signing the Contract Is Not the Finish Line
One thing we want to be transparent about is that selecting a vendor does not guarantee implementation success. Vendor timelines are built on best-case assumptions, and every organization is different. We are currently in the middle of an implementation for a relatively simple project with a brand-new startup, and there are still bumps in the road because the person responsible for systems also manages everything else in HR. Her workload is slowing down the HRIS integration, not because she is not great at her job, but because there simply are not enough hours in the day.
The work you do during the selection process should feed directly into your implementation. You should not have to start from scratch on requirements when the vendor kicks off the project. All the documentation, problem statements, stakeholder alignment, and process decisions you make now will save you enormous time and headaches later.
And if you have been stuck for six months or longer, do not be afraid to bring in outside help. Sometimes you need a neutral, vendor-agnostic party to facilitate the evaluation, especially when there is emotional bias toward a specific platform or when the internal team simply does not have the bandwidth to drive the project forward alongside their regular responsibilities.
Not Sure Where to Start with Your Software Selection?
If this post surfaced some uncomfortable truths about where your EHS software project stands, start by understanding your organization's overall digital maturity. That context will help you prioritize which blockers to address first and build a stronger business case for the investment.
Syncra's EHS Digital Maturity Assessment takes 10 to 15 minutes and scores your organization across strategy, technology, process, people, and data. You get a maturity score, an archetype that names your situation, and prioritized next steps.