Successful projects start with better RFPs

Eric Holter, Cuberis, USA, Emily Lytle-Painter, Independent, USA

Abstract

Keywords: RFP, RFQ, Website, Digital Project, Collaboration, Digital Initiatives

Introduction

The time has come for your museum to start a new digital project. Your colleagues and trustees are buzzing with excitement over the promises and practical uses of this new project in your museum. You overhear conversations like, “I can’t wait to use this for our k-12 education,” or “Think of the higher visitor numbers we’ll have after this launches,” but all you feel is this uneasy pit in your stomach. Why? You’ve been chosen to lead the development of this project, and the first thing staring you down is the task of writing the dreaded Request for Proposal (RFP). For many museum professionals, selecting a firm for a digital project is not your daily job, or something you have had much experience with in the past, adding stress, fear, and self-doubt to this already lengthy process. This paper will serve as your guide to alleviate stress by going through some of the problems with the traditional RFP and discussing ways to improve the process and the document itself, with the end goal of setting you up for a successful digital project.

All that’s wrong with the RFP

The RFP is protective

The RFP document is often written to be protective. This is because the process is seen as primarily contractual; a starting place that is defensive for both the museum and the potential firm. When the first exchange between a museum and a firm is the RFP, embedded between the lines of all the project background, requirements, and deliverables is a lot of language intended to protect the museum from getting burned during the project. RFPs can become catalogs of every problem the client has ever encountered in past projects gone bad. Sadly, bad project experiences are very common, and no one wants to repeat those experiences—so you try to weed them out at the proposal level. Questions or requirements such as “please provide your company’s financials,” or “provide a list of team members that will work on this project,” or this unusual example, “are the principals of the company married to each other?” (this is a real example from a client who experienced project failure when a firm’s principals entered into divorce proceedings). As you can see, fears from past projects might start to sprinkle the document with odd protective requirements. But apart from the odd requirements, there are other ways that the fear of project failure can distort the RFP.

Museum fears

Museums write protective RFPs due to several well founded fears. The first is the fear of not getting everything they need. Naturally, museums want to get the most for their money, so RFPs tend to list every possible feature. However, this extensive list can very easily shift from a thorough and well reasoned document to a catalog filled with every single feature and function museum stakeholders can think of. Museum digital teams often have to justify their plans for expensive development projects to leadership teams that “don’t understand digital.” This may lead to the desire to add on unnecessary, exhaustive functionality to the RFP, in an attempt to make the possibilities for the new website or interface be all things for all people.

Another common concern among museums is the fear of paying too much. Not only do RFPs attempt to list comprehensive requirements, but then the budgets are often set with a low number, as a means of negotiating the best possible deal. Again, this is normal in negotiation, but it does introduce distortions into the document. Museums are also afraid of project failures, missing deadlines, going over budget, or unacceptable deliverables. These are all genuine concerns, but when specific terms and conditions or penalties are set forth at the outset regarding potential failures, the distrust is set even before the project begins.

Firm fears

Clients aren’t the only ones who approach RFPs with fear—partner firms are also afraid of project failure. Firms are afraid of a project that keeps getting new requirements added as the process goes on, so they add all sorts of qualifiers to the project scope. They also fear projects that go over budget, add padding, restrict scope, draw hard deadlines on timetables, add restrictive conditions to terms, or that never end or have new decision-makers introduced halfway through. Most of all, firms are afraid of wasting their time because the client has already chosen another firm; no one wants to be the second and third document needed in order to satisfy the administrative requirement of soliciting competitive bids.  

The RFP is bloated

RFPs are often bloated and far bigger than necessary—traditional RFPs in the past have been known to reach upwards of 20 pages. RFP bloat usually occurs when an organization is trying to compensate for long-term neglect. The average lifespan of digital projects vary, but for a website it is usually three to five years. While updates and maintenance may keep a site functional during this span, design standards, new technologies, and new marketing opportunities usually require significant upgrades to the site over time. Many museums find they have “technical debt” from one-time digital projects and legacy third-party integrations that accumulate over time and get lumped into the RFP as an attempt to fix everything at once. And if gradual upgrades, design refreshes, and new technology implementations are not handled on a regular basis, a site or project can become so out of date that rebuilds from the ground up become necessary.

