The RFP process, redefined
By Michael Argentini
Managing Partner, Technology and Design
A Request for Proposal(or RFP) is a strategy used by clients to find a vendor for providing a service or product. The RFP exercise is typically performed early in the procurement cycle.
They're great tools for finding a vendor to sell you a quantifiable product or service, like computers or a courier. But they're not the best way to find a creative partner for a project with a scope that is not immediately quantifiable, and which likely requires the creative process to unfold and change as project requirements do.
What is an RFP?
An RFP is generally presented by a prospective client as a document which describes the requirements for a project, and usually dictates the desired structure and format of the vendor's response. The goal is to find a single vendor that has the technical skills, requisite experience, resource availability, and pricing, to meet the needs of the project as the client understands it to be at the time.
Some of the more common reasons a client would issue an RFP to find a vendor include:
- Get the attention of various providers, soliciting cost estimates en masse. This allows the client to compare vendors with each other.
- Create a competitive landscape where vendors do their best to win a project.
- Encourage low-cost estimates by providing transparency around project requirements, and by creating a competitive environment.
- Ensure that providers create strategy for, and/or address every facet of project requirements.
- Create a sense of impartiality in an otherwise highly competitive environment.
- Find the best vendor for the job, and ultimately, create the best final product for the money.
Throughout the first part of this article I've used the term vendor to describe the company performing the service. The RFP process generally makes the assumption that the client is negotiating a vendor relationship based on perceived, quantifiable factors like price and scope of work. But for creative projects like building software applications and services, this view can be counter-productive.
In this scenario, a partnership is most often the best way to achieve creative goals. Since it's important to choose the right partner, this is where the RFP process comes in. But an RFP may not address important questions. Does (and can) the partner understand your company's needs? Can they implement the right user interface and design aesthetic for your users' needs and brand image? Their rates may be higher than some, but will they be more efficient and use fewer hours? By insisting on the lowest price, are you inadvertently creating a "hit and run" scenario? You get the picture.
So, let's take another look at the prior rationale and draw out the flaws in creating a partnership through a traditional RFP process.
1. Get the attention of various providers, soliciting cost estimates en masse. This allows the client to compare vendors with each other.
By following a rote RFP process, the client compares the prospective partners using a process that all but guarantees they will choose the one who can write the best RFP response, not who would be the best partner; many times valuing ambiguity over substance.
A client should get to know the prospective partners through dialogue, understanding their capabilities and experience, and meeting their staff. This is much more effective, and takes far less time. How do they handle mistakes or changes in scope? Do they have a defined culture? Do they espouse core values? What's their focus? How's their client retention? What will the ongoing relationship be like? So many questions like these remain unexplored.
2. Create a competitive landscape where providers do their best to win a project.
Completing an RFP is a labor-intensive exercise. Some can take days to a week or two, and the mad dash to read, question, complete, and submit the response is often put on the back burner as other client project priorities take precedence, leaving little time to perform due diligence. Additionally, most of the time the RFP is a required process. So even if the prospective partner has creative thinkers, their enthusiasm will be tempered by corporate mandate.
If you get to know the partner up-front, it's not hard to make the decision to work together. And when you do, they need to first help you discover everything you need to know about the project and how to complete it successfully. For that matter, they can help you define what a successful project even means.
3. Encourage low-cost estimates by providing transparency around project requirements, and by creating a competitive environment.
This strategy has been used by countless service providers as a way to unwittingly race to the bottom. The worst time to estimate the scope and cost of a project is at the outset. Think about it. This is the time when the partner knows the least about the project, and possibly the least about the client. Yet, the partner is tasked with quantifying it.
As a client, don't hesitate to share your budget with a partner, and work with them to determine how to best use it. Hiding critical information like that has consequences. Your partner may approach things differently based on the time and funding your project really has.
4. Ensure that providers create strategy for, and/or address every facet of project requirements.
The partner hasn't interviewed users. They haven't spoken with the IT department. And they have requirements as identified by the client. Feedback and ideas are invaluable in a proper process. But in building the RFP, the client had to become a software designer and developer in mindset in order to give the partner what they think they will need to define and estimate the project. This is unfair to the client, and largely ineffective.
A partner should be included in the definition phase. They will perform appropriate discovery and work with you, your users, and other stakeholders, to identify the solution you need. This is why you're choosing a partner.
5. Create a sense of impartiality in an otherwise highly competitive environment.
This has nothing to do with the focus of completing a successful project. This is a red herring and shouldn't be seen as beneficial in any way. If anything, it makes choosing a partner more difficult as the focus is splintered; some of it wasted on political posturing.
6. Find the best vendor for the job, and ultimately, create the best final product for the money.
I'd rephrase this as "Find the best partner and create the best final product within an acceptable budget and timeframe." A partner won't view your project as a job, and they don't work best when treated as a vendor. They care about your business, your users, and the success of the project. They're in it for the long haul, and want to help you succeed for many years to come.
The RFP Process, Redefined
Yes, we do work with prospective clients who issue RFPs. But we're very particular regarding the ones to which we choose to respond. Aside from making sure we're a good fit for the request, we want to be sure that we have the time and resources to respond with proper diligence, thoughtfulness, and substance. Allocating the resources, in particular, presents a bit of a barrier.
So, when it comes to creating these kinds of partnerships, we believe there's a better way. Perhaps the initialism "RFP" should stand for Request For Partnership, and in that spirit, follow some of the following guidelines:
- Begin with a selection of prospective partners who are invited to bring appropriate staff to meet with a client's core project team to make introductions and talk about who they are, and what their values are. They should present their relevant experience, discuss their passions and frustrations; basically learn as much as possible about each other to determine if there's a "fit".
- The client should then choose a partner that satisfies all of their criteria, and involve them in a collaborative effort to define a vision for the project, and the scope for a discovery process. This should end with a complete definition (business and technical requirements) for the project, based on a user-centric approach.
- Now that everyone has agreed to what will be created, the last step should be about defining the timeline and length of effort (cost) of the deliverable. There should be an understanding that scope can and should change as we learn new things, and evolve to maintain focus on the goals defined in the discovery process. Acknowledging this up-front is crucial. As decisions have to be made during the build phase, the client will have the ability to approve or deny any out of scope work, thereby controlling cost while still being flexible.
What have your experiences been regarding RFPs and choosing a creative partner? Do you struggle with them as a corporate mandate, or do you really embrace them? Have you used any of the aforementioned strategies in place of, or alongside, an RFP?
Article last updated on 4/21/2018