If you’re new to web design and development, starting your own agency or are just getting to grips with freelancing – here are some handy tips to avoid mistakes on quoting for projects.
There may even be some tips in here that the seasoned professional could use for their next project.
Firstly, some caveats
I know there are different pricing structures out there, agile, fixed, hourly rates, value based.
This post is on the more traditional process of an up-front project quotation, aimed at a fixed cost but with room for scope creep and change requests.
As a designer and front-end developer, the information below is tailored to my experience – a lot of the advice is transferrable to other industries though.
The below advice is based on my experience of projects that I work on which range from a few thousand pounds to tens of thousands of pounds.
Questions, questions, questions… questions
It is likely that you will have received an overview on the project from your client, perhaps even a brief.
99% of the time though, this does not answer every single question on every single aspect of a project.
Before you start thinking about numbers and budgets you’re going to need to get all of the information you can out of your new prospective client. This means talking to them at length about what they want to achieve from this project. I like to do this initially via a phone call, face to face meeting or Skype call.
You ideally want to get a strong feel for the type of company this client works for, how good a fit they’ll be with your company and whether you are the right person/company to do their project.
Once I’ve got a solid idea of the project (including the budget, if it felt right to do so) and it is something that I want to take on, I need to delve a little deeper.
Rather than take up more time on the initial call, I send out a Google doc for the client to fill out at their leisure.
This is a great way of getting some more basic information and keeping the communication channels open. I normally fix a date with the client for when I’d like this filled out by.
Typically, there are a lot of discussions around this document, you’ll find questions spark more questions or bring functionality out of the woodwork that the client hasn’t thought of. It is very important at this stage to keep talking to the client and commenting on the Google doc to get every conceivable question answered.
Once you have everything you need, it is time to provide an estimate for the project cost. Notice at this stage I’m calling it an estimate and not a quote. I like to make the distinction to the client at this point that I’ll provide an estimate first via email and if they are happy with the breakdown I will create a formal proposal including contract.
Estimating the project cost
This is where a lot of people slip up. They’ll just plain and simple make it up. Out of thin air based on a rough idea of what they think a project like this should cost based on no serious thought and sometimes no experience.
They will think about best case scenarios, with no time needed for up-skilling, reading brand notes, API integration, project setup or project management.
When I first started quoting for projects I went through an entire project in my head and wrote down every single element. These days I can do this process without the writing down.
Taking the example of a web design and build project; I’d break the design down into “templates” – distinctly different designs across the website. I would jot down, in my notepad, estimates for designing every single template. I would include 2 iterations to these designs. I would break down the build into global markup and styles, including the functionality and layout on a template by template basis.
By the end of this process I’d have 3 or 4 pages of scribbles “0.25 day”, “1 day”, “0.5 day”, “1 hour”, “2 days” against rough notes, wireframes and workings out. I would add all of those up. I’d add them up 3 times to make sure I had not missed anything.
This is now my base cost for doing the project, with best case scenarios assuming I can do it all without having to up-skill, read any third party documentation or liaise with the client. Depending on the project cost at this point, I add on at least 1 day of project management time to cover a basic level of client interaction and up-skilling/documentation. The larger the project is, the more this project management cost should increase.
I like to be honest with my clients and this stands as a line item in my formal proposal, but you may want to build this into your costs another way. It’s up to you!
Should you ask for a budget before you provide an estimate?
You may find it is handy to mention a range cost during the “questions…” part of the process to see if it is agreeable with your client’s budget. I know a lot of people say don’t mention costs on the first contact with the client and you should never ask a budget. But let’s face it a lot of clients do in reality have a budget ceiling so it can be good to have an idea of it at this stage.
Providing a rough project range cost is not something I would advise for someone just starting out though. Once you have a few years of projects under your belt you’ll have a range of experience to call upon, which will give you a firmer idea of where to price any given project.
By no means should a client’s budget dictate the project value you quote on. If you think the costs tally higher, that’s fine – the client will hopefully trust you and may have some more money to assign to the project. If the costs come in lower than their budget, that is also fine – providing you have asked all the questions.
Time estimated is not equal to time being spent
This is important. If you are estimating a project at 10 days – that does not mean it will be finished in 10 days time. No. Please don’t do this!
I usually double the project lifecycle for a small project and triple it for a larger project as a starter. If the project is particularly detailed I’ll put together a basic private calendar allowing for feedback loops, iterations and at least 2 contingency days on a larger project for illness or unavailability on both sides.
Contacting the client with your estimate
Before I commit to a final proposal with attached contract, I’ll pen a simple email with a semi-detailed breakdown of costs.
Testing and deployment
I make it clear the cost is an estimate and that if the project requirements change then there may be additional cost or in fact as I have done in the past, reduce cost if the complexity of the project reduces.
I’ll also provide a rough start date and end date for the project, explaining iteration and feedback loops and that it could go faster or slower depending on these.
I ask that if the cost sounds reasonable, to let me know and I will formalise the proposal and send it over.
Finally I’ll mention my payment terms.
Writing the formal proposal
Not every project will need a formal proposal, some can stop at the email stage – particularly when dealing with a recurring client.
For a new client I always like to get a signed contract on a new project based on a formal proposal.
I won’t go into the details of writing a formal proposal on this post, but if you think it would be useful for another post please let me know.
- Don’t rush out a project cost
- Ask a boat load of questions
- Keep communication channels open with the client
- Work out a cost down to the finest detail you can
- Make sure you include time for project management
- Include a rough schedule