In addition to compensating for past neglect, the project manager, anticipating that the next opportunity to revisit the site won’t be for another three to five years, adds “everything we can imagine we might need” to the list for the next three to five years. Doing this adds more requirements to an already packed project. Bloat can also occur as a result of the person putting together the RFP trying to negotiate and include all stakeholder priorities. This is related to the previous point—if this kind of initiative only happens every three to five years, then everyone wants in. The very rush to address all stakeholder needs only intensifies the bloated project RFP, and in the end, convolutes the process itself and the final product.

It is important that the RFP remains shorter rather than longer, because the bloated RFP can make the process divisive based on structure alone (Kieller, 2015). The long lists of features, the majority of which are listed as mandatory due to different stakeholder priorities, means some firms will try to overcompensate in their proposals by answering “yes” to all, under estimate the budget in order to win the bid, and then attempt to negotiate a higher price once the project is underway. This proposal subterfuge on the part of some firms contributes to other museums’ fears of the whole process (as discussed above), leading to more padding and more bloat in RFPs, continuing the vicious cycle.  

The RFP automates a relational process

Far more critical to the success of the project and the effectiveness of the partnership is the relationship between the people who will be involved in the process. The perfectly delineated document matched with the perfect proposal would be useless if the people behind those documents don’t communicate well or work together effectively. You have to get a feel for the chemistry between your museum and a firm in addition to checking of the boxes of requirements. When the focus falls to a document exchange, proposals just become a means of impersonal “pitching” for work. This dynamic leads to overkill in buzzword filled document preparation. A conversation (discussed further in the “dynamic RFP process” below) will cover so much more ground than a proposal ever could.

How to redeem the RFP process

Before you even sit down to write the RFP document, you’ve already started the process by gathering your team, discussing project goals and scope, and compiling any information or data from prior digital projects to use as reference. These are all necessary steps, but before you write the RFP there are some more changes you can make to the process that will make writing the RFP easier.

Find expert firms before writing

Don’t let your RFP be a letter written “To Whom it May Concern.” One of the easiest pieces of research you can complete is reaching out to potential partner firms before you set out to write the RFP document. Kirk Cheyfitz (2015) states that more agencies are participating and responding to RFPs if and only if there is already a relationship with the potential client. Going back to the fear on the side of the museum, one of the scariest ideas is spending many hours and days putting an RFP together, just to have no firm, or only sub-par firms, respond with a proposal. Reaching out and vetting firms before sending the RFP is one way to avoid this outcome.

In addition to making sure your RFP receives qualified responses, reaching out to firms before writing the RFP can help you clarify recommended digital specifications, include more specific requirements in the final documentation, have a better understanding of costs and project timeline, and write a case for internal approval (gov.uk, 2016). The best way to establish contact with qualified firms is by reaching out to fellow museum colleagues or looking within the Museums and the Web community for word of mouth recommendations or to meet sponsor firms. Exhibiting firms at conferences are excited to meet you, and would love the opportunity to sit down and share their info, even if you don’t have a website project on the horizon. Looking at past projects and speaking to colleagues who have worked with these firms before are good introductions to the kind of work the firm does.

Make the process dynamic

Unless your organization has very clear guidelines that structure the procurement process (e.g. a Request for Quote (RFQ) must be written before an RFP is submitted), there are really no set rules as to how you go about the RFP process. As mentioned in the section above, many firms don’t respond to cold RFPs. One way you can change up the process is by how you reach out to them. After gathering an initial list of firms you want to reach out to, set up an informal phone call with a decision maker in the firm, or vet the selected firms by sending out a Request for Information.

The Request for Information

The Request for Information (RFI) is an informal questionnaire museums can send out as a way to get to know their potential partners and solicit creative solutions without having to put together a hefty RFP or read through many weighty proposals. Using the RFI allows for flexibility in the project’s direction; if one firm mentions a better solution or project parameter that you have not yet considered, and you then decide to incorporate that solution into the final project, you haven’t wasted the time it would take following the traditional route. (i.e. if solutions are uncovered after the RFI, you save the time you would have spent writing the RFP and reading through proposals just to find that same solution).  

Knoebel, writing on the Princeton University blog (2016), shares the process he and his team followed when soliciting proposals for the redesign of the Princeton website. When writing, he shared a link to the RFI they submitted to potential firms with “…crafted questions to encourage vendors to go deep and give us insight into how they think rather than what they’d do for us.” The questions are split up into the sections “our industry” to gauge firms’ experience with the higher ed industry, “technology” to give firms the opportunity to demonstrate their experience working with Princeton’s selected CMS, “design” for the firms to discuss their past work regarding visual and UX design, and “project management” for firms to discuss their experience problem-solving with past clients and projects. Before getting into the questions, Knoebel establishes clear rules and encourages responses to be made as short as possible.

