Writing your tender

Skip the page content navigation if you do not require links to content sections within this page.

Page Content Navigation

Skip the primary navigation if you do not want to read it as the next section.


Primary navigation

Home Clients Non profits Webfactory Support About us Services

Skip the main content if you do not want to read it as the next section.


Writing a tender for a charity website

Writing a good tender is one of the most important points of the entire project lifecycle.  If you get it right, you increase your chances of finding the right supplier for you.  This document suggests some tips to consider when writing a brief.

A good tender should be as clear as possible, with lots of relevant detail.  The less precise your tender, the wider the range of costs you are likely to be quoted.
 
Consider asking an independent IT consultant with experience of Content Management to help you produce the brief.  In the absence of a budget for this, try to spend as much time as possible on making your brief detailed.

At a minimum, your tender should contain:

  • an overview of your organisation
  • your motivation for undertaking the project
  • your strategic goals for the website
  • an overview of the types of audience that you expect to use your site
  • specific functionality requirements (e.g. make it easy for site visitors to cover their tracks)
  • any restrictions regarding technology, hosting, etc (e.g. the site must be use only Open Source components, or must be AAA-level accessible)
  • the amount of traffic you are expecting
  • the level and nature of technical support required
  • the amount of content (a) that you currently have; (b) that you'd like to have
  • in addition to technical build, do you want other consultancy services, such as:
    • help developing content
    • a new visual design
    • usability consulting?

Although the tender must be detailed, beware of second-guessing the solution by prescribing your own vision of how the site will be implemented.  You should focus on your needs, rather than perceived solutions - otherwise you run the risk of missing out on creative solutions to your problems.  Examples of unecessary detail include:

  • A sitemap
  • User interface details, such as "the site must use dropdown menus"
  • Design details, such as colour palettes to use

It can be tricky to distinguish between a need and a solution.  To take the "dropdown menus" example above: instead of specifying dropdown menus, you should give the reason why you've decided you need them.  This reason might be that your users typically don't have much time to surf, so they need to access all major content straight from the home page.

Finally, you may find it helpful when it comes to comparing suppliers if you share with them your criteria for making your decision.  These might include:

  • Relevant experience in the sector
  • Ability to deliver to your timescales
  • Breadth of skillset
  • Longevity of company
  • Quality of references
  • Ease of use of CMS / specific features in CMS
  • Clear quality assurance procedure

Good luck in finding the right supplier.




Skip the secondary navigation if you do not want to read it as the next section.


Secondary Navigation

The following page sections include static unchanging site components such as the page banner, useful links and copyright information. Return to the top of page if you want to start again.


Page Extras

Skip the main banner if you do not want to read it as the next section.


Page Banner


End of page. You can return to the page content navigation from here.