Managing Web Projects #5 – The Contract

Managing Web Projects #5 – The Contract

Before I start this entry I’d just like to stick in the following disclaimer:

I am not a lawyer, anything you read here is general advice only and I’d strongly recommend getting a good contract lawyer to draw up your contract(s) for you.

Right, now that’s the legal bit out of the way we’ll get on to the … er … legal bit!

Never, ever, ever undertake any project without a written contract that both parties are happy with and have signed. I’ve lost count of he number of times I’ve heard people moan that a client hasn’t paid or changed the scope of the project at the last minute. My response is always “Well that doesn’t matter, your contract must state that that’s a billable charge.” To which they reply “Um…. actually I didn’t bother with a contract!”

Not only does a contract protect the client, it protects you as well. You can clearly state what is expected from both parties – from you, a fully functioning site in x weeks, from the client, content to be delivered by x and any later then the project deadline is moved back x weeks.

There are three ways that contracts are normally assigned:

1) You send out your standard contract agreement for the client

This is okay for small, standard sites where timescales, content etc. are not “mission critical”. The generic format allows you to cover most eventualities and really the only thing that needs to change each time you send it is the client’s name.

2) You send out a bespoke contract agreement

These contracts are specifically tailored to the client. This would be particularly useful if you were, for example, building a complex database driven site and couldn’t progress too far without the database content. You would put definite deliverable dates in the contract to ensure that the client sent the content on time. If these dates aren’t met, you’re obviously going to fall behind in the project so there are penalty clauses in it to move the deadline back.

3) The client sends you a contract

This normally happens when you’re dealing with large firms with their own legal departments. Always look through this type of contract very carefully as there will probably be provisos in there stating they own the code, the webserver, your house and first-born son.

Don’t be afraid to question these contracts or request changes. The worst that could happen is they say “No” and you decide not to do the job.

Contract Style

Some lawyers like to use very obfuscating (cheeky tongue) language in their contracts to cover a multitude of sins so no-one really knows who’s doing what, when and who owns it.

Personally I prefer a very plain and simply worded contract using as little jargon as possible (or at least explaining the terms somewhere). In fact, here in the UK we have the “Plain English Campaign” which strives to force all companies to stop talking twaddle in their literature and just spit it out.

With a plainly written contract, each party can easily see what’s expected, what they have to do and what they’re getting. There was a case, in one of my previous companies, that a client was refusing to pay as they didn’t realise they’d incur penalties for late delivery of essential content. They argued that we were in the wrong as we delivered the website late but it was all in there in the contract if you could understand it!

Contract Content