It is important to send the RFI to your initial list of firms only after you have gathered your team, met with stakeholders, and set concrete project goals. Starting down the path of finding a digital partner without setting these clear goals at the outset will only make the process harder for you down the road. If you decide to send an RFI you don’t need to follow another institution’s questions, but if you do, always make sure those questions are tweaked to fit your organization and the project. Don’t ask a question without knowing why you’re asking it; but do be careful not to ask questions that aren’t open-ended and will restrict your respondents from answering creatively.

Let firms interview you

Speaking of creativity, one of the trickiest aspects of hiring an outside firm for a digital project is finding a way to measure creativity and expertise, two qualitative characteristics, through a traditionally quantitative document, the RFP. One way you can try to evaluate qualitative characteristics like expertise is by finding tangible evidence of experience and performance on projects similar to yours; a narrow focus in a specific practice area; and, credentials like certifications or a track record of speaking and writing on a subject to professional audiences (Harrison, 2012). Another way to go about evaluating a firm’s expertise and creativity during the process is to schedule a phone call or in-person meeting and let them interview you. During this meeting the conversation should focus on outcomes and processes instead of what the firm plans to put into the project (Wayland, 2012). This gives the firm the opportunity to dive deeper into what was included in the RFP document and potentially suggest a few ideas they’ve come up with for the project for you to evaluate; this helps you get a feel of how a relationship with that firm will look like after the RFP process is over.

Bring in final selections for a test run

After you’ve selected one, two, or three firms for the final round there are several options for how you can choose your official partner. Harrison (2012) recommends narrowing your pool to only one final firm and only sending an RFP to them, but for some organizations this may not be possible due to accountability and good governance policies that require the RFP to be sent to more than one firm. If this is the case for you, narrow your final pool as much as you can, send those final firms the RFP, then offer to pay the top one or two for their evaluation of you. Yes, this takes time and money, but it gives you the benefit of real responses based on factual analysis. It also gives you a jump-start on the project itself because all good firms will do an analysis of your current website or digital project once they’ve been awarded the contract, and now you’re taking care of that step before the contract has even been signed. This process is recommended especially for larger projects where you, the decision maker, have more money, time and resources at stake should the firm you chose for the project fail to deliver (Andolsek, 2004).

By engaging potential partners and paying them for their insight, you get meaningful evaluation instead of educated guesses about what you really need. You get deeper analysis, amore familiarity with your institution in the responses, and, in most cases, you will get lower and more accurate quotes—since the firm will not need to pad out of fear that the RFP isn’t adequately representing the problem. It means getting to see your final one or two firms in action, and at the end of this step, you will have actual work to evaluate, leaving you with the confidence that the firm you choose will truly be the best fit for you.

How to redeem the RFP document

If you’ve never put together an RFP before, you’d probably prefer to just start a project using the dynamic process described above, and skip the writing of the RFP altogether. However nice that may be, nonprofit museums and libraries often need to write an RFP as required by their institution’s policies, funders’ policies, or when government regulations require one (Peters, 2011). Even if you’re not required to write an RFP, Peters (2011) writes that the RFP, when done correctly, can serve as a great need assessment tool. Through the creation of the RFP you can interview key internal stakeholders and come up with solid requirements that are measurable to help guide the project to a successful conclusion. Having these concrete measurables at the outset of a project will help you manage or decline additional stakeholder suggestions should they wish to add requirements to the project later on down the road. With that said, here’s how you can redeem the RFP Document.

Start writing early

Murphy’s law truly is alive and well in the realm of digital museum projects. You should start the RFP writing process early for two reasons: hard deadlines looming in the distance, and time to allow for the process to be altered.

Do you have a specific target launch date or hard deadline within the project? (E.g. you need a project phase to be completed by a certain date to send to the trustees for approval, or a stakeholder is taking an extended leave halfway through.) Starting the process early can make sure the project stays on track to meet a hard deadline, even with a few holdups due to unforeseen roadblocks. Andolsek (2004) recommends you give a project timeline six months minimum from inception to launch for organized projects, and at least a year if the project goals are not firmly set, the project is disorganized, or many stakeholders are included in the process. When setting a timeline, even with the most organized project, it is always good to confirm that your scope has realistic expectations; consult a trusted resource or the firms you’re in communication with, as every project is different.

