Contracts & Agreements

The very first step in any project is setting down in writing exactly what your scope of work is and what are the roles and responsibilities of each party. Without a detailed agreement, you have nothing to fall back on if something goes wrong. It holds you, your team, and the project owner all accountable for the project deliverables. It also goes back to building project owner confidence in you and your team. Not only does it look professional, but you drawing up a detailed formal agreement lets them know that you have fully understood their requirements and care enough about their project to put the time into it.

While this agreement should be as explicit as required to convey the exact requirements and production plan, it should not be so rigid as to restrict the production team’s flexibility to adjust feature prioritisation as the project evolves. Ensure that it is formally approved by the project owner before starting work. Below is a template for what such an agreement should cover — you may find alternative templates elsewhere, or already have your own, but the important thing is that it covers the same basic details. I’ll go into more detail about each section in future posts.


Scope of Work: [Project Name]

Date: [Date] Author: [Author] Version: [Version]

Project Goals

A brief project overview — your understanding of precisely what it should entail, e.g. A website for the purpose of XXX, A mobile app representing XXX brand’s XXX division. Give as little and as much detail as required.

  • Explicit business goals, e.g. Acquire XXX new sign ups
  • Explicit user goals, e.g. Allow users to sign up within X seconds

Feature Requirements

List explicitly discussed major/high-level features (a more detailed feature breakdown, for assigning work to the production team can be sketched out later — the project owner doesn’t need to know exactly what each button is going to do). e.g.

  • A sign up form containing fields…
  • Customer acquisition emails that provide links to…
  • etc.

Deliverables

List exactly what your team will deliver: code? images? wireframes? a style guide? a compiled app? documentation? test cases? a database?

Roles & Responsibilities

Describe who is responsible for what. The purpose of this is to hold people accountable and remind them of what is required of them in order for the project to be successfully completed. Be explicit and list the names of the project stakeholders, as well as any time-dependent responsibilities. e.g.

  • [Project owner’s name]: provide timely and accurate feedback when required, provide business background information on demand, provide brand materials before production begins, arrange for business stakeholders to be available to provide requirements and feedback
  • [Production team leader’s name]: make technology decisions, provide accurate cost estimates before production begins, immediately assign a team to handle production, ensure smooth delivery
  • [Client/Account manager’s name]: handle accurate requirements gathering, handle all contracts and agreements, issue invoices, accurately communicate requirements and feedback to the production team, provide daily status reports to all project stakeholders, handle weekly reviews with all project stakeholders
  • [Project manager’s name]: devise accurate functional requirements, devise and deliver a performance budget, breakdown requirements into work assignments and assign work to production team members, devise timelines, provide necessary workflow tools to the production team, establish workflow processes, accurately report progress on demand, identify and report risk factors, ensure analytics recording is implemented for measuring success criteria, ensure requirements are being met, take part in daily stand-ups
  • [Content production manager’s name]: accurately gather and communicate content requirements, devise content strategy, provide a content style guide, advise on content management system, produce content as required, take part in daily stand-ups
  • [Lead developer’s name]: produce features as required, produce features according to the functional specifications and timeline, ensure accurate and detailed code documentation, work with lead designer to handle feature iterations, take part in daily stand-ups
  • [Lead designer’s name]: devise a scalable and modular design pattern, provide a design style guide, analyse analytics and make adjustments to the design system, ensure design requirements are met, ensure all features are tested for usability and accessibility, work with lead developer to handle feature iterations, take part in daily stand-ups
  • [Lead tester’s name]: ensure all features are tested for compatibility, usability, performance, accessibility, and machine-readability, work with designers and developers to ensure feature iterations are being tested, provide accurate test case reports, provide helpful feedback to designers and developers, ensure project requirements are being met, take part in daily stand-ups
  • etc.

Milestones, Deadlines & Timelines

All stakeholders should be made aware of when stuff should be completed by. This is dependent on what features your team thinks they can produce within what timeframe. e.g.

  • Describe the time required for requirements gathering, business case analysis, stakeholder interviews, planning etc. (timelines)
  • List features XXX to be ready for review by dates XXX (milestones)
  • Project deployment estimated around date XXX (deadlines)

Change Request Policy

What happens if the project requirements change after production has started? Should the project owner pay more? Should change requests be deferred until after the next milestone? Should the deadline be extended? What about if it’s the production team’s fault? Someone leaves the team or you realise that feature X can’t be completed? There’s a very good chance that at least one of these is going to happen.

Describe here as accurately as possible what should happen in such scenarios — every team will handle it differently. Try to imagine and prepare for every possible scenario and describe your contingency plans here so that everyone is prepared from the outset.

Warranty & Legal Issues

Who will own what after the project is completed? Again, be explicit. Who is liable if any part of the project is found to be plagiarised or broken or causes the project owner’s business to suffer loss? For how long after delivery is your team prepared to make changes and fixes, and at what cost to the project owner? Depending on your organisation, the project owner’s organisation, and the type and scope of the project, you may want to consult an intellectual property lawyer for this section. The good news is that you can probably re-use it in SOW documents for other projects.

Budgets & Cost

Outlay your team’s rates and possibly an overall estimated cost for the project. Obviously, how your team handles costs might be different — maybe you practice value-based pricing rather than timely rates. Costs should be based on how many people will be working for what about of time, which is in turn dependent on the feature requirements, or otherwise based on the value of your team’s work to the project owner’s organisation. If the project owner can provide a maximum budget then list it here — it highlights to your team how much money, and therefore time, they have to work with to produce the required features. Cost estimation is extremely difficult but it’s important that you set expectations for all project stakeholders. e.g.

Project budget: [US$XXXXX]

Production team weekly rate: [US$XXXX]

Estimated total cost: [US$XXXXX]

You may also want to outline warranty period and ongoing maintenance costs, if required.

Success Measures & Performance Metrics

Describe here exactly what data you will gather in order to measure the performance of the resulting web project against the originally stated business and user requirements. Also describe how that data will be gathered and accessed, by who, and who will be responsible for analysing that data. e.g.

  • Time to render: the average time, in seconds, that it takes for each page of the website to fully render to the user. This will be recorded using a variety of online tools and browser development tools. The data will be gathered, analysed, and reported by the production team on a weekly basis. The data will be reported separately for global users on mobile and desktop devices and compared against the original performance budget.
  • XXX new customer acquisitions every month: this will be available via a custom Google Analytics report, based on data automatically collected from the web app. The Google Analytics account will be made available to the project owner by the production team and the project owner will be responsible for monitoring metrics.
  • etc.