You've followed the advice in my sales post, and now a potential customer is interested in you. I'll show you how to write a plan to tackle their problem, shake hands on the deal, then get to work!
As a bonus, I'll give you some tips for improving your writing. This is an invaluable skill; this blog and my website alone have already brought me new customers.
A proposal is a description of the work you will do for a customer. It states what the customer will receive at various stages of the project, and is also a formal agreement to complete the work. Marriage proposals and indecent proposals may be subjects for a future blog post.
Once a customer is really interested in hiring you for a particular job, they will ask for a proposal. Even better, offer to write one before they ask for it, then deliver it within a couple of hours. That will impress them!
First, do some initial research, then quickly send your customer a rough idea of your solution. Get their feedback, and then modify your proposal to narrow down the requirements and budget. Involve the customer in the process of proposal writing from the beginning; it's hard for them to argue against something they wrote themselves!
The customer who sent me a selfie of themselves emerging from a giant vagina would receive a differently-written proposal from the one I would send to a traditional German manufacturing company.
Is the customer at the same technical level, and in the same industry as you? Do they already have a good understanding of what they need? Or do they have no idea what they are buying? Adjust your proposal to your audience.
Your proposal will probably get shared around within the company: the technicians, the marketing people, those controlling the money, and even the CEO. Include a bit of something for everyone. The first time you use acronyms, include their full name in brackets, for example: "the website needs a CMS (Content Management System)".
Keep technical language within the technical section. This part of the proposal will only be read by the technicians within the company, who will be checking that you have the right skills for the job.
Your proposal may also be part of a larger proposal, and your customer may show it to their own customers. Ask how widely it will be shown, and if they need anything additional for their own documentation.
Why couldn't your customer solve their problem internally? Contractors are expensive and risky, and are usually called in as a last resort.
Perhaps you could suggest an existing cheap or free solution, or someone who could do that particular job better or cheaper than you. You might be missing out on this contract, but you will gain the customer's eternal gratitude and trust for saving them time and money.
Visit the customer's office to get to know their industry: what are the real challenges they face every day? Some of my engineering friends became master pizza-makers and delivery-people, just to immerse themselves in the world of a customer.
If you've read this far, you're in the minority. Busy people don't have time to read dense blocks of text, especially if it's technical or boring. Make your proposals as a slide deck (using PowerPoint, Google Docs, or LibreOffice). Use bullet points, not prose, and only have a few sentences per page. Use plenty of pictures and diagrams.
If the customer wants more detail than what I am proposing in this blog: you are not dealing with a real person, you are dealing with a process. Either ask them to handle their own busywork, collaborate with someone who knows the grant-writing process, or move on.
Start by leaving the proposal rough and general; perhaps you are completely wrong about what they want. Send your first revision to the customer immediately, making it clear that it is a rough draft. Add questions and notes in any areas you are unsure about.
Involve them in the planning process from the very start. A customer can't refuse a proposal they wrote themselves!
Language is the magic fuel which powers ideas and creativity, so keep it rich and potent. Don't regurgitate stale buzzwords like "state of the art", "best of breed", "actionable", and "deep dive".
Stick to George Orwell's advice on plain English: replace technical or complex phrases with simpler ones whenever possible.
Try to work out your own original "catchphrases" that encapsulate your key ideas. For example:
Unique jargon and in-jokes are the verbal badges of team membership. By seeding the beginnings of a shared language with your customer, you accelerate the formation of close working bonds, right from the start.
If you notice your customer using phrases from your proposal in their everyday conversations, then you have done your job very well.
Some sections to consider including in your proposals:
What you are going to do, as a bullet point list. These are contractually binding: you must complete all these items, unless the customer explicitly wants to trade them for some other solutions partway through the project.
What you aren't going to do is often more important than what you will do.
List any risks that might endanger the project, and anything the customer might expect but you are not going to do.
This section defines your working relationship with the customer. Here is mine. Note the section about reference rights - you want to be able to tell the world about all the great things you are doing!
I propose an "agile" way of working: requirements can be changed by the customer mid-development if it means a better result. Basically, just doing whatever it takes so that all involved are happy with the finished product, with a minimum of fuss and paperwork, within the budget and time scale.
The product will always be of a "nearly releasable" quality level, so it can be shipped at any stage within short notice, if the business needs change.
The project will be split into phases or milestones. When a phase is in progress, major changes cannot be made until the next phase. At the end of each phase, features and budget usage may be re-prioritised and modified for the next phase. QA will be conducted throughout.
The work will be conducted both on the customer's premises and off-site. James will be available exclusively for the project at least 2 days a week for the duration of the contract, unless otherwise agreed by the customer.
Reference rights: James can mention publically that he worked on the product, customer can mention publically that James worked on it.
This section is for any technical experts reviewing the proposal. Show that you have planned the project properly at a high level. Include any acronyms and industry-standard tools or techniques you will use. A block diagram is useful here (your presentation software is an excellent tool for this).
How will you track the progress of the project, and allow the customer to submit any problem reports? Who is in charge of the final "OK"?
Is the customer in a hurry? Do they have deadlines? Will you work faster than they can evaluate your work, or will you be waiting on them to provide resources? Give yourself plenty of leeway to complete the project ahead of time.
Try to set a roughly part-time schedule, since unforeseen problems often come up, and humans are at their most effective when working 4-5 hours per day.
Your proposal should have a cost breakdown, showing how much each part costs separately, and the final price. Don't forget to include VAT if needed.
If you don't know the customer's budget, propose their dream product, then narrow it down from there.
It should go without saying - don't try to rip off your customers. Businesspeople know right away if you're trying to cheat them, since they have con-men trying to rip them off every day.
Always be honest, even if you think it makes you look bad. Whenever you make a mistake, apologise, and don't try to make excuses or pass on the blame.
Refuse to talk about hourly rates initially, even if the customer asks.
Hourly rates should be a minor accounting detail, and a rough guide for you to work out the cost of the project. If the customer is especially hung up on hourly rates from the beginning, it means they are either inexperienced, or have propensity for penny-pinching. Just let them go, and they will come back in 6 months, asking you to fix the disaster made by the contractor who quoted half the hourly rate, then took four times longer to partially complete the job.
Ask their budget, and then tell them what they can get for that. To help the customer to narrow down the scope, you can use "hours" to estimate the cost of each part.
I often take the worst of both worlds: I make fixed budget proposals but still keep a timesheet and share it with the customer. If I finish ahead of schedule, I'll use the rest of the "hours" I have budgeted to do extra "wishlist" items for my customer. If I go over budget, I lose out. It costs me money, but I enjoy the projects and I like to see my customers get excited when they get more than they were expecting.
There are a few reasons why you wouldn't want fixed pricing:
How you get paid should be convenient and comfortable for both you and the customer. It's better to do a small contract first to test the working relationship. Break one big proposal into separate smaller ones if possible.
Put a maximum payment period in the proposal: mine is 30 days. Some businesses charge interest if a payment is overdue, but I rarely have to do more than send a single friendly reminder, so this seems a bit punitive.
Here are some different invoicing options:
If it's a new customer, suggest writing the first invoice after a few days, once it's obvious you can do the project, then they can pay the rest on completion. It covers you against being ripped off if the customer changes their mind.
If you have a big contract without a tight deadline, you can bill by the hour, then send a bill every month until the budget is spent or the customer ends the project. If the project requires little or no work over the month, you bill less that month.
This is a good model if there are definite deadlines. You can bill as parts of the project are completed at obvious and easily definable milestones, such as: "prototype usable", "first performance completed", "first five levels of game are playable", or "product in the store".
This is good for maintenance or poorly-defined requirements. Just run a tab, and invoice the customer whenever the number starts getting too big.
If you have a really good working relationship with the customer and they have an excellent idea, you can talk about sharing profits and intellectual property. You become collaborators. This is ideally where you want to head - as far from services, and the pay-by-the-hour model, as possible.
Ah, too bad! A few things could have gone wrong:
I am definitely not a lawyer or offering legal advice. Check your contracts and proposals with a lawyer first.
My approach has served me well for over 12 years, and it comes from my Australian upbringing: if you trip over in the street, screw up, or get ripped off in Australia, it's your own dumb fault.
This is the only "contract" I hang on the end of my proposals: "I promise to do the work and the customer promises to pay me".
If you don't trust each other, why are you even working together? Your word and reputation, and that of your customer, should be the only "contract" you need. If you find yourself relying on the wording of a contract to protect you, the project and your business are already in big trouble. Arguing over a contract should be a last resort.
If your customer brings additional contracts to the table, no problem. Note that people will often throw nonsense into the contract just to give them something to take out during negotiations, or a standard contract won't be completely relevant to your situation. If you don't agree with anything, get them to change it or take it out.
Legal action happens as a last resort, when communication has broken down and both parties hate each other. Everyone loses except the lawyers. Don't hate people.
Your proposal is your chance to promote yourself, your plan, and your promise. Make it simple, make it concise, and make it for an audience.
James Hudson
Please write to me! Or at least "like" or "share" this post so your friends can be inspired to start their own businesses.
Needless to say, this blog isn't financial or legal advice, an excuse for getting fired, or promising that any of these ideas will work for you. The companies or people I mention may not agree with my opinions here. Don't do anything reckless, damaging or hurtful to anyone! In the future you might need your bridges unburnt.