Adding extra time at the beginning of a project is especially helpful to you as you write the RFP. Leaving extra time in your schedule gives you time to go back to potential firms or stakeholders with questions for clarification, and leaves time for the ever dreaded review by your legal department. It also gives you time to alter the remaining project timeline, should you wish to do so, based on suggestions from firms who submit proposals. We’ve already discussed above how you’re soliciting responses from expert firms, and chances are some of them will respond with solutions you haven’t fully explored or even considered at all. Sadly, very often, it’s the fact that an RFP took so much time and effort to produce that these valuable insights are dismissed because they are outside the scope of the RFP, and going back to the drawing board is not an option—even if that might result in a better outcome.

The RFP itself is also a detailed document that takes time on its own to research and write. Andolsek (2004) presents a list of tasks to consider when putting the RFP together:

Before writing

• Select the internal team and decision-makers;
• Outline project schedule;
• Analyze how current tech is meeting your needs;
• List project requirements;
• Define budget;
• Research potential partner firms;
• Send brief pre-RFP letter or RFI (optional);
• Review RFI/qualify candidates (optional);
• Set up interviews with candidate firms (optional).
• Develop final list of firms, estimate RFP release date.

Writing the RFP

• Develop schedule for preparing RFP;
• Review project requirements;
• Develop evaluation criteria while writing the RFP;
• Compare completed RFP and evaluation criteria to budget;
• Reestablish contact with list of pre-qualified firms;
• Publish RFP;
• Establish a location where FAQ responses will be posted;
• Provide an electronic copy of RFP;
• Be prepared to hold conference call if needed;
• Be prepared to receive/respond to firms’ questions;
• Specify contact protocol (e-mail only, no phone calls, time limit).

Some of these steps seem obvious—you know you’re going to have to put together your decision-making team and define a budget, but did you think to develop your evaluation criteria while writing the RFP? Peters (2011) recommends putting together a draft of your scoring criteria while writing, because that time is when you’ll have the best idea of your colleagues’ and stakeholders’ priorities when it comes to weighting selection criteria and direct access to ask for clarification if needed. Following the recommended steps above will take at least a few weeks, which is why it is best to get started sooner rather than later and give yourself extra room for unforeseen holdups.

Be concise and don’t lose sight of your project goals

Once you’ve started putting the document together it can be easy to get caught up in the legal jargon and long-winded explanations you’ve used to explain the project to stakeholders, but the RFP document should be short and sweet. Be specific—though not too specific—after all, you do want to leave room for creative responses to your RFP. The following information should be included in the RFP (Peters, 2011):

• Organizational background;
• Short project description;
• Project requirements and objectives
• Project budget;
• Milestones and deadlines (especially note any hard deadlines);
• Questions and required information
• Contact information and deadline for submissions

The rationale behind keeping the RFP short is simple: you set the tone for the responses you’ll receive in proposals. If you write a long RFP, you’ll receive equally long-winded proposals. Do you really want to take up more project time reading and deciphering long-winded, jargon-filled proposals? The answer is probably no. If you’ve followed some of the ideas outlined in the RFP process section above, you’ll have a better grasp on who and what you’re actually looking for, and a concrete set of project goals leading to a shorter RFP.

Keep your goals in mind when writing the proposal to prevent the padding that inevitably creeps into RFPs. That padding combined with the multitude of stakeholder wishes can lead to a big project—bigger than you currently have budgeted. Though difficult to do, it benefits you to rank stakeholder wishes in order from “critical” to “wish list” by considering things like how the project will be used day-to-day and by what department. Making a clear list of needs versus wants for the project will help you keep the RFP shorter and also make it easier for firms to propose a project that meets the project goals and budget. This leads us to the next aspect of the RFP that must be included: budget.

Clearly state your budget

Clear and simple, if you’re sending out an RFP with the expectation to sign a contract with a firm at the end, a budget needs to be included. Knoebel (2016) and his team didn’t state a set number, but instead included a range for the budget in Princeton’s RFP. Whether you have one number or a range, a number must be included for your RFP to be taken seriously by professional firms. RFPs without budgets are red flags to firms that your organization may not be serious about carrying through with the project, or that your organization is only looking for the lowest bid. Including the budget promotes honesty; firms that want to work with you will explain if they can’t make that number, and offer a solution if possible.

