A client of mine recently received a proposal from a software developer, and asked me to look it over and let her know if I thought it was “ok”. As far as proposals of work from an independent developer go, it was pretty good. It had a long list of bulleted items that would be included, was broken into 4 phases of work, with a separate cost estimate for each phase. The one thing it was missing, at a high level, was a delivery timeline estimate (would phase 1 take a week? a month?).
But the first thing I noted, in my feedback to her, was that it was very much written both by and for the developer.
I found that it was really good at detailing a bunch of technical tasks I was sure she didn’t specifically request. In some cases, it even detailed some tasks I wasn’t sure she’d actually want performed. Conversely, I recalled several specific features she wanted developed, that I didn’t see listed.
Incomplete proposals are fairly common, it can seem tedious to write out every little detail (and also feel pretty thankless before you’re getting paid), so I asked her, “Do you feel like he truly understands what you want?” and gave her a couple small examples of where his proposal didn’t match my understanding of the product she was trying to get built. One of her responses is what prompted me to write this post. She said:
“I didn’t see that feature in the proposal either, but I wasn’t sure. I thought maybe he included it, but just in technical terms I didn’t understand”
To me, that’s not “ok”. Before signing off on any proposal, or any other contract, formal or informal, you should always feel confident that you understand what it says.
So what’s a non-technical reader supposed to do?
Know what you want
You probably have a good idea what you want, and it’s ok that you do not know every detail involved in creating it, that’s why you’re hiring someone. Being able to spell out what you want may seem easy, but actually this is the bulk of the hard work you’ll need to do. “I need a website” is not sufficient, you need to be very clear about your vision. You need to go into as much detail as you can, and you need to understand any decent developer will likely still have good questions when you’re done. If you get stuck describing, in your own words, what you want, it’s ok to describe it by using examples – as long as you can be specific about what about each example you want (and what you don’t).
Get really practical. List out all the things you can think of, even little things, and even though it may be tedious: “show my phone number on every page”, or “customers should be able to purchase in USD with Visa or MasterCard, but not American Express or Discover”. List out everything you don’t know: “Can I use the merchant account I got from my bank to accept money online, too?”, or “Will the logo I bought for my letterhead work for the iPhone app icon?”
Ideally, you’ll have written all that down before you ask anyone to bid on the work. That way, when you get back a proposal or estimate, you can look for all the things you asked for. It’s actually a good sign, in my opinion, if the person bidding on the work asks for a copy of your list in electronic format to use to start their proposal.
If you don’t see some specific thing you wanted listed anywhere in the final proposal, but you know it was in your list, you’re in a great place to start a conversation about it.
Ask Questions
Even talking amongst themselves, technical people often say things like, “I don’t see feature X, can you point it out to me?” in a discussion about whether a written proposal truly covers everything. My client was worried that might be offensive to her developer, but it’s nothing to shy away from.
Best case, they simply forgot to include it, or summarized the information in a way that wasn’t clear to you. That’s easy to resolve, you just ask them to add it in or make that section clearer. Worst case, they intentionally omitted it, but even that can be a huge positive. If they intentionally omitted it, the reason may be because it’s beyond their skill set, or they disagree with it, or they believe it contradicts something else you requested. Any of those reasons can (and should) lead to a good conversation, and is certainly information you’d rather have now, than after a portion (or all) of the work is complete.
No matter how good your list was, how many questions you ask, or how much you ask to be rewritten for clarity, you should not feel bad. Even people whose whole jobs are writing specs (or designing software) forget things, contradict themselves, and ask “obvious” questions from time to time. The end result, and whole point, is a proposal that you feel confident you understand. You should be comfortable you understand what you’re going to get, and the proposed amount of time and expense it will take, just like any other decision you make about your business.