How You Ask for What You Want May Determine Whether You Get It

Incompleteness, inflexibility, and unreasonable risk assignment can prevent you from getting the right vendors to respond to a Request for Proposal (RFP) for your technology transition. Having advised a client to step away from some RFPs, more than one of which I know with certainty their firm could provide great outcomes for, I thought this some valuable ground to cover.

Successful technology implementations are complex team efforts—there may be a number of other entities involved, e.g. software and infrastructure services, service providers, subcontractors, and stakeholders from related projects—but to simplify I’m going to focus on the two main parties: vendor and solicitor.

Vendor selection and engagement requires considerable investment and risk from both parties. Solicitors, simultaneous to their normal operations, have to engage with staff, supporting services, management, legal, and budgeting powers to document their needs, make a strong case for the value of the outcomes, and build the solicitation within their organization’s procurement framework. Vendors need to engage business analyst, software development, resource management, and legal resources to evaluate the solicitation and decide whether and how to form a response. This article provides observations from the perspective of a vendor in the digital asset management domain, and guidance on getting great players to show up at your tryouts, get drafted, and deliver big on what you’re asking for. Some of this may be applicable to RFP processes at large.

Solicitor Risks

  • Selecting the wrong technology.
  • Selecting the wrong vendor or failing to find one.
  • Over paying.

Which can result in these negative events:

  • Cost and schedule overruns.
  • Loss of management and team support.
  • A project “do over”.
  • Continued negative impacts from not addressing the drivers for the RFP.

Vendor Risks

  • Selecting the wrong client.
  • Not being awarded a contract.
  • Being awarded a contract they have under bid.
  • Overlooking unreasonable contract and compliance stipulations.

Which can result in:

  • Poor client experience and reputation damage.
  • Financial losses.
  • Missed business development opportunities.
  • Resource allocation and morale issues.

The Unfortunate Thing

The preceding informs you vendors have big incentives to succeed in delivering your wishes, yet: A vendor that may produce the best outcomes for your solicitation may not respond to your RFP. Why? Simply put: A vendor must commit to providing the client the right return on investment (ROI) to be selected by this process. They need to see ROI as an outcome of that.

How people might read that stated as such, illuminates one of the differences in perception that can be present in the evaluation process. As a solicitor one can read it and have thoughts about vendors being all about profit, the end. From a more objective standpoint: Let’s acknowledge profit motive and add that it takes copious resources to create great technology solutions and keep the best talent available for clients; also, that the best companies are those with a great passion to serve in their field of expertise. No reputable firms that succeed over time are just about the money. They deliver on all fronts. I believe that a more reasonable position to be coming from, and it’s reflected in what follows. Let’s dive.

How to Get Through the Qualies

Processes vary across vendors, but before any firm engages resources beyond sales staff in responding to a solicitation it will be in the hands of someone wearing a BA (business analyst) hat. To qualify the solicitation, i.e. mitigate all of the risks listed above, they’ll be looking for signals to respond or not, checking fit and risk. The best athletes will not enter a competitive event unless a select criteria are in place, and the success of that event depends on them doing so. It’s no different for technology projects RFPs are issued for. Here’s what I’m looking for when I wear my BA hat (it consists of silver hair), and tips on keeping good talent in your search process.

Solution Alignment

Do the needs stated in the RFP align 80% or more with the offering we can respond with?

No solution will align 100% with a solicitation. Read that again, we’re gonna loop back. The higher the alignment between what’s being asked for and what a vendor can deliver, the more sun shines on success.

Can we bridge all high priority feature gaps?

For high priority features requested that are not present in a vendor’s standard offering, they must be certain of delivering acceptable solutions.

Does the RFP acknowledge any deliverables that may be speculative? Is there a post award discovery process built in?

Some deliverables are speculative by their nature and/or the constraints of a reasonable investment in a response, e.g. custom software development and data migration. How this is acknowledged in an RFP, or not, is often a signal for how much technology development experience a solicitor has. I see two flavors of this frequently, paraphrased:

  1. We demand perfect alignment with every feature/deliverable as expressed (even if incompletely or poorly) and you the vendor are indemnified to that, pretty much in perpetuity, no matter what we say verbally, ever.
  2. We acknowledge that some parts of technology implementation can be speculative, dynamic, and require flexibility in how requirements are met, and have built this into our plan as follows. . . .

