Today is a great day. A new potential client has come knocking on your door, and they’d like to consider you for a project. Thrilling as it may be, your excitement quickly turns to anxiety as you realize that the next thing they want to know is “how much will it cost?”
Here begins the great struggle of web business development. You need to know what you’re building before you can know how much it costs to build it. But accurately mapping out the scope of a project could take weeks of focused effort. That’s probably not something you can give away whenever you get a request for a quote. So what do you do? Make up numbers and hope you’re on target? Undershoot and you may land a job that cripples your business. Overshoot, and you may unnecessarily send that new client packing.
Fortunately, it doesn’t have to be this way. Defining the challenges, solutions, and strategies for the project to come is some of the most valuable work you will do for your client. Not only is that time worth paying for, but the resulting deliverables will be critical to the success of the project, regardless of who they hire to complete the next phase.
Let’s look at how we can structure a pre-project research phase that will ensure that—on completion—everyone’s ready to hit the ground running with design and development. By the end, our new client will know more about their organization and web project than ever before, and you’ll be able to create a much more accurate budget for subsequent work.
Let’s do it! What are we doing?#section2
So there it is. That unread email with the subject line Fancy Organization Request for Proposal.
It’s a website redesign: no surprise there. And, wait—oh miraculous day—they even told you their budget. They have $100,000, which is enough money to do some real stuff. But what stuff do they want? Poring over the pages, you realize quickly that it’s not so clear. Some of the requirements they state, in fact, seem vague, strange, or misguided. As much as these folks are hoping you can take their RFP and give them a precise quote and a plan of action, you know in your bones that you need more clarity—and clarity rarely comes easily.
Smaller is better#section3
So instead of putting together their requested $100,000 proposal, what do I do? I put together a $20,000 one. This, my friends, is unexpected. Gutsy, even! This is not what they’ve asked for. The gall. The nerve. The chutzpah!
Alright, let’s acknowledge this right now: there is risk involved in this approach. If I turn in something that looks entirely different from what the client is requesting, they cannot compare apples to apples with the other proposals. This may not fit into their (potentially rigid) RFP process. Our proposal may get tossed out in the very first round, just for being different.
On the other hand, this may be exactly what makes us stand out. Rob Harr from Sparkbox has a terrific line that I’ve started using myself: “I’m going to embrace the fact that I’ll know more about your project tomorrow than I do today.” For some clients, that may be a refreshing dose of honesty and creative thinking. And I don’t know about you, but those are the clients I really want.
One caveat: though we’re holding off on producing an accurate second phase budget until later, we still need to address the general cost of future work in some way. It’s a good idea to take a stab at a ballpark range for the second phase, with the understanding that it’s a bit of a shot in the dark. That way everyone will at least have a sense of the magnitude of a second phase, and can plan accordingly.
So what are we actually pitching in this smaller project? Well, it’s the first part of the bigger project, naturally. Depending on the nature of the project, it may require different tasks and deliverables. But we’ll likely include things like meetings, interviews, information architecture recommendations, branding analysis, a copywriting style guide, a content audit, wireframes, and style prototypes/style tiles. Whatever we end up doing, we’ll compile all of the research and conclusions we draw in the specification document, which is the central deliverable we provide at the end of the phase.
When putting together a standalone research phase, the trick is to focus on work that will help you more clearly define the project. That way you’ll have a well-formed plan for a second phase, and can provide the client with a much more accurate budget for that subsequent work.
What does everyone get out of this?#section4
In all likelihood, I don’t need to sell you on research. Understanding what we’re going to design and build before we begin means we can create better things, more efficiently. But why, when we have the opportunity to sign a big contract, would we opt to sign a small one? Why, indeed!
It’s good for clients#section5
You know what’s scary? Handing a big wad of money to a stranger. That’s what a big initial contract is like for a potential client. A smaller introductory research project lets a new client wade in ankle-deep before the big plunge.
Not only are they making a smaller commitment of time and money but—by the end of the project—they’ll know if you’re a good fit for them. If everyone decides to part ways at the end of this phase, they’ll still have valuable deliverables to help them jump-start the project with a different team.
It’s good for you, too!#section6
And this goes for you, too. There’s nothing worse than signing on for a year-long project with a new client, and then realizing a month in that it’s a bad match. The pre-project project lets you assess the relationship in a low-risk environment, and decide if it’s worth continuing.
From a business development perspective, this initial research project has a lot of appeal, too. Sure, you’re not landing a big ticket contract just yet, but bear with me on this one.
Proposing is time-consuming#section7
If you’re a small company like ours, you likely don’t have a dedicated sales person. This means that responding to RFPs is costly, and before long you’ll have to start making some hard decisions about which proposals you can afford to write, and which you can’t.
The nice thing about research phase proposals is that they tend to be very similar from project to project. By definition, these proposals don’t include very much about the specifics of the work being done, so a chunk of well-written boilerplate in your proposal gets you a lot more mileage. Investing less time with each proposal means that you can respond to more proposals. Wider net, less effort—without sacrificing quality. Yay!
Your feet, their door#section8
In my experience, when you don’t have a proven track record with a client, selling a $10,000–20,000 project is a lot easier than selling a $100,000–200,000 project. This little research project helps you get a foot in the door with that new client, and prove your worth without resorting to something devaluing like spec work.
A clearer future#section9
As this phase is nearing completion, you’ll be able to create a much more accurate budget for phase two. Because your research has generated a well-informed project definition, there will be much less guesswork, and a far greater understanding of the project’s requirements. In effect, you’re getting paid to write the best proposal ever. And you should be! The insight into the project and organization you’re providing is vital work that ensures that no one will be jumping into the project blindly and simply hoping for the best. That’s because now you’ll have something that every project desperately needs, but surprisingly few actually have. You’ll have a plan.
Hi Matt,
Very interesting strategy. From your experience, I would like to ask you about one detail. What percentage of that kind of proposals are rejected at the beginning?
Thanks,
Jakub.
Hi Jakub,
It’s about the same as our full proposals. About 50/50, maybe 40/60. We haven’t been great about paying attention to the details of that pipeline, sadly (one can’t do everything all the time!). But we’ve just started setting up https://getbase.com/ to get a better idea of how things like that affect the success rate. I’l let you know what we learn from that!
MG
Hi Matt,
Great article. I’m on board with this approach and have practiced it myself.
In your experience, how often has one party, you or the client, opted to split before the second phase? In the case of you not choosing to proceed, how has the client received your decision?
Thanks,
John
John,
I’ve actually yet to have a second phase not occur! I think the motivations that come out of this scenario really encourage building a team relationship with the client. So usually everyone’s pretty stoked to keep things rolling for a phase 2.
I think I’ve also developed a pretty good radar for bad fits from an initial meeting, and that often keeps me from taking things any further in that case.
When I’ve had to deliver the “bad news,” though, it usually goes better than I think it will. If things aren’t jiving, it’s usually obvious from both sides. As long as you help them transition elsewhere (at least give them a few names or introductions), it doesn’t make sense for anyone to get too bent of shape. In fact I’ve found that, given a well-intentioned approach, most people will surprise you with their understanding, even when ostensibly rejection is at play.
MG
Matt –
Great post. I’ve used this approach many times and would agree with your points. Some of the challenges that we’ve faced:
– As you mentioned, it’s a good idea to deliver some sort of range for the future phases. However, for those RFPs that are very unclear, it’s difficult to deliver a tight range. We’ve had to deliver ranges that may go from $100k – $500k, purely because of the unknown. This can certainly scare the prospective client.
– The client will for sure receive a proposal from another firm saying exactly what they want to hear, with an exact budget and timeline. I’m assuming these firms have just guessed because of their desire to win the work. Clients that go with these types of firms probably aren’t a good fit for us anyway, but it’s still frustrating.
– I have received feedback that this approach has a perceived lack of confidence/vision. “Tell us what we should do and how much it will cost.” As a result, I’ve had to adjust and carefully explain WHY we do it this way. Clients that value this approach tend to be a great match for us.
Thanks,
Billy
Great post. I was just having this discussion yesterday.
Billy third point about client viewing this approach as a “lack of confidence/vision” is a clear warning sign that you might not want the project in the first place. It indicates a “corporate procurement” type mentally that focuses on supposedly tangible things like number of pages, templates and design comps rather than solutions that meet real needs.
Hi Matt,
This article is so refreshing. I am a solutions architect for a firm in Boston, it’s really just a fancy word for sales. However, I have been a design and developer for more then half of my life. With that experience, this was something I introduced into our firm about two years ago and let me just say it was the best choice ever! it really works, it’s good to see others who think alike.
Cheers,
Michael
Billy & Chance,
This is the tough stuff, right here! Trying to navigate a new organization’s culture and history, and all the baggage that comes with that, can be quite difficult. Sometimes all you need is more clarity and frank discussion; other times old beliefs are too deeply ingrained, and that alone will mean you’re not a good match.
But certainly, there will always be those that will accept nothing but a precise definition of all work, right off the bat – regardless of its actual accuracy. In my experience, though, many organizations have been burned by that before, and when someone finally comes along and confidently declares “I don’t know the answer right now, but I’m going to find out,” they find the honesty refreshing.
Of course, sometimes there is so much red tape, that no new ideas can squeak through, no matter how sensible.
But hey, if this stuff was easy, we’d all be bored, right? 🙂
MG
Thanks, Michael!
MG
Hey Matt, thanks so much for taking the time to write this – it’s an excellent approach I’d definitely like to start adopting myself.
Great article Matt.
This is exactly what we are doing now in our organization with one difference. The firm that will do the pre-project research will not be able to apply for the actual redesign as it is considered by our legal department unfair competition for the rest of the firms that would apply for the redesign tender due to the knowledge that will acquire during the research phase and the influence that the research will have in the definition of the specifications.
Unforunately public procurement legislation is not so flexible.
Nikos,
Interesting! My perspective on this is that it’s assumed that we’re the firm that has been chosen to do the whole project, barring unforeseen incompatibilities. There’s no need to do another RFP search, unless it seems like it’s not a good match after phase 1.
MG
Matt – good read! We’ve been talking about this very thing for some time. Good to see there are others that get it, which is going to kick us in the ass to actually implement this in applicable situations.
Typically, we don’t respond to RFPs because it assumes one (the client) could check off boxes of a requirements checklist and assume they’ve got the perfect match (the agency). Everyone knows relationships don’t work that way. Heck, if my wife were to go back and see if I was someone that “checked off the boxes,” we wouldn’t be married. 😉
Thanks, again!
Hi Matt:
I think this is good way to tackle larger projects; by splitting the entire project into a stage for discovery, research, and scope definition, and the rest of the project. For clients that have a large budget and a project that will take a long time, this allows both sides to see if they can work together with minimal damage if they decide “No”. The client has a well-defined scope at the end that they can take to another agency if things don’t work out.
A small project is always best for a first project when you are dealing with someone you have never worked with before.
Great article, especially for an IT architect who gets called to help creating RFP and evaluating the responses.
I find it very hard to create RFP with no details and get more surprised when I see vendors responding with exact time and cost to vague RFPs!
This encourages irresponsible, vague RFPs and can only be avoided if vendors are willing to refuse to provide all inclusive initial response, instead proposing a two phase approach.
It hurts me more to see such proposals (when it happens) being rejected just because they did the right thing in my opinion by suggesting a two phase solution!
Well, I can only hope that conventional wisdom will eventually prevail and IT folks gets educated on writing clear RFPs with two phase proposal, which may require a cultural shift for both parties?.
I like the integrative approach, you may be reaching a latent need. The typical rule here is consumption depends on availability, the typical outcome is usually over budget. This can lead to the building of an aversion, maybe a systemic problem why it’s tougher to get jobs if you are new to the prospective company. Since they believe it’s probably going to be over budget. So this approach can offset that aversion and reframes the question as well.
I think one place that needs to be covered and is salient to the client is to also ensure them that Phase #1 is modular enough to simply pass it off to the next firm if they wanted to go another direction, again calming another aversion of the failed tech projects in the past.
Unique approach.
Thank you for this article. I’ve often mused that clients’ requests for proposals are like asking a building contractor to give a quote for a skyscraper when the architect hasn’t even finished the design.
I just offered a version of this to a client whose WordPress site needs a rather major update of WP and all 30-some-odd plugins, and I can see there’s quite a bit diversion from best practices already. So rather than stabbing in the dark for what it’d take to do the whole job (2 hours? 20?) I suggested that I simply clone the site locally and run all the updates in order to figure out what will break. That’s a job for which I *can* actually estimate a number of hours. Then I stand a chance at an estimate for what phase 2, the actual fixing, will take. It feels so much more prudent to proceed this way.
And as Christian noted above, I actually stated that the client may wish to call on another developer to do phase 2, and/or I may even recommend that, should I determine that the work is outside of the scope of my own skills.
Thanks again all.
Thanks, everyone! Glad the idea was helpful to you.
Susan: that sounds like the perfect approach for a problem like that. Thanks so much for sharing!
MG
I literally JUST followed this approach with a proposal I submitted yesterday. It’s so logical, I wonder why it feels so radical?! Anyway, great article, thanks for sharing.