This is dependant on the type of project; the more complicated the project, the more in-depth the contract has to be. But things to consider are:

  • Names and addresses of all parties involved (including external suppliers).
  • Scope of the project – This will detail the type of website. Functionality, technologies used etc. could be listed here, but for larger sites I prefer this is a functional requirements specification, which is agreed and signed off separately (the contract usually goes to the people who pay the money the FRS goes to the people who’ll understand the technical jargon).
  • Deliverable dates – When is it to be complete by? You could list the stages here as well for completion, testing, and deployment.
  • Content Capture – Here you list who is providing the content, the formats that it will be provided in, who’s doing what with the data (for example, you may outsource a market research company who’ll run the necessary reports and give you the results), and when it’ll be provided.
  • Changes to content – Are changes to the content allowable or are you expecting it to be delivered in its final form. If changes are allowed, what are the costs involved in this (if any).
  • Intellectual property/Copyright – This is probably the most important part. This section lists who owns what. For example if you sign away the rights to the code, you legally can’t re-use portions of it unless you get the client’s permission. You need to be as clear as possible about what can and can’t be done with source code, graphics etc. Usually I retain the intellectual properties rights to all underlying code and the client retains copyright of the design, images and content.
  • Disclaimers – This is useful if you are using a third party for anything. In this section you would state that you are not responsible for the failure of third party x to do y. For example, if you were using a third party host, you would state that you are not responsible for server maintenance, backups or uptime. This section could also be used to state that it is the responsibility of the client to ensure all materials provided by them are allowable (in terms of existing copyright – i.e. they have the owners permission) and any royalties due are their responsibility.
  • Costs Incurred – What the client is liable for in terms of “extra” costs incurred by you. This may include travel expenses, purchase of stock photos etc.
  • Web Hosting – If the client is sourcing their own hosting, state it here plus any access rights you need to upload to their servers (there’s no point building a website if you can’t upload it!). If you are sourcing it for them, name the supplier and contact name/details for the company.
  • Laws affecting electronic commerce – Again, another disclaimer stating that the client is responsible for the payment of any taxes etc. incurred through the use of e-commerce.
  • Data Protection – This section should indemnify you against the loss or misuse of data. For example, if the client asks you to import 10,000 email addresses into their database for a HTML mailshot from their new website, the onus should be on the client to ensure that these email addresses have been collected properly and the recipients have agreed to receiving the email.
  • Maintenance agreement – Are you going to be responsible for maintaining and updating the site? If so, how often, for how much and when will the agreement be reviewed?
  • Payment of fees – This states the terms of payment. For example you may want 20% of the total paid up front with the balance due 30 days after sign-off of the finished site. In this section you’d set out any fees for late payment, such as 5% of the balance for each month payment is delayed.
  • Initial payment and refund policy – Here you would state the total cost of the website, the upfront payment, balance payable and the due dates of these payments. Here you may also state that if the client stops the work and cancels the contract they only have x number of days to do so, and what monies are payable back to the client. Also state what the rate is for work already carried out (usually an hourly rate) and how much of the initial payment they are eligible to receive back
  • Client Sign-off – This is the area where the both you and the client signs and dates the contract, thus making it legally binding (hoorah!).

Getting the contract to the client

If the job is time sensitive, then you can get written permission to start the project via fax or email. Never accept a telephone call as confirmation a project can start; a verbal contract isn’t worth the paper it’s written on!

Email the client a copy of the contract and ask them to fax-back the client sign-off page. The contract should be sent in PDF format to ensure that the client doesn’t change any of the content. Ensure that your signature is embedded in the file.

I’m not sure about other countries, but in the UK, faxes are still technically not held as legally binding documents, so print off the contract and send 2 copies of it to the client via registered post, including a pre-stamped return envelope so they can send a signed copy back and keep one for their records.

Well, that about wraps up the contract. Remember, as mentioned previously, it’s worth paying someone to draw up a contract for you (especially a generic one that you can remove unwanted sections from), so that you know you (and the client) are covered in all eventualities.

So, you’ve received your contract sign-off, which brings us to the next step: The Technical Specification (also know as a Functional Requirements Specification).

Don’t forget to check out the e-book version and download your free sample chapter!

Managing Web Projects

full course
  1. Managing Web Projects #3 – The Pitch
  2. Managing Web Projects #2 – The Workflow
  3. Managing Web Projects #1 – The Brainstorm
  4. Managing Web Projects #5 – The Contract
  5. Managing Web Projects #4 – The Quote
  6. Managing Web Projects #7 – Sourcing the team and Managing the Project
  7. Managing Web Projects #6 – The Technical Requirements Specification
  8. Managing Web Projects #8 – The Design Process
  9. Managing Web Projects #9 – The Development Process
  10. Managing Web Projects #10 – Testing the Product
  11. Managing Web Projects #11 – The Change Request Form
  12. Managing Web Projects #12 – Sign-off and “Delivery”
  13. Managing Web Projects #13 – Invoicing the client
  14. Managing Web Projects #14 – Maintenance Contracts
  15. Managing Web Projects – The Whole Shebang

Subscribe to our mailing list

Join Hundreds of readers who have access to exclusive downloads and content

Leave a Reply

Your email address will not be published. Required fields are marked *