Can a Website RFP Improve Your Project Success Rate?

Have you ever issued a website RFP and received limited responses? Did you wonder what went wrong and why design agencies failed to reply with earnest?

You’re not alone.

The breakdown in the RFP process can be attributed to both the RFP issuer and the RFP responders. And it is an issue that has been growing for years.

On the client side, a lot of companies fail to publish a solid RFP, which makes it difficult for agencies to respond or even take them serious. On the agency side, design firms have grown so jaded about poorly written RFP documents that many won’t even reply. This breakdown in the RFP process flow can be corrected.

A well-written, properly executed RFP can have a positive impact on the website design process. It can help articulate the project requirements and objectives, while also providing a method for obtaining an apples to apples comparison of website developers.

So now that we’ve moved past the validity of website RFPs, let’s move on to crafting one that works for both the client and the design agency.

Top Reasons Why Design Agencies Ignore Website RFP Documents

While there are lots of agency blog posts ranting about the dangers of website RFP documents, there seems to be little information about fixing the problems within the RFP process. The posts that do offer help simply provide an RFP template that has little do so with the actual website design process.

Let’s start by looking at reasons why the average website RFP document under-delivers:

• The RFP lacks tangible details and focuses on the wrong information. Most of the RFPs I receive talk about the company’s creation, divisions, and other information that I can easily find on the About page of their website. Then the RFP will fail to provide key information about the actual project requirements. I don’t need to know your state of incorporation, but I do need to have a good understanding of your e-commerce needs such as product configuration, shipping requirements, and sales tax calculations.
• The RFP limits contact between the client and design agency. Some RFP documents will clearly state a limitation on communication. And if I’m allowed a one on one call it is with an administrator who doesn’t actually know the ins and outs of the website’s current or future functionality. This is a major issue and it is a huge red flag for me. I need to be able to talk to you about your project, so I can help formulate a solution. I also want to get a feel for the people behind the company so I can determine if we are an adequate fit. As my client, you’ll spend a lot of time talking with me and my team throughout the design and development process, so I want to make sure our personalities fit. It may sound silly, but this likability factor absolutely influences the success rate of projects.
• The RFP requirements and budget are out of sync. I have literally had people ask for a “Facebook like” website and then tell me their budget is minimal. Ok folks, Facebook did not become the powerhouse it is with a minimal budget. If your budget is low, that’s okay. We just need to make sure your requirements list is in line with the allowable budget.
• The RFP requires a great deal of superfluous information. If you want to know if I have professional liability insurance, I do and I’m happy to answer that question because it pertains to your project and the need to limit risk. I will even provide a copy of my liability and my errors and omissions insurance certificates so you can validate my claims. If you need a complete resume for every member of the project team, I’m not going to provide it because it is irrelevant. Ask for information that provides value and not simply because it was part of a RFP template you downloaded from the web.
• The RFP timeline is unrealistic. This is another showstopper for me, because RFP responses take time. They take time to understand the project needs and objectives, they take time to formulate a digital solution, and they take time to assemble an adequate response. I cannot do this within a week and if I do, my response will be weak. If your first attempt at the website RFP failed and you need to send it to a new batch of developers, adjust the date so that you can receive quality, well thought out responses.
• The RFP is a boilerplate document. If you download an RFP template from the web, make sure you update it to match the nature of your company and the requirements of your project. Make it your own and make it work for your firm. The more time you put into crafting a strong RFP, the more time design agencies will take in replying to it.

Now let’s look at three core reasons design firms struggle with RFPs in general:

• RFPs don’t work well for services like website design. They might work great for commodity products, but for highly customizable service projects, the RFP process creates a challenging process flow that limits discovery and the personalized creation of a solution.
• RFPs tend to focus on price and not solutions. No matter how hard I try to put a positive swing on website RFPs, the bottom line is a lot of the vendor selection will be made on price and timing. The danger in this is in communities like WordPress have a wide range of service providers that vary from very cheap, bottom feeders to very high-end design agencies. If you allow price to be a major part of the decision process, you could very well end up with a developer or design agency that lacks the abilities to execute. Your website is your path to the digital world and provides an avenue for you to reach an endless number of prospects and customers. It is your most important digital asset and this asset should not be defined by price alone.
• Some IT managers use RFPs for research purposes and this degrades their effectiveness. At first I did not believe this statement and then I found myself in the middle of this situation. It was with a local B2B tech firm – my sweet spot – and once I was onsite with them I knew I was part of a research experiment into the viability of WordPress and not at all part of an actual selection process. I proved that WordPress was a viable solution and I spent an hour educating them on search engine optimization. After many failed attempts at follow up, I noticed the IT manager launch his own WordPress website utilizing the knowledge I provided and all done in-house. And it wasn’t done well.

