You’ve got a software project — you just need the resources to do it.
So you start writing an RFP (Request for proposal). You put down the budget, timeline and deliverables in an effort to properly scope the initiative. After all, you need to find the best qualified team which means you need to be as specific as possible.
Then, you sit back and read what you’ve outlined.
After your brain gets back to its normal speed, you realize that if you can’t keep yourself awake, you have little hope of keeping potential teams engaged long enough to gain interest in your project.
As the recipient of many RFPs, I can tell you that they rarely come true in their original form. An RFP is meant to be the beginning of a conversation, not the end of one. No one expects you to have all the answers. If you use your RFP as a conversation guide with prospective teams, you will get more authentic communication and less false promises.
What is a RFP and why do they put people to sleep?
The goal of an RFP is to cast a wide net in finding the right team to take on a project. They are used as a way to get multiple bids without having to waste time explaining the project multiple times.
Traditional RFPs include key deliverables specified to an excruciating detail. I’ve received documents that detail the back-end technologies that must be used—for no particular reason. Often, they include the team qualifications, questions for said team to answer and maybe a project timeline complete with launch dates. When we receive an RFP, it can help set the context for a project. The challenge is that before our team is able to truly dive in and problem-solve, it’s difficult to know how the solution will come together and even more difficult to plan a project’s timeline and budget.
Our Director of Design, David Hendee, says writing an RFP is a bit like a writing a float plan for a sailing trip. When you set off, you know who’s on board, where you are headed and what equipment you have on hand, but you don’t know the exact path you will take, what conditions you’ll encounter, when you will arrive — and sometimes your destination changes along the way.
Stop planning, start driving
Software used to be planned in months — even years — with giant feature specifications. Fortunately for us, there’s a better way to work: enter the agile process.
Agile software development emerged in the early 2000s as a reaction to broken processes that degrade quality of work. The focus moved from committing to months-long sets of work months at a time to short, fast cycles of work that prioritize team communication, on-going learning, and frequent reflection. Both customer and technical learnings are uncovered in this framework which allows the team the flexibility to adjust to changing “requirements.” With agile practices, the team keeps goals (not tasks) at the forefront, readjusting individual tasks to make sure they reflect those goals as new information is discovered.
Ok, so then what? How do you find the right team?
During a UX Bookclub of LA interview last year, I asked designer and author Kim Goodwin about the ideal project brief. She talked about her favorite product requirements document (PRD):
“I have seen these things be 170 pages of painful detail, most of which got thrown away. My favorite one was a one page document that basically outlined ‘who we think is the audience?’, ‘how big do we think the audience is?’ ‘what’s the problem we’re trying to solve for them’ and in really vague terms, ‘what’s the kind of the thing we think will address their needs.”
Start by considering why you are writing an RFP in the first place. What led to this project? Then, start talking out loud. Record yourself or have someone scribe for you. Open with why your company wants to embark on this project. The goals of your project should be paramount to its execution.
Write just like you speak: conversational and accessible. Outline the sections in as few lines as possible, frame your project. Timeboxing your writing to an hour should help keep the outline focused and succinct.
- the primary goal of the project
- who the market might be (this could be a guess)
- an estimate of the overall size of the opportunity
- any team members who will be involved and their role on the team
- how to measure the success of the project
- a few essential questions to guide the beginning of the project
- any reference links (if there is an existing project that related)
Consider not including:
- a request for qualifications (RFQ) — if you don’t think a team is qualified to do the project, don’t send them your RFP
- walls of text — keeping your RFP as concise as possible will ensure better understanding and faster response time
- specific tasks — these will come together once you select the right team
- deliverables — your goal is your deliverable
- launch dates — with continuous deployment, we’ve abandoned the idea of the big reveal. Your goal will determine your timeline, your budget will determine the amount of work that can be completed towards that goal. (see agile development above)
Once you’ve framed out your project, you can share your RFP through Google Docs or Hackpad with a couple of colleagues to get feedback. As you share it with each potential firm, you might ask for their feedback so you can improve it throughout your search.
Regardless of how well-written your RFP is, it is not a substitute for a conversation. In fact, you can even skip the RFP and just schedule the meeting. If having an RFP helps you sleep better, ease into it goals first. Regardless of how you communicate your project ideas to possible collaborators, remember that asking the right questions often yields better results that stating potential answers.
Check out the example RFP template: http://goo.gl/yVLUWj