Traditional RFP processes are designed for comparison, but they often constrain the very innovation organisations need most.
For decades, software selection in the EHS space has followed a predictable pattern: comprehensive requirement matrices, hundreds of yes/no checkboxes, and feature-by-feature comparisons that tell you what a system can do but rarely why it matters for your specific organisational challenges and context.
While these traditional RFPs serve a legitimate purpose for standardised evaluation and scoring (loved by both big consultancies and client procurement teams), they create an unintended consequence: they force vendors into a defensive posture, proving compliance with a checklist rather than demonstrating how they'll solve your actual business problems.
The Problem with Traditional RFP Approaches
Standard EHS software RFPs typically include:
- Hundreds of one liner functional requirements with no explanation of why they matter
- Binary yes/no/customisation response options
- Heavy emphasis on feature parity across vendors
- Limited opportunity for vendors to demonstrate strategic value
- Minimal connection between requirements and real operational challenges
The result? You get extensive documentation about product capabilities, you spend a lot of money comparing features but limited insight into how a solution will address your stakeholder pain points, drive adoption or deliver measurable business outcomes.
Experimenting with a Different Approach
We recently partnered with a client who gave us the creative freedom to reimagine their software selection process. Together, we developed an approach that maintains the rigour of traditional evaluation while unlocking genuine innovation from vendors.
The Problem-Centred Procurement Framework:
Discovery and Problem Identification
We started with stakeholder interviews across the organisation; from frontline users to executive sponsors. Rather than starting with a pre-defined feature list, we listened for:
- Operational pain points and workflow friction
- Strategic objectives being hindered by current systems
- User adoption challenges and resistance factors
- Compliance gaps and risk exposure areas
Building the Problem Framework
We distilled interview insights into validated problem statements that became the foundation of the RFP template. Each problem statement included:
- The specific business challenge
- Current state impact and consequences
- Stakeholder groups affected
- Success criteria for resolution
Inviting Solutions, Not Just Specifications
Instead of asking vendors to simply check boxes, we invited them to demonstrate HOW their solution addresses each validated problem. Vendors were requested to provide:
- Specific functionality that solves the problem
- Implementation approach and change management strategy
- Evidence of similar problem resolution (case studies, references)
- Measurable outcomes clients should expect
Maintaining Rigour While Adding Depth
The framework still enables structured, comparable scoring but evaluates strategic thinking, implementation philosophy and real-world applicability alongside functional capabilities.
Why?
The difference between asking "Does your system have incident reporting?" and "How does your solution help our field supervisors complete incident reports within 24 hours despite limited connectivity?" is significant.
The first question gets you a checkbox. The second gets you insight into mobile functionality, offline capability, user experience design and the vendor's understanding of your operational reality.
This approach:
- Reveals how vendors think about problem-solving, not just what features they've built
- Surfaces implementation philosophy and change management approach early
- Connects technology capabilities directly to stakeholder needs
- Still allows for structured, defensible evaluation and scoring
What We're Learning
Early results from our pilot engagement are compelling:
- Significantly higher stakeholder engagement in vendor evaluation
- More substantive vendor responses that reveal cultural fit and implementation competency
- Clearer differentiation between solutions beyond price and feature counts
- Stronger foundation for post-selection implementation planning
Interestingly, despite extensive research and experience in this domain, we haven't seen this problem-centred RFP framework widely adopted in the EHS software selection space. Most organisations still rely on traditional requirement matrices, even when they acknowledge the limitations.
Where This Could Go
We see significant opportunity to evolve how organisations approach safety technology procurement:
- Beyond EHS Software: This framework equally apply to other enterprise safety technology selections where stakeholder adoption and problem-solving matter more than feature parity.
- Continuous Improvement: Problem statements identified during RFP discovery can inform implementation planning, configuration priorities and success metrics post-selection.
- Vendor Ecosystem Evolution: As more organisations adopt problem-centred RFPs, vendors may shift how they position solutions from feature lists to problem-solving capabilities. Amen to this!
Join the Conversation
We're sharing this approach because we believe procurement processes should evolve alongside the technology they're evaluating. Traditional RFPs aren't necessarily broken; they just don't have to be so limiting.
If you're exploring software selection, rethinking your procurement approach or have experimented with similar frameworks, we'd love to hear from you.
Reach out to PKG Safety Innovation to discuss what we're learning, share your experiences or explore how problem-centred procurement might apply to your organisation.
