The Dark side of the RFP Process
We recently received a Request for Proposal (RFP) from a small, startup energy trading company. They are soliciting proposals from "established" firms to provide energy trading and risk management (ETRM) software and will select a vendor based on several different factors. As seems to be standard practice in the energy trading technology industry, I have limited clues on what will win this proposal for us.
To be honest, we were damn surprised when we received the RFP. I have a hard time with the term "established vendor", and the client provided a laundry list of requirements -- many of which our software does not have a (current) way of handling. The RFP goes on to state that the selected vendor will provide "turnkey access" without any further development before implementation.
I applaud the ambition, I really do. I'm even starting to believe this is a client after my Molecule heart. A turnkey, ready-to-go solution would be a dream come true in any situation, had it not been for 45+ other technical, functional and reporting needs the client "must have" on Day 1, in order to make an affirmative decision.
At this point, my mind starts to think and wonder, and ask why?
- Why have RFPs crippled this industry and the decision marking process that follows?
- Why on earth would anyone need all of this software capability on Day 1? At that point, a startup has 2.5 employees, and no trades. Thinking 5+ years out is ambitious, but can cripple your sense of understanding what you need Day 1, and the software flexibility and features you might want for down the road as your needs evolve.
I can think of a few reasons.
- It is very easy to follow the pack.
If every ETRM-buying firm is putting out an RFP, why can't we? It becomes really easy for firms in this industry -- big and small -- to keep the status quo. It is the easy answer. Why veer off course and try to do something on your own when you know a dozen (or more) vendors are panting to respond to your wish list of ridiculous requirements?
You might as well test them to see how high they jump, or how quickly they will lower their price to win your business.
-
Locking in Price looks awfully like locking out Risk.
As the client, you have the ultimate say. And if you're wanting a commitment several years out, why not push hard on price? The problem is, when scope is murky, getting someone to commit to a lump-sum price is simply amplifying the risk that things will go badly wrong.
At Molecule, we have long offered month-to-month pricing. However, the market often dictates long-term deals. We see 3- and 5-year commitment requests come across our desk all the time. That's not a bad thing in an ETRM software industry long known for its bad behavior. But locking in a price when scope is wide open, will not end well for anyone. In fact, it incentivizes vendors to be misleading. -
Shoot for the Moon. Even if you miss, you'll Land with the Stars.
There seems to be a sentiment that if you ask for every feature you might ever need, you'll end up getting more than you would have otherwise. Sadly, that's not how good software works. In good software, unused features get removed--so that developers can focus on making the things you do use, stellar.
As hard as it is to figure out what you need on Day 1, it is really important. Why pay for more? And if you don't know, it's OK to be vulnerable and share what you are trying to figure out. The absolute wrong answer is to revert back to point #1 and undergo a process that will only make the decision murky, the process prolonged, and ultimately, have you stuck in a marriage that you committed to based on the prettiest (and longest) PowerPoint, all for the sake of optics.
If you're running the process at a supermajor, we totally get it (though we disagree) -- you have many bosses and can't leave a single stone unturned. But if not, there really is no excuse.