There are lots of very good WordPress firms who won’t reply to RFPs and this is a problem. Clients are missing out on some very strong agency expertise, as well as missing out on acquiring some stellar WordPress talent.

If I could correct this for all parties, I would do so. Since I can’t, I’ll just pledge to faithfully reply to any website RFP that is solid.

Maximize the Quality of Responses to Your Website RFP

Let’s collectively change the way the world views and utilizes website RFPs. You can do that by providing strong RFP documents and I can assist by providing solution driven responses.

Let’s review some key data that should be included in the creation of a website RFP. These include, but are not limited to the following items:

• Provide a brief company background. While agencies don’t need an entire company history provided, having a brief overview will help them get a quick baseline for who you are. Provide a link to additional information such as your website About page.
• Describe your product or service offering. Having an understanding of what you offer helps agencies grasp some additional basics about the project. If the agency has prior experience with similar product or service companies, the team can start to make connections to prior work. An example of this would be my background with ERP software. If someone came to me with a project for ERP software, my mind will quickly jump to work within the ERP industry and best practices for selling to multiple stakeholders inside and outside of the C-level suite. I think about the pain points of their target audience and the marketing tactics that work with this type of sales process. I would think about white papers and software demos and very focused call to actions. And all of that happened because the RFP informed me about the product offering.
• Describe your target demographic. Knowing your target demographic helps agencies understand factors like possible design style and accessibility requirements.
• Discuss the project background. Discuss what is prompting the website redesign and what led you to issuing an RFP. If you’ve gone through this process already and have had failed attempts, let us know that too. This information will help us know if we are a suitable fit for you and the project itself. No one wants another failure, so the more we know about the history, the more we can help drive success.
• Communicate the project goals and objectives. Talk less about the date your company was founded or the size of your organization and talk more about your marketing goals and objectives. This will help the design agencies create a solution that can meet your objectives and achieve these goals.
• Discuss your problems and let the providers define the solution. RFPs that present selected technology (in WordPress this would be plugins) can only describe solutions that the client already sees. When you’re hiring a developer, you’re hiring them to come up with solutions that you haven’t been trained to see. If you explain your pain points and existing issues, the developer can create the best solution based on their experience and knowledge.
• Require direct communication with your RFP recipients. Overly restrictive RFPs that discourage direct communication will most likely be ignored. As a possible technology partner, I want to build a relationship with you. This means I need to communicate with you one on one. If you are serious about an agency, let them get on the phone with key members of the internal project team so they can fully understand your needs and requirements.
• Don’t dictate the RFP format. Designers and developers are creative folks. As such they don’t work well in restricted formats like an RFP response template that is many years old. Give the prospective agencies the required information and let them reply in a format that best articulates their capabilities, strengths, and solution.

Make Sure the Website RFP Includes Key Data Points About the Project

There are a few more items that I consider very important, although they can be sticky subjects.

All website RFP documents should include the following items:

• Budget – Providing a budget range will help agencies understand their constraints. This let’s the estimating team know the scale in which they can propose solutions. This helps the developers know if they can create custom code or if they have to use an off-the-shelf solution that may or may not have all the required features. This also helps the design team quantify the process (wireframes and design comps) and volume of custom design (unique design templates within the website). It will also help prevent sticker shock when the proposal arrives.
• Project timeframe – One of the most common issues agencies have with RFPs centers around timelines that are far too short. Unrealistic project timetables can force an experienced firm to exit the selection process simply because they know they cannot launch a successful project within the timeframe given. Provide a realistic timeframe or range so you can garnish the best responses.
• Internal staffing and resources – Define your project team within the RFP so that the responding agencies can plan resources accordingly. An example of this would be a website redesigned combined with a learning management system (LMS) roll out. If you articulate that you would like to add an online course to your new website, but lack any in-house experience using an LMS, I know I should propose a resource who can help you tackle the LMS planning and architecture. It helps me help you, which in turn helps your project.

