The Hungry Teenager Problem: Why Most RFPs Are Bloated From the Start

One common way midmarket companies select enterprise software is by purchasing an RFP template. It usually includes a list of possible requirements for each module. I’ve seen some with 200 suggested requirements and I’ve seen some with thousands of suggested requirements. The idea is to have your stakeholders identify their requirements, often ranking them as Must-Have, Should-Have, Nice-to-Have, and Not-Applicable. This seems like a thorough process of defining what you are looking for in an enterprise system.

The problem with this method is that it works about as well as sending your teenager to the grocery store without a shopping list. Almost everything the stakeholder encounters in the suggested requirements looks appealing and ends up in the shopping cart. While reviewing the requirement list, I’ve heard people exclaim, “There are systems that do that? I’ve never thought of that. I’d love to have that.” Suddenly, the cart has another “Should-Have” item that had previously never been contemplated. Just like a hungry teenager set loose to wander the grocery store aisles looking for items that strike their fancy, stakeholders begin to justify every item remotely related to their functional area.

Not only does this lead to a bloated RFP looking for the unicorn system that does everything, but it may not even include the items you truly need because they are unique to your business.

What is the alternative? How should you build an RFP? At Victoria Fide, before we ever write a requirement, our teams do two things. First, we document how the business actually operates today, process by process. We call this the Enterprise Process Review. In the Enterprise Process Review we document the pain points and the true differentiators for the business. Although most companies are not as different as they think they are, most companies do have a few areas in their operations that truly differentiate them from their competition. We want to identify this “secret sauce” and make sure any future system appropriately supports this. Second, we assess what is genuinely worth changing: where the organization is ready to change, where the real opportunity sits, and what a solved version of the problem looks like. We call this a Transformation Opportunities Assessment.

From the Enterprise Process Review and the Transformation Opportunities Assessment, we perform a requirements analysis. This is the step that produces the actual “shopping” list. Every line on it traces back to something we observed or something the business decided it wants to change. Nothing lands on the list because it sounded interesting in a vendor webinar or because one loud stakeholder insisted on it in a planning meeting.

In my experience, the requirement that ends up mattering most is rarely the one anyone names first. It is usually a workaround. A manual step nobody ever wrote down, because nobody thought of it as a requirement. It was just how the work got done, and it had been for years.

The job of the Enterprise Process Review and the Transformation Opportunities assessment is to limit the cart to what the business actually needs, not to catalog everything that sounded good to somebody in the room while the RFP was being drafted.

Transformation is not easy, but it doesn’t have to be impossible. Take control of your project’s success today and schedule a free 30-minute consultation to find out how Victoria Fide can equip you for transformational success.

The Vendor Demo

The same discipline has to carry through to the vendor demos. Most RFPs ask vendors to run a standard walkthrough of their product, module by module. That is the equivalent of walking through the grocery store and only visiting the candy, snacks, and frozen foods aisles. If you let the vendors drive the demos, you will end up seeing only the end-caps and other eye-candy.

Instead of vendor run demos, at Victoria Fide, we help the stakeholders write the demo scripts, built directly from the pain points and the “secret sauce” surfaced during the Enterprise Process Review and the Transformation Opportunities assessment. If procurement’s real problem is a manual spreadsheet quietly plugging a gap the old system never handled, the demo script asks the vendor to solve that, specifically, in front of the people who live with it every day. If a company’s real edge in the market comes down to something particular about how it fulfills an order, the script asks the vendor to show exactly that, scripted to the client’s own process, in front of the people who would actually use it.

We had a client Business Process Owner who was anxious about changing their order-entry screen. Rather than tell them how the new system was better, we had the vendor sit with the order-entry team and walk through the client’s order-entry process. When the client saw their actual orders successfully processed inside the new system, it built confidence the team did not have walking into the demo. It also surfaced improvements nobody had thought to ask for.

That is what a demo script built from real pain points can do that a generic feature tour cannot. It tells you whether the system can execute your process and the vendor can configure it to solve your problem. It does not just tell you whether they can run a polished sales pitch.

Our solution selection process turns an otherwise subjective exercise, what looked appealing during the RFP, what impressed in the demo, into a specific and defensible list of what the business actually needs, tested against scenarios the business wrote itself.

Write the list before you go to the store and hand the vendor a script, not a stage. If you do that, you significantly increase your chances of making a selection that will set the foundation for successful transformation through the implementation of a critical system.

You can learn more about our Solution Selection process here.