When a Kenyan NGO needs a new website or a major website redesign, the quality of the procurement document can have a significant impact on the quality of the final result.
A clear Terms of Reference (ToR) gives prospective web design agencies enough information to understand the organization’s needs, prepare relevant proposals and estimate the project accurately.
It also gives the NGO a structured basis for comparing proposals.
For donor funded projects and organizations with formal procurement processes, a well written ToR can be particularly important because it establishes the project’s objectives, scope, deliverables, expected timeline and requirements before vendors are invited to submit proposals.
This guide provides a practical Terms of Reference template for NGO website projects in Kenya, including the sections you should consider, what to put in each section and a copy and adapt template you can use for your own project.
Note: This is a practical website procurement template, not a legal or procurement policy document. Your organization should adapt it to its own procurement procedures, donor requirements and applicable Kenyan laws and regulations.
Terms of Reference, commonly abbreviated as ToR, are a document that explains what an organization wants a service provider or consultant to deliver.
For a website project, the ToR establishes the framework within which web design and development agencies can prepare their proposals.
A website project ToR typically explains:
A ToR is closely related to an RFP for website development services, although the two terms are not always used in exactly the same way.
In some organizations, the ToR forms part of the RFP or procurement request. In others, it is issued as a standalone document.
A poorly defined website project creates problems for everyone.
The NGO may receive proposals that are difficult to compare because every agency has interpreted the project differently.
One agency may propose a simple WordPress website.
Another may propose extensive UX research and a custom CMS.
A third may focus almost entirely on visual design.
All three may technically be responding to the same procurement request.
A strong ToR reduces this ambiguity.
It gives agencies a common understanding of:
It also makes it easier for your evaluation team to compare proposals on a like for like basis.
A comprehensive ToR for a website project can include the following sections:
Not every project needs every section. The level of detail should reflect the complexity of the website.
The following template can be adapted for a Kenyan NGO, nonprofit organization, development organization or donor funded programme.
Start by introducing your organization.
Include information such as:
Organization name:
[Organization Name]
Organization type:
[NGO / nonprofit / development organization / foundation / programme]
Location:
[City, Kenya]
Website:
[Existing website URL]
[Provide a short description of your organization, its mission, programmes, geographical focus and the communities or stakeholders it serves.]
[Organization Name] is a Kenyan nonprofit organization working to [describe mission]. The organization implements programmes in [locations] focused on [areas of work]. Its stakeholders include [beneficiaries, partners, government institutions, donors, researchers, policymakers, etc.].
Keep this section concise.
The agency needs enough context to understand the organization, but the ToR does not need to become a full organizational profile.
Explain why the website project is being undertaken.
Describe the current situation.
For example:
The organization’s existing website was developed in [year] and no longer adequately supports the organization’s communication, programme and knowledge-sharing requirements.
You could identify issues such as:
Be specific about the problems.
This gives agencies context for their proposed solution.
The problem statement should explain what is not working and why it matters.
For example:
The current website provides limited access to the organization’s programmes, publications and resources. Users have difficulty finding relevant information, while internal staff experience challenges managing and updating website content. The website also provides a poor experience on mobile devices and does not adequately support the organization’s current communications strategy.
A strong problem statement focuses on the underlying problem rather than prescribing the solution.
For example, instead of saying:
“We need a WordPress website with 20 pages.”
you might say:
“The organization needs a maintainable content management system that enables non-technical staff to efficiently manage programme, publication and news content.”
This allows qualified agencies to recommend an appropriate solution.
Define what the project is intended to achieve.
Possible objectives include:
Try to make objectives measurable where possible.
Instead of:
“Make the website better.”
consider:
“Improve the discoverability of publications by introducing improved information architecture, search and filtering functionality.”
Tell agencies who will actually use the website.
Your audiences could include:
For each major audience, briefly explain what they are likely to need from the website.
For example:
| Audience | Likely needs |
|---|---|
| Donors | Programme information, results, reports and organizational information |
| Researchers | Publications, datasets and resources |
| Partners | Programme information, opportunities and contact information |
| General public | Mission, programmes, news and impact |
| Job applicants | Vacancies and organizational information |
This helps agencies think about the website from a user perspective rather than simply reproducing your existing navigation.
This is one of the most important sections of the ToR.
Explain what you expect the selected agency to do.
Depending on the project, the scope could include:
The scope should reflect your actual requirements.
Do not include features simply because they sound impressive.
List the major functional requirements.
Depending on your organization, these could include:
For a resource heavy NGO website, specify the requirements for managing documents, videos, audio, reports and other resources.
You can also specify whether users should be able to filter resources by:
If research is important to the project, explicitly include it in the ToR.
Possible requirements include:
Do not assume that an agency will automatically conduct extensive research simply because you have requested a website redesign.
If you want research, make it part of the scope and deliverables.
For organizations that depend heavily on knowledge resources, research can be particularly valuable in determining how people actually find and consume information.
Explain the organization’s expectations around content.
Specify:
If the existing website has hundreds or thousands of resources, provide an estimate.
For example:
“The existing website contains approximately 2,000 publication records that may require migration.”
This allows agencies to price the work more accurately.
If the project involves replacing an existing website, include SEO requirements in the ToR.
These might include:
The selected agency should understand that the project involves migrating an existing digital asset, not simply launching a new website.
State your accessibility expectations.
For example:
“The website should be designed and developed in accordance with applicable accessibility best practices and the agreed WCAG requirements.”
Depending on the project, requirements may include:
If your organization requires a particular level of WCAG conformance, specify it.
The ToR should communicate the technical requirements without unnecessarily dictating the implementation.
You may specify requirements for:
Not necessarily.
If your organization has a genuine technical requirement for a particular CMS, state it.
Otherwise, consider asking agencies to recommend the most appropriate CMS and explain their reasoning.
This can produce better proposals than telling every agency exactly which technology to use before they have assessed the problem.
If the website collects personal information, include security and data protection requirements in the ToR.
Potential requirements include:
Kenya’s Data Protection Act, 2019 provides the country’s framework for the processing of personal data, with the Office of the Data Protection Commissioner responsible for oversight and regulation. (odpc.go.ke)
If your website will collect personal information, your organization should determine its obligations under the applicable data protection framework and communicate relevant requirements to the agency.
Where appropriate, the ToR should also clarify the agency’s role in processing personal data.
Do not assume that a website developer is responsible for all of an NGO’s data protection obligations.
List the expected deliverables explicitly.
For example:
| Phase | Deliverable |
|---|---|
| Discovery | Discovery report |
| Research | User research findings |
| Strategy | Information architecture |
| UX | Wireframes |
| Design | Responsive UI designs |
| Testing | Usability testing report |
| Development | Production website |
| Content | Migrated content |
| SEO | Redirect and SEO migration plan |
| QA | Testing report |
| Training | CMS training |
| Launch | Production deployment |
| Handover | Documentation and credentials |
This section becomes particularly useful when evaluating proposals and later determining whether the agency has fulfilled its obligations.
Provide your expected project timeframe.
For example:
The organization expects the project to be completed within approximately 12 weeks from contract commencement.
Then indicate any important dates.
| Milestone | Target |
|---|---|
| Procurement | [Date] |
| Agency appointment | [Date] |
| Project kickoff | [Date] |
| Discovery | [Date] |
| UX and IA | [Date] |
| Design | [Date] |
| Development | [Date] |
| Testing | [Date] |
| Training | [Date] |
| Launch | [Date] |
Do not create an unrealistic timeline simply because you want the website launched quickly.
A strategic website redesign involving research, custom design, development and significant content migration may take considerably longer than a simple website.
For guidance on realistic project schedules, see our article on how long an NGO website redesign takes.
Explain what the NGO and selected agency will each be responsible for.
These might include:
These might include:
This section can prevent misunderstandings later.
Tell agencies exactly what you want included in their proposals.
You might request:
Ask for examples of:
Ask agencies to explain:
Request information about:
Ask for:
Request a clear breakdown of:
Request contact details for relevant previous clients where appropriate.
Your ToR should explain how proposals will be evaluated.
For example:
| Criterion | Weight |
|---|---|
| Relevant organizational experience | 15% |
| Understanding of the project | 15% |
| Proposed methodology | 20% |
| Technical approach | 15% |
| Team experience | 10% |
| Portfolio and relevant case studies | 10% |
| Financial proposal | 15% |
| Total | 100% |
The exact weighting should reflect your organization’s priorities.
Do not automatically make price the largest factor.
A very cheap proposal may omit important work such as UX research, content migration, SEO, accessibility or testing.
For more guidance, see our article on what to look for in a web design agency for your NGO.
There are two common approaches.
For example:
The organization has allocated a budget of KES [amount] for the project.
This can help agencies propose realistic solutions within your financial constraints.
This allows agencies to independently estimate the cost based on the requirements.
Neither approach is universally correct.
Your procurement policy, donor requirements and project circumstances should determine which approach is appropriate.
If you need to establish a realistic planning figure first, see our guide to NGO website development costs in Kenya.
The ToR should communicate your expectations around ownership.
For example, you may require the selected agency to provide:
The final contractual agreement should establish the precise legal terms of ownership and licensing.
Do not leave this until the end of the project.
Your organization should understand the ownership arrangement before signing the contract.
For more information, see our website development contract checklist for Kenyan NGOs.
Specify who will own and manage the critical infrastructure.
This can include:
Where practical, your NGO should maintain control of critical accounts.
The selected agency can have administrative access without necessarily being the permanent owner of those assets.
Specify what happens after launch.
Ask agencies to explain:
Also ask agencies to distinguish between maintenance and new development.
A bug fix is not necessarily the same thing as adding a new feature.
Your organization’s procurement process may require additional information.
Depending on the NGO and funding arrangement, this may include:
Include whatever your organization’s procurement policy requires.
Do not copy another NGO’s procurement requirements without checking whether they apply to your organization.
The following condensed version can be copied into your organization’s own procurement document.
Reference: [Reference Number]
Date Issued: [Date]
Submission Deadline: [Date]
Project Location: [Location]
[Organization Name] is a [type of organization] working in [areas of work].
[Provide a brief organizational background.]
The organization intends to [develop a new website / redesign its existing website] to address [key problems].
The existing website is [brief description].
The objectives of the project are to:
The primary audiences for the website include:
The selected agency will be expected to provide:
The website should include:
The proposed solution should address:
The selected agency will be expected to provide:
The project is expected to commence on [date] and be completed by [date].
[Describe the organization’s responsibilities.]
[Describe the selected agency’s responsibilities.]
Applicants should submit:
Proposals will be evaluated based on:
[State budget or explain whether applicants should submit their own financial proposals.]
Proposals should be submitted to:
[Email / procurement portal / physical address]
Deadline:
[Date and time]
For clarification regarding this ToR:
Contact: [Name]
Email: [Email]
Telephone: [Phone]
“Develop a modern and user-friendly website” is not enough.
Explain what the website needs to accomplish.
If you tell every agency exactly how to build the website, you may prevent them from proposing a better solution.
Specify genuine technical requirements, but allow room for professional recommendations.
If you have an existing website, content migration can be a significant part of the project.
Estimate the amount of content involved.
A redesign should account for the organization’s existing search visibility.
If accessibility matters to your organization, include it in the requirements from the beginning.
Without clearly defined deliverables, proposals become difficult to compare and projects become difficult to manage.
The cheapest proposal is not necessarily the best value.
Compare methodology, experience, deliverables, team, technical approach and long-term costs.
Your organization should understand who will own the website, source code, designs, domain and other assets.
Give agencies enough time to perform research, design, development, testing and content migration properly.
The terms ToR and RFP are sometimes used interchangeably, but they can serve different purposes.
A ToR primarily describes the assignment.
It explains:
“This is the problem we need solved, these are our objectives and this is what we expect the consultant or agency to deliver.”
An RFP is typically the broader procurement document through which suppliers are invited to submit proposals.
It may contain:
For many NGO website projects, the ToR can therefore form an important part of the overall RFP package.
If you are preparing a complete procurement process, our guide on how to write an RFP for website development services provides a more comprehensive framework.
Before publishing your ToR, make sure your organization has answered several fundamental questions:
Answering these questions internally can make the procurement process considerably easier.
A strong Terms of Reference gives a website project a clear starting point.
For Kenyan NGOs, it can also make the procurement process more transparent and make proposals easier to compare.
The goal is not to write the longest possible document.
The goal is to give qualified agencies enough information to understand the organization’s needs, identify the underlying problems and propose an appropriate solution.
Your ToR should therefore be specific about the outcomes, requirements and deliverables, while allowing experienced agencies some flexibility in explaining how they would achieve them.
Once you have a clear ToR, the next steps are usually to evaluate agencies, compare proposals, negotiate the final scope and sign a contract that accurately reflects what has been agreed.
If you are preparing a website procurement process for your organization, these related guides can help:
