My business – and that of many of my friends, colleagues and tweeps – quite often involves responding to requests for proposals (RFPs). It’s a necessary process for getting new work, new clients and tackling new challenges. And it can be a fairly arduous process. It takes time to craft a response that’s detailed enough, but not so detailed that you actually find you’re already a quarter of the way through a project you haven’t even been awarded yet.
Over the last month, I’ve put together myriad proposals – some large and some small. And while most RFPs carefully spell out the requirements of a project, there are many out there that are so poorly written (or so obviously boilerplate with little thought given to the exact requirements of the particular project they’re meant to address) as to be nearly impossible to properly respond to. It is the poorly-written or unclear RFPs I want to discuss in this post.
I’m fortunate that the places I work aren’t bereft of new and continuing projects. The state of the economy hasn’t knocked projects off our docket. We might be the exception to the rule, and for that I’m truly grateful. But that doesn’t mean we can just rest on our laurels with our current roster of clients and lazily coast through the times. We still need to develop new business, grow, take on new projects and challenges so we can stay on top of industry trends and hone our craft (in this case, I’m talking web design and software development). In some cases, this means making pitches to current client to try new things, change their images, add some functionality to a website.
However, in other cases, we go out hunting for new clients, and lately this has meant responding to RFPs. Some of these RFPs are wonderful, in that they clearly communicate project requirements, timelines and client expectations.The really excellent RFPs make us excited to bid on a project.
Other RFPs, though, are absolutely abysmal. They read as hastily assembled, over-jargoned and needlessly bureaucratic messes. At best they contradict themselves. At worst, they fail to engage potential clients, and generate excitement for what might otherwise be an exciting project.
Firms putting out RFPs need to consider not just what they’ll be getting back, but what they’re putting out into the world. Bidders may pass on your proposal if it’s reads like a disaster.
Now I understand that most RFPs provide for time for bidders to ask questions and have them answered. However, an RFP should be written in such a way as to mitigate a raft of questions. Bidders should be able to ascertain fairly precise parameters for a project based on that initial document.
An organization’s RFP might just be the first introduction some firms get to a company. They should reflect the image organizations are trying to convey not just for their project, but for their reputation as well. This doesn’t mean they have to be incredibly visually designed documents. But they should be coherent and clear.
I’m in the business of communications, and the projects I bid on at work are for communications-related projects. If the first point of contact is already muddled, both parties will wind up wasting time seeking and providing clarification. Some bidders might just pass on a project.
Either way, if you’re in the business of crafting RFPs, remember that document templates provide the framework, not the meat of the proposal. Carefully review your RFPs before you send them out into the world. Make sure your expectations, requirements and desired timelines are communicated with no ambiguity. Do this and I will happily bid on each and every one of your projects.