Keep Good Vendors in the Process

  • Keep in mind basis for these qualifications is how well your needs* have been expressed in the solicitation. The better formed a request is, the better the response should be.
  • Be thorough, clearly prioritize, and supply all needed supporting materials.
  • Scope functional features in the RFP to those that will actually be used. If they are in use now or will be within 90 days of your Go Live date keep them. If not leave them out or place them in a non-binding section communicating candidates for future features.
  • If basing requirements off of a template, or copying them from some source, audit their contents for relevancy to your use cases. (Yes, this happens, and it’s horrible if discovered late in the response process.)
  • Strive for perfection but don’t expect full attainment. The 80% rule is pretty solid, anything higher indicates a good potential technology choice.
  • Include a framework that allows some amount of post award discovery for high risk, speculative, or incompletely defined deliverables, allowing vendors to bid a range initially, fix a budget for discovery, and finalize in the project plan. With your 80%+ covered this isn’t breaking, it’s bending to reality. Every project I have been engaged with that undertook a discovery phase before finalizing their project scope‒and that is many‒has had better outcomes. Every. One.

* I keep saying things like “stated needs”. Why? Because a majority of software features labeled ‘requirement’ in RFP’s, are not. Software requirements have explicit impact statements, use cases, behavioral descriptions, and test criteria. Something like “solution shall be capable to watermark images on ingest” is not a requirement, it is a stated need. As such it’s poorly defined and might represent a wide range of effort. (I’ll guide you through that wormhole in a subsequent blog.)


Can the solicitor afford what they are asking for?

If it’s clearly stated in the RFP, at least by something to the effect of “a budget not to exceed $n is allocated [insert constraints here]”, a good determination can be made on the feasibility of meeting solicitor expectations within their budget. If no budget constraints are given, and/or the solicitor refuses to give such information (sadly this is often, owing to the “they’ll just bid our max” fallacy), the quality of this evaluation suffers. It also says the solicitor may well not have assessed or assigned a value to the request. Vendor score of risk is raised and they must work from whatever publicly discoverable intelligence they can mine.

Keep Good Vendors in the Process

Solicitors should know the value of what they’re asking for. The exercise of assigning it mitigates the risk of overpaying almost completely. Put it in the RFP. Vendors can’t help deliver the most value for your budget without it, and in my experience often add value to meet it. I'm leaving out a rant on the ethics of stealthily pursuing $250K dreams on a $20K budget.

Pricing Commitment

Which deliverables are fixed price?

Certain deliverables are known quantities and straightforward to fix price for, for example hosting and support contracts, or base software and installation packages. Others are not, such as (mentioned earlier) custom software development and data migration. If a fixed price is stipulated for the latter the solicitor may have just guaranteed some things for themselves, assuming vendors stay in the game: high bids and cost overrun risk.

Are Any Contract Terms Non-Negotiable?

As with deliverables there are some no-brainers with contract terms; however, there are other terms whose flexibility may benefit solicitor and vendor, e.g. decoupling payment for custom deliverables or migration from out-of-the-box deliverables, discounts for timely payments, fixing price increases for long term projects to price indices, etc.

Keep Good Vendors in the Process

  • See my earlier guidance in Solution Alignment around post award discovery.
  • If possible, don’t fully prescribe invoicing schedules. If not, allow proposal of alterations or alternatives for consideration.

Predetermined Outcomes

Some solicitations, despite being in open bid systems, are written for a specific vendor or technology. Any competent vendor knows competing technology and firms quite well. Tell tale signs:

  • Near perfect alignment of stated needs with a specific though unnamed solution and/or provider.
  • Polite “pound sand” responses to requests for information to assess integrations with required third party applications.

I’ve seen a couple drivers for this:

  1. The solicitor has been unsuccessful at lobbying their procurement framework for a single source exception for their desired provider. They must go to open bid.
  2. Solicitor stakeholders have decided on a solution prior to issuing a solicitation.

There are other predetermined outcomes that may or may not make sense as well. For example, if your organization’s IT is providing support for the solution and they use a specific platform, well, that makes sense as a constraint. However, if a solicitor stakeholder prescribes a given database technology for a solution without a really, really solid basis, that pretty much harpoons the benefit of opening up your requirements for review by experts with a wide array of options.

