EHS proof of concepts can sometimes feel like a never-ending rabbit hole. They can be time-consuming, difficult to organize, and might even feel pointless. Yet, software proof of concepts, and proof of concept testing, can provide immense value to organizations that are looking to identify the right partner, no matter their ultimate end-goal.
In this blog, we will explore what we mean by proof of concept, why it’s important for software evaluation and selection, and some essential steps to bear in mind for those about to undergo the process.
What Is Proof of Concept (POC)?
A proof of concept (POC) is evidence obtained from a trial or pilot project designed to demonstrate that a product idea, business plan, or any other type of product development is feasible. For example, within Cority, our product teams may work with a small group of trusted customers to explore the effectiveness of certain product enhancements within our platform. Such as, the introduction of new custom workflows or tools. These ideas are tested through a POC trial, and the results are gathered to help stakeholders better understand benefits and risks of the innovation and identify areas of improvement moving forward. This definition may feel a little broad, so let’s move on to what this means within software evaluation.
Why is POC important when evaluating a software or technology partner?
When using POCs for evaluating EHS software and partners, some of the same principles mentioned above still apply. As an organization, users explore which solutions will help resolve issues or expand capabilities in a new area. It might help to think of it like a business plan for your EHS department – testing assumptions and ensuring that the software will enable the organization, and its users, to resolve some of their critical business issues. Consider it a “test drive” for whatever workflows or procedures are being considered.
As such, POCs can;
- Help to fully flush out these benefits and limitations
- Validate any preconceived ideas about what software can deliver
- Enable the collection of feedback early in your buyer journey
- Help ease concerns from senior leaders, budget holders, and internal stakeholders
- Force organizations to think ahead and consider possible hurdles to deploy and use the solution
- Challenge any internal assumptions about the best ways to achieve goals
How to Successfully Evaluate an EHS Software POC
As established, POCs can essentially act as a test run for EHS software. As such, organizations will need to create evaluation criteria to help demonstrate whether the solution will achieve the desired end results. Consider the overall performance of the solution, how it enables teams within the organization to achieve desired goals and objectives, and the general ease of use and navigability of the platform. POCs tend to exist within a relatively short timeframe, so feedback will need to be gathered quickly. The following steps can help to make the evaluation process more straightforward.
-
Defining Your Problems and Solutions
POC evaluations can be highly subjective – often devolving into futile discussions amongst stakeholders about their personal preferences regarding font styles or where they think logos should be placed. To avoid those arguments, it’s critical to define your organization’s goals for the POC. What is your organization trying to achieve with the POC? What questions need to be answered that cannot be answered now?
-
Identify your Technology Partner and Internal Stakeholders
To utilize a POC, a partner will need to provide said POC! We’ve written about identifying the right EHS and ESG SaaS service provider at length in multiple articles, so we won’t go into depth here. Picking the right software providers to include in the POC process – not to mention the right mix of internal stakeholders to participate in the evaluation – is essential. Remember, POCs can help to determine the right partner, but the way they work with your organization, along with what expertise and resources they bring to the table are also all essential factors to consider in the evaluation process.
-
Clearly Communicate Timelines and Constraints
Being clear and upfront about POC timelines, scope, and budget from the word ‘go’ is simply good housekeeping. By establishing realistic parameters, your organization is in the best possible position to get the most out of the POC. Equally, try to remember that POCs are not designed to be a true reflection of the tool that will be used forever; they serve as a glimpse into the world your organization will access once the chosen software is implemented.
-
Creating a Rubric
Another area we have written about at length is how to define success in a measurable, impartial way. One of the goals of a POC is to ensure no preexisting biases are carried into vendor selection. A way to counteract these biases is to create a scoring rubric that aligns with the goals outlined in the previous steps of this process and introduces a degree of objectivity and repeatability when evaluating multiple software vendors. The creation of a rubric can help in making specific, measurable goals. For example, “We want to reduce the time taken to complete incident reporting by 5% in the next 5 years” is a measurable goal, whereas “We want to make our incident management process better” is not.
-
Including End Users
It’s not uncommon for organizations to forget that a POC is the window into a product and process that will be put in the hands of their colleagues later down the line – focusing on theory and perception rather than involving the end users from the start. Employee engagement levels and overall solution adoption can be positively impacted if end users are brought into the evaluation process early on. Additionally, end users may also help to identify previously unidentified process issues or challenges that can be important to consider in overall vendor selection.
-
Evaluation
In the final evaluation, a scoring rubric can help determine whether the POC delivered upon the criteria set out by your team. While it can, and should, be a trusted source of impartiality, your organization should also bring in other factors at this stage.
Consider how helpful the software provider was during the POC. Was the partner or software provider hands-off or checking in regularly and working through issues? Which provider felt more committed to the success of the project and worked to ensure a successful POC? Finally, which vendor feels as though they will be more committed to the success of any future partnership?
Moving Forward
When done right, proof of concepts are invaluable in bringing organizations closer to digital transformation, allowing them to connect workers and ensure they have the tools and information they need.
