Elements of an Effective Request for Proposal (RFP)

Researching and deciding on a new software solution can be time consuming. With so many solutions to solve your problem, how do you ensure you’ve communicated the necessary information to potential vendors to find the right solution and gain the greatest return on your investment? By writing a concise and detailed request for proposal (RFP), that doesn’t stifle innovation, you can make certain you choose the best vendor for the job.

With today’s acceleration of digital transformation, customers expect companies to be available via multiple channels without missing a beat. As companies need to adapt quickly, how does one choose a software that will meet the customer’s expectations while also meeting the goals of the company and supporting their sales process?

From our experience, we’ve seen two common approaches companies take to writing RFPs:

• The long 38-page RFP with many requirements that eliminates innovation and can pigeon-hole a customer into a specific solution.
• The short one- to two- page RFP with little detail that is vague and can take a vendor more time to understand and develop a proper solution and even worse… lead to assumptions of what is needed.

To help you pick the perfect vendor for your solution, we’ve created a helpful guide and outline on how to write an effective RFP from a software provider’s perspective.

1. Project Details

The first part of an effective RFP lists out all the administrative details of your planned project. This section includes content such as project name, submission deadline, contact details and the criteria the RFP will be judged on.

2. Company Introduction

In the second part, an effective RFP will provide vendors with a high-level view of the company, its vision and mission, and its 5-10 year goals. By giving vendors a high-level view of the company and its goals, they can provide a solution to solve more than just a siloed problem.

The first mistake that is often made is who is writing the RFP. Typically, the RFP creation is often delegated from a top manager or a higher-up to someone else

By delegating the work, the manager should expect to receive a solution or requirements that only reflect the responsibility of that manager or their function. Typically, the author of the RFP does not understand the vision of the company, its business objectives or the company’s existing IT landscape to broaden their scope.

They don’t know where the company wants to be in 5 to 10 years, and they don’t understand how software can help reach their functional and company-wide goals.

If the creator of the RFP isn’t aware of the overall company business objectives, how could they transform the big picture into hands-on, tangible business outcomes? It’s impossible.

By involving multiple departments and higher-ups in the process of crafting the RFP, it’s possible to take a company-wide holistic approach. The company will be more successful with their RFP and will see a great return on their investment.

3. Project Objectives & Timeline

To find the right solution, companies must be able to clearly define the problem they are trying to solve.

Understanding pain points are essential for understanding the pitfalls a customer is facing and to providing the right solution. We’ve experienced RFP’s that depict a successful sales process only to find that after we won the bid, there were major pain points. Although we still found a solution, this completely changed the direction of the project.

4. Project Scope & Specifications

Scope creep is a dreaded monster that can happen when a project scope is not defined properly. It can cause project delays, additional costs and for the quality of a project to go down. By beginning to define the project scope before the project begins, companies can avoid scope creep.

The project scope of an RFP is a more detailed outline of all aspects of the project. It can include resources, timelines, deliverables, requirements, project boundaries, etc.

Additionally, when considering the scope of a project, software vendors want to understand:

• Software requirements
• Hardware requirements
• Product line or service being developed

It is also important to find a balance between the requirements and exceptions to a scope of work. What variables are deal breakers and what variables could be reconsidered? Companies risk blocking innovation and eliminating vendors that could solve their problem if the requirement didn’t exist.

5. Proposed Outcome & Cost Summary

One of the most important items for the vendor to understand is the expected outcome. Vendors need to be able to see what the picture of success looks like from your perspective. Ask yourself, what outcomes do I expect to see when this project is complete?

For example, at the end of this project we’d like to have error free quotations and clean orders. Or we want to be able to do live design with a customer.

By defining the problem and vision of success early in the process, it can save a company time and money in the long run.

Conclusion

To summarize, to be successful with your RFP:

• Take a holistic company-wide approach, software can help companies reach both their functional and long-term goals
• Clearly define your project objectives and scope to save time, money and resources
• Use your RFP as a tool to begin a dialogue with vendors to avoid limiting innovation due to lengthy requirements

To help you get started with your RFP, we’ve created an outline that helps explain the problem at hand and gives vendor’s insight into your company and its goals.