Keep Good Vendors in the Process

  • If your organization is issuing an RFP with a predetermined outcome it is unethical and unfair to vendors. I urge pursuing a better course. When I smell this I start looking at other risk indicators closely, and other solicitations a bit more dearly.
  • Don’t solutionize excessively. With the exception of some rare cases it can be disastrous. Remember: You only know what you know. Open minds always acknowledge better solutions may exist, and that there may be risks they are unaware of. Express the impacts and needs the desired solution must address and let the universe conspire for you.


Is the timeline reasonable? Flexible?

Irrespective of resourcing the timeline stipulated by an RFP may be reasonable or not. If it is reasonable resource management on the vendor side has to have availability.

Is the solicitor resource availability stated?

It’s not only vendor resources that are required. If the solicitor hasn’t dedicated resources to interface with vendor project management and developers during implementation delays will be introduced.

Keep Good Vendors in the Process

  • Describe the resources allocated solicitor-side by role, % FTE (full time employee), and the timeline they will respond within to requests for materials and information.
  • If possible, indicate a range of acceptable start dates and a not to be exceeded date for final deliverables. Also, clearly indicate mandatory first Go Live release deliverables and any that may follow an initial release.

Engagement: Getting to Know One Another

Is there a demonstration round? Vendor Q&A with primary stakeholders?

I recently worked as a solution architect for a project who disclosed only when I made it to their location to start implementation planning that they had never seen the chosen solution. Take that in for a second. No one, not management, production staff, anyone, had any interaction with the platform being implemented. Their procurement process had denied this. This and other constraints that prevent interfacing with solicitor stakeholders during the response process - fair and regulated means of which need to be in place - will have negative impacts.

What is the content, tone, and nature of the RFP and responses to questions?

Most RFPs communicate organizational culture to some degree, and if they have at least a written round of vendor questions, more is revealed. Good vendors are looking at who you are since they know from experience a technically perfect solution can be tanked by toxic culture or individuals. After steering one of my clients away from an RFP (which was the final driver for this article), I followed along the Q&A round as a sort of diligence exercise. When a solidly qualified vendor made a well formed, conforming request for a reasonable variance on a couple requirements, the response was: “Protest denied.” Vendors get to know solicitors by their actions. This didn’t seem to promise a collaborative environment. I don’t regret my guidance.

Keep Good Vendors in the Process

  • Include a round of demonstrations in the solicitation process. It may be most effective to have a two round selection process where the field is narrowed first.
  • Remind your team the quality of your communication counts, as does positive attitude. Change is tough but inevitable. Consider carefully how you will handle holdouts and their role in the process.
  • Give due consideration to vendor questions and requests and be reasonably flexible in your responses. (Hey, they’re working for you for free until selected.)

Compliance Review

This evaluation generally falls into:

  • What regulatory standards must a response conform to?
  • Which applicable industry standards is knowledge assumed of?
  • What legal liability is being assumed?

The devil can be in the details. If the RFP doesn’t budget for compliance testing on any front, but contains legal verbiage assigning the vendor liability for damages and/or remedy for work performed at the solicitor’s behest, this is a big red flag, especially if it survives a warranty period, or, is accompanied by clauses that say the contract is not subject to negotiation.

Keep Good Vendors in the Process

  • Be thorough in listing anything in the first two points above. It’s great to know up front.
  • Read from a vendor perspective the clauses assigning liability. Many times these are templated institutionally for broad use and contain statements that are reasonable for one type of purchase (a building) but not applicable in a software domain. Be willing to approach your legal team with any questions of your own that may lead to revisions (pre issue) or those that come back from a prospective vendor.

Omissions from This Article

This isn’t exhaustive. (Merely exhausting.) I’ve omitted some categories of RFP content that most seem to handle well, e.g. response grading criteria.

Vendors are Only Here for You

As a vendor or representative I know I only get to work in my chosen field if I continue to deliver what clients need when they need it. All negotiations can be collaborations and the RFP process is a first chance to work together. Attract the best provider responses by laying the groundwork for mutual success in your RFP. If you think I can help: contact me.