How this guidance works
This page provides template language you can adapt for your own RFPs when procuring digital services. Each section includes the rationale for why it matters and suggested wording you can use or modify.
The aim is to ensure that every supplier working on government digital services in Barbados is held to the same standards – regardless of which ministry is commissioning the work.
Before you write the RFP
Understand user needs first – through research with citizens
The single most important thing you can do before writing an RFP is to conduct user research with the people who actually use the service. This means members of the public – citizens, residents, businesses – not solely the civil servants who administer the process.
This distinction matters enormously. When requirements are gathered only from government staff, the resulting system will reflect how the back office works today. It will digitise existing forms, replicate existing queues, and preserve existing steps – even when those forms, queues, and steps are the problem. Civil servants have valuable knowledge about how a service operates, but they experience it from the other side of the counter. Only citizens can tell you what it is like to navigate a service as a user: where they get confused, where they give up, what information they cannot find, and what would actually make the process easier.
If you have already conducted user research, the RFP should be grounded in what you learned. Reference the research findings, describe the user needs you have identified, and make clear that you expect the supplier to build on this evidence – not start from scratch or substitute their own assumptions.
If you have not yet conducted user research, be honest about this in the RFP and make research the first deliverable. Do not attempt to write detailed requirements without evidence of user needs. Requirements that are not grounded in research are guesses, and procuring against guesses is how government ends up with expensive systems that nobody wants to use.
Define the problem, not the solution
An effective RFP describes the user problem to be solved and the outcomes government wants to achieve. It does not prescribe a technical solution. This gives suppliers the space to propose innovative approaches while keeping government focused on what matters.
Before drafting, make sure you can clearly answer:
- Who are the users of this service – both members of the public and public servants – and what do they need?
- What outcome will success look like – for citizens first, and for government?
- What constraints must be respected (security, accessibility, interoperability, data sovereignty)?
- What is the government’s current capability to oversee this work?
If you cannot answer these questions, you are not yet ready to procure. Consider running a discovery phase first – either internally or with a small, time-limited engagement focused on user research.
Scope for phases, not the whole programme
Structure the RFP around a single phase of work (discovery, alpha, or beta) rather than the entire service lifecycle. This reduces risk, creates natural decision points, and avoids locking government into a long-term commitment before learning has happened.
If the service is urgent, scope the RFP for a time-boxed pilot at a single location or for a single service area. A low cost 12-week pilot will teach you more than a requirements document that took six months to write.
Essential RFP sections
1. Context and problem statement
Describe the situation as it is today, the users affected, and the problem to be solved. Be honest about what you know and what you do not yet know – this signals to suppliers that you value learning and iteration, not false certainty.
Template language:
The Government of Barbados is seeking a supplier to [describe the phase of work – e.g. “conduct a discovery and alpha phase for a digital appointment booking service”]. The aim is to [describe the user outcome – e.g. “reduce waiting times for citizens accessing passport services and enable online appointment booking”]. We do not have a predetermined technical solution and expect the successful supplier to work with us to identify the right approach based on user research and evidence.
2. Scope of work
Define the phase, its duration, and the key questions it should answer. Avoid listing detailed functional requirements – these should emerge from user research during delivery.
Template language:
This engagement covers [phase name] over a period of [duration]. The supplier will work alongside GovTech Barbados staff to:
- understand user needs through research with real users of the service
- map the current service journey and identify pain points
- prototype and test potential solutions with users
- recommend an approach for the next phase, including technology choices, team structure, and estimated costs
The supplier is expected to involve government staff in all activities. This is a capability-building engagement, not a handover of responsibility.
3. Working practices and standards
This is where you set clear expectations about how the supplier will work. All suppliers delivering digital services for the Government of Barbados must comply with the following.
Digital Service Standards. The supplier must demonstrate how their approach meets the Barbados Digital Service Standards throughout delivery – not just at a final assessment.
Template language:
All work must meet the Barbados Digital Service Standards. The supplier must demonstrate compliance throughout delivery, not solely at the end of the engagement. Services that do not meet the Standards will not progress to the next phase.
Design System. Where the service includes user-facing interfaces, the supplier must use the Barbados Government Design System.
Template language:
Any user-facing elements must be built using the Barbados Government Design System. Deviations require written approval from GovTech Barbados and must be contributed back to the Design System for the benefit of all government services.
Working in the open. Code, research findings, and design decisions should be visible to government throughout – not presented at the end.
Template language:
The supplier must work in the open. This means:
- all code is committed to a government-owned repository from day one
- user research findings are shared as they emerge, not held for a final report
- design decisions and architecture choices are documented as they are made
- progress is demonstrated through working software, not slide decks
GovTech Barbados staff will have access to all project tools, repositories, and communication channels used during delivery.
User-centred design. The supplier must conduct user research with real users – primarily members of the public who use the service – and demonstrate how findings have shaped the service. Research with civil servants is also valuable, but it is not a substitute for understanding citizen needs directly.
Template language:
The supplier must conduct user research with members of the public who use or will use the service. Research must be conducted at regular intervals throughout the engagement – not only at the beginning. Participants must include people with a range of access needs, digital confidence levels, and circumstances, including people who currently struggle with or avoid the existing service.
Research with public servants who administer the service is also expected, but must not be the sole or primary source of user needs. The supplier must show how research findings from citizens have directly influenced design and development decisions.
The supplier must not substitute stakeholder workshops, expert reviews, or assumptions about user behaviour for direct research with the public.
Accessibility. All digital services must be accessible to all users, including those with disabilities.
Template language:
All deliverables must meet WCAG 2.1 AA as a minimum. The supplier must conduct accessibility testing with assistive technologies and include users with access needs in research activities. Accessibility is not a final check – it must be built in from the start.
4. Team and ways of working
Require the supplier to name the individuals who will do the work and describe how they will collaborate with government staff.
Template language:
The supplier must name the individuals who will work on this engagement and provide evidence of their relevant experience. We expect the team to include, at minimum, [list roles relevant to the phase – e.g. “a user researcher, an interaction designer, and a developer”].
The supplier’s team will work alongside GovTech Barbados staff as a single, integrated team. GovTech Barbados will provide [list government roles – e.g. “a product manager who will set priorities, and a service owner who will make decisions about the service direction”]. The supplier must not work in isolation or in a separate location from the government team without agreement.
5. Knowledge transfer and capability building
This section is critical. Without it, government learns nothing and vendor dependency grows.
Template language:
A core objective of this engagement is to build the capability of GovTech Barbados staff. The supplier must:
- pair with government staff on all key activities – research, design, development, and architecture decisions
- document decisions and technical choices as they are made, in a format accessible to government staff
- ensure that government staff can install, deploy, and modify the system by following written documentation alone, without verbal assistance
A portion of the contract value [specify – e.g. “15% of the total”] will be withheld until knowledge transfer has been independently verified. Verification means a designated government developer can complete a defined enhancement to the codebase without contractor assistance.
6. Intellectual property and code ownership
Template language:
All intellectual property created during this engagement belongs to the Government of Barbados. All code must be committed to a government-owned repository from day one and licensed under [specify open-source licence – e.g. “the MIT Licence”]. The supplier may not reuse government-specific implementations without written permission.
7. Evaluation criteria
Evaluate suppliers on their ability to deliver in the way described above – not on the impressiveness of their written proposal.
Suggested weighting:
| Criterion | Weight | What to look for |
|---|---|---|
| Understanding of user needs and approach to research with citizens | 30% | Evidence of genuine user research practice with the public, not just stakeholder workshops or assumption-based personas |
| Technical approach and use of open standards | 20% | Modern practices, open source, interoperability, no lock-in |
| Team capability and relevant experience | 15% | Named individuals with demonstrable experience in similar contexts |
| Approach to knowledge transfer and capability building | 20% | Specific, concrete plans – not generic promises |
| Value for money | 15% | Realistic pricing; note that cheapest is not best |
Template language:
Proposals will be evaluated on the criteria above. We value evidence of practical experience over theoretical frameworks. Suppliers are encouraged to provide examples of previous work, including services they have delivered that are publicly accessible. The lowest-cost proposal will not automatically be preferred – we are optimising for long-term value, capability building, and reduction of vendor dependency.
8. Contract structure and phase gates
Template language:
This contract covers [phase name] only. Progression to subsequent phases is not guaranteed and will depend on:
- whether the phase has met its success criteria
- whether knowledge transfer requirements have been satisfied
- whether government has sufficient confidence in the approach to proceed
The Government of Barbados reserves the right to re-compete subsequent phases with different suppliers. The successful supplier for this phase will not receive preferential treatment in future procurements.
Practical tips
Keep the RFP short. A 10–15 page RFP signals that you know what you want. A 100-page RFP signals that you are trying to eliminate risk through volume – which never works.
Ask for a short written response and a working session. Rather than evaluating lengthy written proposals, ask suppliers to submit a brief response (5–10 pages) and then conduct a working session where the team talks through how they would approach the first two weeks. This tells you far more about how they actually work.
Talk to previous clients. Ask for references and actually follow up. Ask the references: did the supplier conduct genuine research with members of the public, or did they rely on workshops with staff? Did the supplier transfer knowledge effectively? Could you operate the service independently after the engagement ended?
Involve your technical staff in evaluation. If GovTech Barbados engineers or product managers are available, they should be part of the evaluation panel. If not, consider engaging an independent technical assessor.
Publish the RFP widely. Do not rely solely on vendors you already know. Publish on government procurement portals, share with regional digital communities, and consider whether international suppliers working remotely could offer good value.