Someone recently asked what does it take to write a good website proposal? They didn't tell what the site was, what it would do, if it already existed, ... all they had was a maximum budget.
Here was my answer:
The construction cost of a website is based on what it does and how much function/content is required to achieve that end. So to state a maximum budget without knowing what you're building is like saying you will not pay more than x for painting an unknown house.
A good proposal accurately represents end user expectations and unless the development is simple, the statement of work must include the customer as one of the active members of the development team.
Most poorly implemented websites result from designers not know how and/or customers not knowing what.
Customers are usually not so good at explaining their vision, often because they don't have one, and technical people sometimes are too eager based on what they think will suffice, or worse, what they did last time.
A good proposal includes:
- an explanation of the process that will be used (see design process below)
- at least one customer stakeholder being part of the group
- a list of tangible deliverables (what does the customer get?)
- a delivery timeline that ties to a payment schedule
- the conditions (e.g., same stakeholder must remain in the project for the duration)
- the exclusions (e.g., the price does not include lunch or beer)
Here's an example of a design process that we have used in the past to help educate clients. And here's another doc that has been useful when customers want a proposal when no blueprint exists.
In the end, a good proposal contains only enough information so to produce a win-win result and for that, there is no boilerplate.
One size does not fit all.
Comments(0)