A word of warning: when it comes to budget, hiring professional firms can be compared to hiring a general contractor. If you’re receiving a range of similar quotes from firms in proposals and then receive an extremely low bid, that should be a red flag for you. There are many poorly managed, desperate young firms out there that will agree to your budget without really knowing if they can deliver for that cost. If they are ethical they’ll deliver but it will be at a loss; if they are unethical, they will demand more halfway through, but either way, neither party will be happy in the end. You can mitigate the risk of this happening by clearly stating a budget reached through the research you completed in the dynamic RFP process instead of asking firms to quote a price before revealing the project budget.  

When it comes to the budget, it is also important to make clear to firms what is “must-have” and what is “wish list” from your earlier conversation with stakeholders. Many RFPs, because they have been bloated, treat every requirement as a must-have—or at least fail to distinguish between must-haves and wish list items. But this, again, adds to bloat in proposals and inflated fees. Don’t make your potential partner have to guess which items are must-have or wish list. A good firm is going to want to deliver as much value as possible with the budget available. Sometimes things you might think are expensive wish list items are actually relatively easy to produce, and sometimes seemingly simple items on a must-have list contribute an inordinate amount of cost and complexity to the project. Sometimes the best compromise to meet stakeholder desires with a limited budget is to build the project in phases in order to meet your immediate needs, while setting up a roadmap for additional features to be added when the budget allows.

Conclusion

Writing a great RFP begins with approaching the process differently. Improvements like finding qualified firms before writing, making the process more dynamic by sending an initial Request for Information, giving potential firms the chance to interview the project team, and bringing in final selections to complete an audit of the existing project or site all help the process. In addition, the document can be improved by starting the process early, keeping the document concise to stay in line with project goals, and by stating a budget for clear communication with the firms responding to the RFP. By making these shifts, the broken RFP process can be changed into a productive means of finding truly effective partnerships.

References

Andolsek, Diane. (2004). “The RFP Process: From Request Through Proposal.” Museums and the Web 2004: Proceedings. Last updated March 2004. Consulted September 24, 2016. Available  http://www.museumsandtheweb.com/mw2004/papers/andolsek/andolsek.html

Cheyfitz, Kirk. (2015). “6 New Reasons to Kill the RFP: Find Innovators, Not Commodities.” The Content Marketing Institute online. Last updated Thursday, April 2, 2015. Consulted January 19, 2017. Available http://contentmarketinginstitute.com/2015/04/slow-death-rfp/

Gov.uk. (2016). How to Write your Requirements for Digital Outcomes and Specialists Services. Last updated Wednesday, August 10, 2016. Consulted January 19, 2017. Available https://www.gov.uk/guidance/how-to-write-your-requirements-for-digital-outcomes-and-specialists-services

Gov.uk. (2016). Talking to Suppliers Before you Buy Digital Marketplace Services. Last updated Monday, April 18, 2016. Consulted January 19, 2017. Available https://www.gov.uk/guidance/talking-to-suppliers-before-you-buy-digital-marketplace-services

Harrison, Cal. (2012). “Issues when Issuing an RFP.” Beyond Referrals online. Consulted January 19, 2017. Available http://beyondreferrals.com/issues-when-issuing-an-rfp/

Kieller, Kevin. (2015). “Why Your RFP is a Request for Problems.” No Jitter online. Last updated Tuesday, March 17, 2015. Consulted January 19, 2017. Available http://www.nojitter.com/post/240169740/why-your-rfp-is-a-request-for-problems

Knoebel, Christian. (2016). “How We Picked a Web Design Agency (Hint: We Threw Away the Usual RFP).” RE(design) blog, Princeton University. Last updated Friday, July 1, 2016. Consulted September 24, 2016. Available http://re.princeton.edu/blogs/how-we-picked-web-design-agency-hint-we-threw-away-usual-rfp

Peters, Chris. (2011). “An Overview of the RFP Process for Nonprofits, Charities, and Libraries.” Tech Soup online. Last updated Tuesday, May 10, 2011. Consulted January 19, 2017. Available http://www.techsoup.org/support/articles-and-how-tos/overview-of-the-rfp-process

Wayland, Michael. (2012). “Why We Don’t Respond to RFPs (Requests for Proposals).” IMC USA online. Last updated Monday, February 13, 2012. Consulted January 19, 2017. Available http://www.imcusa.org/news/83597/