Discuss Known Requirements Within the Request for Proposal

When I create a website proposal, I like to have as many requirements known as possible. Some of these are generic, while others are very specific to the look and feel or the functionality of the website itself. The more details I have at hand, the more knowledgeable I will be about a project and the more precise I can be with creating solutions and offering estimates.

Help me help you. Provide lots of details around your functional requirements. Go into great detail so I can help present the best solution for you and your new website.

Here are some website requirements to consider when creating your website RFP:

• Desired content management system
• Mobile responsiveness
• Esthetics and/or inspiration websites
• Functionality – e-commerce, forums, membership processing, learning management systems, etc.
• Size and scope of content migration
• Search engine optimization
• Integration to third party software packages – Salesforce, Infusionsoft, Constant Contact, PayPal, Magento, etc.
• APIs
• Reporting requirements
• Speed and performance
• Accessibility and usability
• Quality control and cross browser testing
• Compliance considerations
• Hosting
• Ownership of code base
• User training
• Post launch service agreements

Define What is Required Within the Website RFP Response

Because different firms will have different proposal templates, help them create a document tailored to you by setting expectations for the response. I wouldn’t suggest you dictate the format, but I do suggest you provide a list of key proposal deliverables.

These RFP deliverables could include:

• Approach to website design
• Sample project plan at a high level
• Tools used within project management
• Project team list
• Project budget
• Payment schedule
• Ongoing license fees
• Project timeline
• Post launch maintenance and support
• Insurance requirements
• NDA signatures
• References
• Minimum qualifications
• Terms and conditions

Keep in mind the design agencies may not reply with all items listed by you in the RFP.

For example, I am happy to provide references, although I do not do so until I know we are on the shortlist of design firms. I do this to protect our existing clients so they are not inundated with requests for references. It is a courtesy to my clients and not an act of stubbornness.

Don’t Forget to Clearly Articulate Your RFP Schedule

One last reminder is to clearly define your RFP schedule, steps, and process. This can be efficiently done via a simple RFP schedule.

A sample website RFP schedule is as follows:

• Issue date of website RFP
• Vendor acknowledge and intent to bid
• Submission of agency question
• Responses to agency questions
• Proposal responses
• Agency finalist announced
• Proposal presentations and/or interviews
• Final agency selection
• Contract signatures
• Project start date

A Website RFP is a Request for Commitment So Start the Relationship Out Right

As I wrote this post, I was Skyping with an existing website design client named David Harper. I knew he would provide some excellent insight from the client side of this discussion.

David is very data driven and analytical. And even with personality type, he did not use an RFP in his process of selecting a design agency for this latest website project.

Once this caught my attention, I was surprised, so I thought I would just ask him about his selection process and why he did not use a website RFP.

Thankfully, David was kind enough to take the time to indulge me and provided insight into why he decided to forgo the RFP process as he interviewed WordPress designers.

Here are some great comments from my conversion with David:

• He started his migration from Expression Engine to WordPress by selecting 30 different solution partners.
• He did not use a website RFP because he feels many documents focus too much on budget and not enough on success factors like relationship, communication, and care. Those were David’s exact words.
• Instead of starting the dialogue with a formal document, he chose to simply make initial contact and start a conversation.
• A lot of the firms he reached out didn’t bother to respond.
• For those that did respond, he let the pre-sales conversation determine his shortlist of providers.
• Early communication provided predictive data on how successful the relationship would be within the lifecycle of the actual project.
• David believes an RFP should only be used to solidify tangibles. It should not be the starting point of dialogue and the relationship.

Now, David is a highly intelligent man who typically knows exactly what he wants. He also “gets” technology and has gone through several dozen website projects in his lifetime. He knows what works and he knows this through experiencing his own set of project successes and failures.

Because of David’s intelligence and experience, I welcomed his comments and I wanted to share them with the readers of this blog post. And while everything David said above was very educational, the most important statement he made was this:

Relationships must come before any website RFP.

David, I have to admit, I don’t think I could have articulated that better myself. RFPs are great if they are accompanied by a solid relationship.