smartcities

The perils of an "Internet" RFP

Recently we’ve received numerous calls from cooperatives and municipal utilities asking us to review a RFP that they’ve prepared.  In theory, this should be a straightforward exercise that can be performed over the phone in a time and cost efficient manner.  In all cases, the RFP has been prepared using samples found with the ever too familiar Google search. Unfortunately building a RFP isn’t as simple as cutting and pasting requirements that sound good and putting it into a new format, in particular in an environment where the technology is changing faster than ever before.

The systems utilities are procuring today should have a life expectancy of eight years, in the case of software solutions, to fifteen to twenty years in the case of AMI/Smart Meter solutions.  As a consequence, it’s really important to ensure that the solutions you purchase meet todays needs as well, as well as, future needs, e.g. you’re not buying for 2015 but rather 2025.  The first step of a “Good” RFP is crafting a conceptual solution that complements existing and future systems, and is aligned with strategic and immediate business benefits.  A RFP doesn’t need to be lengthy to be effective, it simply has to capture the differentiators that are important to you.

A solid RFP involves at a minimum the following components, tailored to meet your specific needs:

  • “Window frame” - positions what the solicitation is for, rules of engagement, and submission details 
  • Description of overall context – describes project overall, context, timing, legacy environment, vision, etc.
  • Vision – it’s really important to understand that the vendor wants to go where you want to go
  • Technical requirements – details of the technology platform, performance, etc.
  • Functional requirements – outlines what users are looking for, we like to include use cases
  • Project delivery requirements – when considering credible vendors that have an established track record the difference between success and failure is the delivery approach and the project team
  • Terms and conditions – this includes mitigating risk related to warranty, performance, acceptance, etc., in addition to the normal legalese
  • Price – total cost of ownership, without any hidden costs, internal and external, is of the paramount importance.

We aren't questioning the quality of the base RFP’s that people are finding on the internet.  They typically represent considerable effort on the part of the authors.  We believe that utilities should develop their specific solution that fits their goals and objectives, then procure software that they understand can actually deliver their dreams.  Too much money is at stake to follow a “me too” model.

If in doubt, we’d be glad to discuss how you can develop a RFP that can deliver traceable value and benefits.  Our guidance is only a phone call away.