- RFPs help you define things that are too late to define once you are working with an implementation vendor.
- Once the RFP is out, you've locked in the maximum impact your project will have.
Although it's always fashionable to deride RFPs (also see Toward Higher Impact RFPs), there's one key reason that RFPs are useful: they help you define things that are too late to define once you are working with an implementation vendor (digital agency, integrator, web shop, etc). Once the RFP is out, it's too late to make an even bigger impact. You've already locked in the maximum impact the project will make.
Once the RFP is out, it's too late to make an even bigger impact.
What are some things that are too late to define once the RFP is out or you are working with an implementation vendor?
- The breadth of the digital change. Got a problem with your current corporate site? The knee-jerk reaction is to send out an RFP to revamp the site (or simply reach out to an agency to do this). But perhaps it would have been better to make a more coherent digital presence for your site visitor, consolidating different sites (perhaps your blog is separate for example). But once you have sent out the RFP the die has been cast about the extent of change. See What's your number? Go wider for higher impact.
- The type of vendor you're working with. Some agencies are excellent for campaign sites. Others are strong for content modeling. Still others are better for integrating with complex backend systems or other more technical aspects. Or you may even need a set of vendors, such as one strong at data visualization, another at changing content workflows, and yet another at customer data platforms. Once you are working with a particular implementation vendor, then you are largely going to be in that "lane" of their specialties.
- The depth of the digital change. Too many digital changes are very shallow, for instance by either getting the veneer of pages looking better or perhaps only really changing top level pages. But sometimes the deep pages should really be the focus of change. Or sometimes change should be at a more structural level, such as introducing more structured content and taxonomy. One of the reasons this is difficult to tackle once speaking with implementation vendors is that there can be a lot of internal buy-in that's required, and this can take a long time. Once the team is in the mode of actually making the change, there's probably little time left to get that deep buy-in.
- An understanding of your actual problems and the overall strategy to resolve them. Self-diagnosing is tough. But by the time you're working with an implementation vendor, broadly speaking you have already defined the problems and your approach to resolving them (since you have defined a scope for them to work on). Ideally you work with a separate vendor to help define your very broad strategy first, to help uncover actual problems and get the buy-in internally to address them.
RFPs help you define things that are too late to define once you are working with an implementation vendor.
Fundamentally, you need to consider if you are going to attempt higher impact before starting work with an implementation vendor. This may require analysis and buy-in that takes time, so should be started well before getting into implementation mode.
The primary thing you can do to avoid this problem is in careful preparation of your RFP, and consider how you might be able to make broader and/or deeper impact.
Contact David Hobbs Consulting if you would like help in defining high-impact implementation strategies or in refining your RFP for better results.