Previous of this article series showed you how to write and how not to write proposals on freelance platforms and websites. Usually, for small projects, all you need is an eye-catching proposal that leads to further discussion with the client.
This part focuses on how to write a winning Upwork proposal that targets your dream clients and brings you real freelance work.
Sometimes, however, you need a little bit of formalism. That’s what we call a ‘quotation.’ Others call it ‘proposal,’ but it is essentially the same thing. I favor ‘quotation’ as it relates more to the business deal that aims to lead to an agreement between you and your client. You will deliver X, the client will pay Y. So here, we go with the term ‘quotation.’
The quotation is a document that explains what you are going to deliver for what price, and what terms apply in the business deal. The need for a formal quotation document may happen for two reasons:
- Your client is asking “can you send me your quotation” which will cause you to react.
- You realize you would need to warrant the scope of work in detail to avoid over-promising your client any work items that you are uncertain of. Often, this can relate to complex technical bits of projects that have not been done before by anyone (which is my typical case).
A good proposal acts as your life insurance.
In any case, a quotation document is something that would look excessive if sent for every little job. When you need to have one, it is usually for a project on the scale of several thousand dollars at least. Usually $10K and above.
If sent through freelance platforms, some of the parts that could be included in your document are already covered by the system, in which case you should not include duplicate or conflicting terms. Unfortunately, I’ve seen this happen many times when being a client.
In this article, I show a good approach for writing your quotation document in a way that addresses the client’s needs completely and protects your freelance business at the same time. Please note here that my examples usually involve CTO-level services that I sell, so some parts may be excessive to your purpose. (In case you are wondering which parts to include in your typical proposals, feel free to drop me a message.)
What is a quotation document, exactly?
As you may guess, there is, of course, a meta-structure, a formula that we can apply. We just need to apply it intelligently, not blindly.
In simple terms, what your quotation needs to communicate to your client:
- What will you produce?
- When will you deliver?
- What will it cost?
- What uncertainties and risks are present? What is the impact of each of them?
- How do you report progress?
- What counts as the final result (i.e. something that ends the project)?
- How and when does the client pay you?
- What support do you offer after the final payment?
Nothing more, nothing less. Now, how do we express all of the above in a concise format so that the client can get the impression that you are the pro who should be hired? Let’s start with the structure.
You can find a lot of templates for project proposals, generic ones, industry-specific ones, and those designed for freelancers. What I have here, is specific to freelance software developers, as I am one myself.
Structure
My outline has quite a few sections. These are section headers of all the proposals I have sent so far:
- Scope of work
- Technical assumptions and limitations
- Development process and collaboration mode
- Milestones
- Budget and payment schedule
- Payment method
- Schedule
- Limitations
- Support
- Intellectual property
- Documentation
- Appendices
What stands out? If you look at any generic project proposal templates, they usually do not highlight the technical assumptions and limitations as heavily as my projects do. I often deliver systems for non-technical clients who do not know much about the limitations and assume certain things that are not realistic. Therefore, technical assumptions and limitations appear as the second section in my quotation document.
If you are not developing systems any more complex than smartphone apps or websites, Section 2 might be strange for the client to be shown early on. Perhaps it would be enough to have Section 2 appear after Section 9: Intellectual property.
At this point, I’d suggest you download the example document, open it, and go through the sections side by side with this article. Let’s go through each section so that the meaning of each section gets clear.
Example project
Because of confidentiality that I guarantee for each client or even a mere prospect, I have removed some specifics and all identifiable information. I have also changed the topic slightly from the original real-world case I had. The example here, therefore, focuses on making a 3D sensor-based AR game for Clive Cliant of a company called Kiddi Fun LLP, a non-profit organization.
Clive wants a game that is targeted to help autistic children to move and practice gross motor skills in a fun way. His project is done in collaboration with researchers and has the aim of building a social enterprise to make a real-world impact. He aims to get partial funding from the public sector in the form of research grants and social support schemes.
In this example, there has been some discussion earlier on, which has to be taken into account in the quotation document. In this case, let’s assume that the discussion covered:
- Which movements could be included in the game in a cost-efficient way.
- Which hardware can be used and if there are any choices to be made.
- How different hardware could work together.
- Rough order of magnitude estimate of the budget, here, roughly US$10-20K.
Given the prior discussion, the technical assumptions and limitations need to be listed upfront to confirm what was discussed and what the conclusion was. It is part of the background story of the project. Please note, that if you work with technology that most people can understand, these limitations might be minimal or even non-existing. So, think for yourself and decide if your client understands what you are going to deliver and what you are not going to deliver.
Now, let’s go through every section. Keep the example quotation document open and compare the content in the document to my explanation of each section here below.
Section 1. Scope of work
First of all, let’s not forget to double-check how the client’s name is spelled to avoid embarrassing comments straight on page 1!
Some would call this the background and objectives of the project. A simple paragraph describing what the project is about is sufficient. Basically, this part is where you define the problem to be solved. The rest of the sections describe all aspects of the solution and the process for delivering it.
Section 2. Technical assumptions and limitations
In most proposals, you would not have this section coming second. My proposals, however, focus on technology that is usually misunderstood. For instance, people think the 3D sensors such as Kinect, Orbbec, Realsense track human movement perfectly like motion trackers. That not being entirely true, I write a section that shoots down the false expectations of the reader, the client, usually in my case a non-techie. In other words, my life jacket comes in the second section. 😉
Therefore, I found it very useful to have a full page dedicated to explaining to my client what the technological basis is before my development work so that there is no mistake on what the project is all about and why it is worth the money the client is paying me.
In chronological order, this section is an important part of the background of the project, i.e. describing the basics of the technology to be used for those parts that are relevant to the client.
Section 3. Development process and collaboration mode
The example project requires testing with autistic children to who I don’t have direct access. Therefore, it is essential to define the responsibilities of each party. Without this, the client would assume my side would be able to do all the testing and most importantly within the cost of the project!
The other practical side of this section is to create a common understanding of the dependencies. This helps you! In case the client cannot deliver their part of the work, any delay cannot be blamed on you! 😉 Some tasks could be run in parallel, some depend on previous ones. It is good practice to list all the dependencies.
In many cases, this section can be minimal (2-3 lines or so) or even left out completely if, for instance, you develop an entire mobile app from scratch yourself and simply hand over the results to the client.
In another case, let’s say the client wants a website and assumes you will develop it, but the client would handle the website administration himself. This would be something to be mentioned in this section, so that you both can agree on who is supposed to do what in which phase of the project.
One obvious part of the process description is defining the velocity, which sets the expectation of the delivery schedule nicely upfront. Are you doing your part of the work in full-time mode or a certain limited number of hours per day or week? Create the expectation right to avoid missing any deadlines.
Section 4. Milestones
This is my favorite part! I love to plan projects and split them into meaningful parts that I am sure the client will like and benefit from. Oftentimes I have an initial version with the core functionality ready in a week or two so that the core parts can be tested by the client as early as possible. It does not matter what those “core” parts are, really. It is better to maximize the initial testing that the client can do compared to pushing complex things at the client’s face only at the end of the project.
Milestones could reflect the number of software releases. These need to be designed from the client’s perspective with consideration of what is possible and realistic from your own side.
Please note that sometimes, when there are unspecified tasks and uncertainties, I divide my quotation into a couple of packages. For instance, I might divide it by functionality and scope in case the client is unsure about what the best way is. An example could be something like this in a typical VR game installation:
- Option A) VR game with a single-player version
- Works offline
- No multi-player testing work during the development
- Option B) VR game with a multi-player version
- Requires networking components
- Requires multi-player testing work during the development
Then, the budget section would explain the total price for each option. That would make sense for a client who does not yet understand the cost levels and what is required for the client’s own business to succeed. To help in this discussion, such an option-based packaging of the quotation is an efficient way to move forward.
Section 5. Budget and payment schedule
Why do I present the milestones from the price separately? In a decent-size project, I wish to focus on what needs to be done, then put a price tag on it.
Based on experience from many previous projects and jobs prior to my freelancing times, I noticed that if the milestones and payments are put together side by side in a table without explanation of what each milestone is about, there is a big danger in getting mixed up with specific expressions, terms, vocabulary, and so on. Then, the client would start questioning why some milestone looks too expensive or what work another milestone requires in the first place. Therefore, my approach is simple:
- First, list what needs to be done in enough detail, use descriptive names for each milestone
- Then, make a table for the payment schedule with milestone names and corresponding price tags
- Sum up the total price (with all side costs included, if any, e.g. fees of your freelance platform)
This avoids much of the confusion with the client.
Typically, milestones correspond to software releases and payments. However, in small projects I may charge 50% advance, have multiple releases that the client will receive, test, and give feedback on, and get paid for the remaining 50% only when the job is completed and the project closed. That’s fine also for small-scale projects. You would not want to burden your client to make ten small payments of $300 to cover a little $3K project. That would be strange and make the client lose time.
For bigger projects, it is better to have milestones matching with deliverables to the client and payments so that all of them go hand-in-hand all the way from the start to the end. However, if there is much collaborative work to be done together with the client, it may be better to set the payment schedule to follow their involvement in the project, which could be testing sessions such as in my example project.
Something that might be not always obvious is that you might need two versions of the budget: internal and external. The internal one is your own calculation for defining mainly how much time you will spend to ensure you land at making enough money for yourself. Also, if you need others, you need to have at least estimates if not formal quotes from your collaborators.
Normally, if I’ve worked with e.g. graphic artists before and have inquired about possible availability, I can go with my own estimate for the graphic design budget. With new collaborators, it is better to ask for quotations that require more work done upfront to design and specify detailed work items for them, maybe.
What you need to put in the quotation document for the budget is the external version, i.e. what does the client get for what amount of money. This does not need to have all the same details as your internal budget, and definitely should not have all hourly rate calculations presented to the client. Instead, just present what the deliverable contains and what it costs. That is easier for the client to understand and to maintain focus on the high-level business deal that you are proposing, instead of going into the details.
You can avoid “why does the graphic design take fifteen hours, I think it is just a day’s work” kind of questions. Don’t present the details!
One important thing about budgets is currency. Always remember to mention the currency that you quote in! It would be embarrassing if you would accidentally copy-paste the template used for your local projects with local currency and use the same local currency in your global projects. That would look highly unprofessional. 🙂 Even if you do your internal budget in a local currency, convert it and round it nicely for the client. For instance, if your final cost is 30,528 Malaysian Ringgit, you’d put it as 7,500 USD for the client. Just make sure the number will look reasonable to the client.
Perhaps the last thing to mention here is that I, in general, make the client commit to the project with an advance fee (25-50%), put small milestone payments in the middle to the project, and let the last milestone after the final acceptance be the biggest milestone payment. This is simply to ensure my plan looks fully committed too. I take no money before producing the honey. 🙂 All I need to do is make sure I have got the cash from my client before I have to pay my collaborators.
All deals need to be in sync. Unfortunately, I have witnessed others failing in keeping the balance with the cash-in and the cash-out.
Section 6. Payment method
This part is probably the simplest one. All you need to define is how the payment should be sent to you. In case your project runs through a freelance platform, you don’t need to think twice: everything must go through that platform to avoid violations of the user agreement.
Although this section is trivial, it is necessary. It gets a bit strange if, for instance, your client assumed he can pay by credit card but you only accept direct bank transfers. Don’t forget to define the payment method. Also, you can mention the impact of missing payments, but this is usually obvious to everyone.
Section 7. Schedule
Although the milestones above would indicate the end date of the project, I find it good to add a short section specifically about the schedule. Typically I calculate the end date for the project with notes on factors on the client’s side that might cause delays.
One good thing to note is your own availability. In case you have a holiday planned or intensive work on something else than the project you are quoting, it is good to list those days or weeks in advance so that the client is aware of it. The people on the client’s side will need to manage their own schedules too. List it here so that everybody is on board and knows the overall schedule.
Section 8. Support
Support is something that you should not need to offer specifically in any other part of the discussion with your client. In the quotation document, however, it is good to mention in order to avoid issues with the client later.
I do not recommend using “lifetime support,” unless it is required by your specific business model. The reason is simple: don’t give away your own time for free. No more than 1 year of warranty in any case. Often 6 months of free support is more than enough.
The most important part here is to list the tasks that are part of the support and exclude those that are not. So, the main point of this section is to get yourself covered against unforeseen issues with any aspect of the project after it has been paid in full.
Section 9. Intellectual property
If the quotation goes through any of the freelance platforms, this part is pretty much covered by the user agreement of the platform. Normally, all work done, all ideas generated, all code copyrighted, and so on belong to the customer. In practice, this means you must not copy-paste stuff between client projects! A good way to avoid this is, of course, making your own utility libraries public. For instance, publish your code as an open-source project on GitHub with free-to-use license terms.
Section 10. Documentation
This may sound a bit redundant, but it is actually very essential to mention the deliverables for documentation. In my case, there is always a short document for installation and setup (usually just links to the official guidelines of hardware providers e.g. HTC and Microsoft, nothing much more). This section does not need to be much, basically, just the names of the document that you will provide.
Section 11. Appendices
Sometimes, appendices come in handy. Depending on the stage of discussion with the client before writing the quotation, I may attach selected pages of my portfolio PDF. I want to give them more information about my background which is a very useful thing to do when there is an expectation of working more together later, e.g. if there is a demo version of a new product with hopes of delivering the full product later.
Sometimes, I attach Dropbox links to videos demonstrating preliminary tests on hardware limits that I have done, or tests already done by others that are available on YouTube as in the example project. This is good for the client to understand especially when dealing with complicated systems, e.g. Kinect and Orbbec 3D sensors, HTC Vive VR systems, HoloLens, etc.
Such material is good to appear in the appendices so that the client is perfectly aware of all technical limitations and understands the scope of development which justifies your price. Then, the client won’t accuse you of delivering something coming out of the box without developing anything in reality, for instance.
The missing parts
As you may guess, the example I gave here is not complete. There are a couple of things to do before sending the quotation away.
You might wonder where the risks are mentioned. Well, it is always a good idea to think about what could go wrong and double-check that you have a plan for it. That’s what project planning is mostly about. Now, in an in-house project plan in a company, you would have lots of risks listed such as key people getting sick, only a partial understanding of the client’s needs is reached, new requirements would appear late in the project, and so on. There can be a hundred things that could go wrong even in a small project (as we software guys know very well, heheh).
In the case of a freelancer, however, listing all possible risks produces a risk on its own. In fact, it would make your quotation look like a risky business for the client to engage in. This is the part where being fully transparent would make you look a bit strange. So, my approach is to embed the technical risks and uncertainties in Section 2: Technical assumptions and limitations. Many times, especially in remote projects, it is the communication and understanding between you and your client that might turn out to be the biggest challenge.
So basically, that’s what this whole document is about, creating the understanding! Also, listing the limitations to the scope of work act as my guarantee that gives me a strong well-justified argument for saying “I never promised that for this price.”
The point is, that my quotation must look like a safe choice to the client. All my tricks are like a camouflage technique, sort of! As you may realize at this point, much of my quotation document is actually a written description of a good and subtle risk mitigation strategy. It covers communication and collaboration aspects with the client, technical parts, and business risks too, sometimes.
In a typical project that I do, I’m often asked to define the minimum (read: cheapest) hardware for a complex AR installation, which I might not know precisely before experimentation since I might need to optimize certain parts of the software to make the overall combination of the hardware and the software work.
In this case, I would write my Section 2 in a way that it contains a list of possible options and combinations with prices listed so that the client would see and estimate the final cost of the hardware needed, the best case, and the worst case. Perhaps the first milestone would be then about defining the hardware. Thus, the business risk to the client would be mitigated. A bit sneaky approach, would you agree? 😉
After getting the risks sorted out, finally, you would need to make the document look like it is yours. This can be done by adding:
- Formal business name, registry number, and physical address
- Letterhead to the document template, e.g. your logo
- Your favorite color scheme, font, etc. for a nice and decent outlook 🙂 (A carefully chosen MS Word document template will do most of the work, actually.)
Do those and your proposal will look as formal as possible.
Variations
I don’t use the exact same format for all quotations. It depends on what the client is expecting. The above example typically takes about 7-10 pages which makes it too heavy for short projects. Sometimes I simplify everything to fit about 2-3 pages. Then, the following structure is sufficient:
- Purpose (or simply Scope of Work as earlier)
- Features and costs
- Milestone #1
- Feature list
- Price
- Milestone #2
- Feature list
- Price
- …
- Total cost and payment method
- Milestone #1
- Limitations
The benefit of simplifying this is obvious. If you have already had a lot of discussion about the project with the client, this short format acts as a mere formality, actually. For each part of the project that you will deliver and expect to be paid for, a simple bullet list is perfect enough to convey the messages. Here, I even rename the second section header as “features” to put a clear focus on what software will be delivered for what price.
The short format saves time for both you and the client when things have already been discussed to a great extent.
Conclusion on how to write a winning Upwork proposal
That’s it! Now, if you read and fully understood all the parts of this article series, you’re ready to propose right! The previous parts showed you how to attract clients and go through all the steps in the process in the right way. This part taught you everything you will ever need for writing a formal quotation document.
Now, go and propose in style! 🙂
