Printable View
Myself and a friend have been asked to design a simple website for a local business. We will be meeting with the client this week but I am unsure about some of the key things.
Firstly, a Proposal. What is it for? And what should be included? It would be very helpful if someone had a sample that I could look at.
Secondly, contracts. Is a contract a must when designing a website for a client?
Thanks
Rob
Welcome to Sitepoint, Rob. :)Quote:
Originally Posted by rob321a
A proposal is a type of price quote for your client. Most companies have their own style of creating them but most proposals have some elements in common. Here's a link to some Site Point articles that can help you form yours:
http://www.sitepoint.com/search/sear...&submit=Search
Yes, you should have a signed contract in place before you begin work for any client. If you just search "contract" in this forum you'll see plenty of reasons why and plenty of ideas on how to design yours.
I really don't think it matters what you feel a proposal is. All that matters is what your prospect is expecting when he or she asks for one. I've found that a 'proposal' can mean a 1 paragraph estimate, a 1 page quotation, a 30 page in-depth report and technical specification or a 1/2 page executive summary.
Hence, you have to ask a prosepct what they are actually looking for to complete their buying process. In fact, I ask them during our first phone call
'If at the end of our meeting I've presented you with a solution that meets all your needs, what would be the next step for you?'
If their answer is 'We'd like a proposal', I ask them straight:
'What would this proposal need to contain?'
In many cases, all that is actually being asked for is a brief summary of what we discussed and a confirmation of the estimated costs - what I'd call an 'executive summary'. I personally feel that this is the absolute most you should provide until you have a signed contract. An executve summary is not a detailed project specification, it's a brief report that summarises the client's situation, their needs, wants and objectives - i.e. you are showing your prospect that you understnad their problems. It then briefly covers the kind of work that will be done to solve that problem (maybe one or two paragraphs) and then gives a decent estimate of the costs and timesales involved. I try to keep these reports to one page and spend no more than 1 hour preparing it.
AFAIK, if the prospect wants a detailed, multipage project specification, they get one when we start the project as this should be the first stage of the project process and something that will probably take several hours or days to create. If they feel they require one before they are willing to commit, then fine - charge them for it and if they give you the job, you can discount it off the final balancing payment.
BTW - I've said this before, but the aim of the sales process is to secure the job in as efficient manner as possible. If you feel you can close a sale during your initial sales meeting, do so. If the prospect isn't asking for documentation, don't offer it - if you do, of course they'll want it, and you just added even more time to the sales process. Too many web developers feel it is an obligation to offer to write a proposal - it's not and it's usually completely unnecessary. You should be able to win over your client by showing you understnad their needs, by referring to previous case studies, presenting them with testimoinals and referrences, etc - you shouldn't be expected to create a complete minutely detailed A-Z of what you indend to do, how you intend to do it and exactly how much each bit will cost and take to complete - not for free and certainly not before your prospect has agreed to give you the job (in writing).
My experience has been that if you have not been able to move your prospect to a sale from your face-to-face meetings, it's highly unlikely that you'll close the sale by then writing a 10 page sales proposal. Sure you'll get some jobs by doing this, but these were probably jobs you would have got simply by asking for the job at the end of the meeting, or just by spending 45 minutes writing an executive summary.
Here's an approach that worked well for us.
First, we create a project scope based on the discussions with prospective client. It includes a preliminary estimate. No charge for this.
Second, if the project scope is acceptable to prospect, we charge them to develop detailed functional specifications, usually 10-20% of the preliminary estimate. Client is under no obligation to hire us, and can take the FS to another development shop or use it to develop the app in-house (they never do!).
This way the risk is low for the client, and they have an option to add/remove features from the final estimate prior to committing to the development in order to control their budget.
Email me directly if you'd like to see our sample Project Scope and Functional Specs documents.
That, in my opinion, is a very good way to handle the whole process. I've always found it best to have them sign a preliminary agreement to cover that initial stage (not obligation to hire me for the main development), and ideally pay for that stage in advance (especially if it's a home based business).Quote:
Originally Posted by Dastar
As you say, no one ever takes the spec elsewhere. This is because during that stage, you had a great opportunity to impress the client and build the foundation of a relationship - plus they've made a decent amount of committment to you already in terms of finances and signing a preliminary agreement.
It's a shame more developers don't take this approach.