Skip to main content

Tag: rfp

Content operations Podcast Podcast transcript

Creating content ops RFPs: Strategies for success

In episode 179 of the Content Strategy Experts podcast, Sarah O’Keefe and Alan Pringle share the inside scoop on how to write an effective request for a proposal (RFP) for content operations. They’ll discuss how RFPs are constructed and evaluated, strategies for aligning your proposal with organizational goals, how to get buy-in from procurement and legal teams, and more.

When it comes time to write the RFP, rely on your procurement team, your legal team, and so on. They have that expertise. They know that process. It’s a matter of pairing what you know about your requirements and what you need with their processes to get the better result.

— Alan Pringle

Read More
Opinion

To bid or not to bid—a vendor’s guide to RFPs

Request for Proposal (RFP) documents usually arrive in the dead of night, addressed to sales@scriptorium or sometimes info@scriptorium.

Dear Vendor,

LargeCompany is looking for a partner who can work magic and walk on water. Please refer to the attached RFP.

Signed,

Somebody in Purchasing

Our instinct is to crack open the RFP and start writing a proposal. But over time, we’ve learned to take a step back and evaluate the RFP first to ensure that it’s worth our time.

In this post, I’ve outlined some of the issues that we consider before responding to an RFP.

Qualifications

Are we qualified to do the work that the RFP is asking for? More importantly, are we qualified in the customer’s eyes? Many RFPs delineate evaluation criteria, which may not be relevant (in our opinion) to the task at hand. For example, we once saw a proposal for an Interleaf to FrameMaker conversion project that demanded expert knowledge of Interleaf. I would think that expert knowledge of FrameMaker would be more important, but the customer wanted Interleaf knowledge. FrameMaker was mentioned in passing. We decided in that case that our expert knowledge of the Interleaf-to-FrameMaker conversion process(es) should compensate for our minimal Interleaf expertise.

But if the RFP demands expertise that we simply do not have, and if that expertise, however irrelevant, will be weighted heavily in the evaluation, investing in a proposal is risky. The fact that we know we can do the project well is irrelevant if that customer will discard our proposal for lacking a required element.

Some days you’re the windshield, some days you’re the bug

It’s critically important to figure out whether an RFP is really looking for a vendor or not. Especially in large organizations and for larger projects, multiple bids are often required. The customer may already know exactly who they want to work with, but their purchasing department requires a minimum number of bids (usually three). Thus, the customer writes an RFP to get “column fodder”—the sacrificial second and third proposals to go along with the vendor that they really want.

We have experience on both sides of this issue. Sometimes, we’re the preferred vendor; sometimes, we’re the one getting the unwinnable RFP. Identifying cases where we have no chance of getting the business is critical to avoid wasting our time. Unfortunately, it’s also a bit of a black art. But here are some factors to consider:

  • Did the RFP parachute in from nowhere, or have we had previous contact with the organization?
  • Are there unusual requirements in the RFP? (For example, we decided against responding to an RFP that stated that close proximity to the customer would be a significant weighting factor. Not-so-coincidentally, one of our competitors just happened to have an office nearby.)
  • Is the project a marginal fit for our services? (In an effort to find additional vendors, the purchasing department might do a quick Google search and then broadcast the RFP. For instance, we get quite a few RFPs requesting outsourced technical writing services. Not the best fit for us.)
  • Is the customer unwilling to have a conference call to discuss questions we have about the RFP?

Most importantly, if your intuition tells you that there’s a problem, pay attention.

Funding

First and most importantly, is the project funded? In one painful case, we wrote a proposal and made the trek to the customer’s office (which was, naturally, on the other end of the country) to present our solution. (This site visit was explicitly required under the terms of the RFP.) Six weeks later, we found out that the evaluation committee had presented their recommendation to upper management and had been denied funding. In other words, the people who issued the RFP did not have approval for the project.

Assuming that funding is in place, there is the question of whether the funding will be sufficient. If the customer thinks their problem can be solved for $20,000 and our proposal totals $100,000, the sticker shock alone will probably be enough to kill our chances. This is why we often ask prospects about their expectations: how long do they think the project will take? How many people do they think should be assigned to the project? In some cases, we ask directly what the budget is.

How are bids evaluated?

RFPs that demand a list of services and hourly rates are a bad sign. Interestingly, government RFPs usually spell out evaluation criteria, using language such as this:

Selection of an offeror for contract award will be based on an evaluation of proposals against four factors. The factors in order of importance are: technical, past performance, cost/price and Small Disadvantaged Business (SDB) participation. Although technical factors are of paramount consideration in the award of the contract, past performance, cost/price and SDB participation are also important to the overall contract award decision. All evaluation factors other than cost or price, when combined, are significantly more important than cost or price. In any case, the Government reserves the right to make an award(s) to that offeror whose proposal provides the best overall value to the Government.

Corporate RFPs seem to avoid any mention of evaluation criteria, other than to state that certain items are required in a proposal or the proposal will be deemed “non-responsive.” The dreaded “non-responsive” label is attached to a proposal that does not meet the requirements of the RFP. For instance, if the RFP indicates that a response must include resumes and resumes are not included, the entire proposal could be discarded as non-responsive.

Evaluating risk

The decision whether or not to bid on an RFP comes down to evaluating the risk. Factors include:

  • Do we have other RFPs that look more appealing?
  • Are the deadlines reasonable (both for the proposal and for the project described therein)?
  • How many others will respond to the proposal?
  • How well does the customer understand the issues?
  • Does the RFP demonstrate an understanding of the problem the customer is trying to solve?
  • Has the customer already decided on their preferred solution and do we agree with the approach they want to use?
  • Are the evaluation criteria clear and relevant?
  • What is the pricing structure?
  • Does the project look interesting to us?
  • Do we want to work with this customer?

Of course, even with all these factors, the decision often hinges on intuition. Perhaps there’s something not quite right about the RFP. Turning away work (or potential work) is always difficult, but I think we’re getting better at sniffing out RFPs where we truly stand no chance of success. Or perhaps, despite several risk factors, we believe that we can work well with the customer and make a useful contribution.

Read More