Let’s face it: we hate writing proposals. We’re engineers and we want to do what we do best: write code, design great architectures, try out new technologies, stuff like that. Nevertheless proposals are extremely important: no proposal -> no project -> no work -> no pay -> no doughnuts.
So here are my rules for writing a good proposal:
1) Embrace Proposals
Especially in times like these, where every customer seems to be cutting back costs, we should be happy about any request for a proposal that comes in. And with this positive attitude our proposals will get a lot better. The customer is our friend. We need her more desperately than the she needs us.
2) Think win-win.
Don’t be too cheap, don’t be too expensive. Just be fair. Customers are smart – they know if they can trust us or not. Both being too cheap and being too expensive may seem like loose-win or win-loose at first sight, but will lead to a loose-loose situation in the long run. If you’re too cheap, the customers get used to your prices and you won’t enjoy working for them anymore. Being too expensive will lead to unhappy customers, because they won’t trust you and find someone else for the job. We are exchangeable.
3) Don’t just think in terms of man-days.
Simply thinking in terms of man-days is not too bad. If estimated properly the project will cover your costs and maybe leave you some profit on top. But imagine you can finish a complex project in a short amount of time, because you already have this great component you’ve written in a previous project that you can use for this one, too? Ask yourself: how much is it worth? How much would others charge for the same project?
4) Cover your back
Always have someone else check your proposal. Never send a proposal to a customer, no one else has taken a good look at. Ask someone to check the proposal critically, question everything from the concept down to the pricing. The resulting proposal will contain less typos and someone else might find something significant you might have forgotten or overlooked. Maybe someone else will think it’s too cheap, too expensive, lacking detail or whatever.
5) Be complete and be clear
The clearer and the more complete the definition of the deliverables, the less potential for discussions with the customer there’ll be. Not only mention what you will deliver, also mention what you will not deliver. If the proposal is about writing a custom intranet application, be sure to mention that setting up the production and staging environment is not part of the proposal – if, of course, someone else is in charge of that. Sometimes, out of laziness, we write stuff like “standard reporting – 1000$”. The customer will probably have a completely different opinion on what a standard report is than you. Sentences like this have the potential of eating up your profit, because the customer expects you to make him happy. And instead of a CSV export of customer addresses, you find yourself writing a full featured CRM application.
7) Find the pitfalls
Every project contains risks. Think about worst case scenarios and everything that could go wrong during the project – e.g. introducing a new technology you haven’t worked with before. The more risks you find, the more buffer you add to the price. Sometimes it even makes sense to mention the risks and the customer will better understand the pricing.
7) Blurry details, blurry price
If it’s not completely clear what the customer wants and what the desired outcome of the project will be, you’re walking on thin ice with a proposal. In that case it’s often better to name ballpark numbers and ranges instead of a fixed price.
Is there anything I’ve forgotten? Let me know and leave a comment – I’ll appreciate it.
Alex
