How to write a great tender

What is a tender/RFQ?

Most organisations will draft up some sort of project brief when they need to find a vendor. For smaller jobs that could be a request for quotation (RFQ) or for larger projects a detailed tender (RFT). For government agencies/departments, going to market it's often a requirement to show they’ve contracted value for money. For web development work, this often means putting together a full tender and then reviewing lots (and lots) of responses.

What makes a good tender/RFQ?

From a vendor perspective (our perspective!) a good/great tender document or RFQ provides us with all the information we need to truly understand your project and therefore respond with a proposal, plan, and quote. If the tender/RFQ is unclear, it makes our task much harder — but more importantly it also means vendors won’t be able to truly address your needs in their responses. And that makes choosing the best vendor very difficult.

There are lots of things you can do to make your tender or RFQ great. To start, here are our top seven tips:

1. Address the who and why
2. Provide a clear list of requirements
3. Consider a template response
4. Include some information on your budget
5. Include the project deadline/timelines
6. Give vendors enough time to provide a considered response
7. Set up a process for questions and answers

Below is more information on these top seven tips, plus other things you should consider when drafting a tender. Your goal is simple: to get the most accurate and considered responses possible, which are easy to compare so you find the best vendor for the project.

Who and why

If vendors have information on who the target audience is and why the agency/organisation is building or enhancing the digital service it helps us to frame our response. What are you hoping to achieve? What are your business pain points? Including this information in the tender means we can create a solution to meet your needs and respond to those pain points. As experts in our field, we might also come up with a better way to address ‘the problem’.

Also think about your key objectives and the project’s success factors — then include that information in the tender/RFQ.

Provide a clear list of requirements

Vendors need a clear and detailed list of requirements so we know exactly what you want and can respond appropriately. With every requirement ask yourself: “If I had no idea about this project, would I know what this requirement means?” It’s easy when you’re living and breathing a project to make assumptions based on your knowledge of the project. Give the RFQ/tender to someone in a different department to see if the requirements make sense to someone who doesn’t know anything about the project.

The clearer the list of requirements, the more accurate the proposals and quotes will be. From a vendor perspective, if the requirements aren’t clear it’s hard for us to come up with a tailored solution. And it’s better (safer) to overestimate the complexity rather than underestimate the requirements.

For a website development project, you might also like to include this information in your tender or RFQ as part of your requirements (or separately):

• Key findings and conclusions from any user research that’s been completed (if available).

• A draft information architecture (IA)/site structure (if available). IA is often something we work on during a project, but even a draft IA provides vendors with an idea of the size of the website.

• A list of the different content types envisaged (if known). For example, news content, blog pages, report pages, video content, forms, etc.

• For each content type provide as much information as possible. This is particularly relevant to forms. We often get tenders that simply say ‘a form’ but the complexity varies significantly depending on the audience, number of fields, length, interdependencies, etc.

• Any sketches or wireframes that show how you envisage the web page layout (if available).

• Information on existing functionality that needs to be brought across.

• Information on new functionality that needs to be built.

A note on functionality

Sometimes it’s difficult to describe the technical components and requirements of functionality and in this case it’s often easier to describe the requirement through user stories, that is, desired user actions. For example, the user story might be: "As a building manager, I want to see a map of projects and click on buildings so that I can see the energy ratings for that building."

Templated response

Often tenders give a template or instructions around the desired responses. This might be a ‘box’ that respondents have to fit their answer into, or guidelines in the question (e.g. a word count or another descriptor like ‘up to a page’). Having a response limit is a good idea for all parties, as long as it’s realistic. We actually quite like this ‘template’ style because it gives us an idea of your expectations and shows us how much information you’re looking for. So if one question asks for ‘1-2 paragraphs’ and another asks for ‘2-3 pages’ we know that you’re after more information and more detail on the second question. It’s also good for you, because it means you’ll get a similar level of detail from your respondents for each part of the tender. Again, this helps to ensure you’re comparing like-with-like when reviewing the responses. However, it’s a good idea not to be too rigid, because respondents can think outside the box and offer innovation. You might like to include a provision for an alternative proposal or even an open ‘any additional thoughts?’ section.

A really well-organised tender might also provide templates for the costings. For example, maybe you want a summary of the quote in a spreadsheet format that includes specific elements, the minimum and maximum estimate for hours required (remembering the clearer the requirements are the more accurate time estimates will be) and then the cost for each item. The tender could include the spreadsheet laid out exactly how you’d like it, then every vendor would fill out that spreadsheet for costs.

Budget

Not many clients reveal their budget, but there are lots of good reasons why it should be included in a tender or RFQ. A budget makes it easier to quantify the project and will help get the best responses possible.This will save both you and vendors time. For example, including a budget:

• Will ensure vendors don’t submit bids that are ‘way off’

• Will ensure vendors don’t overstate and overestimate the project

• Will make it easier for vendors to determine viability

• Can be crucial in a vendor’s response in terms of the direction of the proposed solution.

In short, a budget will ensure the vendor is proposing the best possible solution within your budget. So if you’ve got a budget, let respondents know.

Timelines for the project

If you’ve got a specific deliverable date (especially if it’s a hard date, like an event) include this in the tender or RFQ. This helps the vendor formulate the planned solution and project schedule and may even dictate whether they can respond (for example, if it clashes with other projects).

Response time

Drafting a considered response takes time, so be realistic with your timeframes. Reducing your window for the response may also mean some vendors decide not to respond at all.

Questions and answers

During a tender process, there’s often the need for vendors to ask questions or clarify requests/requirements so it’s a great idea to set up a meaningful process for this. Obviously it needs to be done within the framework of probity and a fair process, while also enabling specific questions that will help vendors create meaningful responses. A simple method to collate and share questions and answers with all respondents is ideal.

A Q&A provision can also help build a relationship between vendors and agencies, which will help ensure you’re all on the same page.

Other important considerations

While the above are our top seven, you should also consider the following:

• Opportunities for vendors to differentiate themselves — For example, you could include ‘What’s your innovation here?’ or other questions and sections that lend themselves to differentiation.

• Getting help if necessary for the technical details — Sometimes a lightweight discovery may help to inform the RFQ. Call us if you’d like to find out more about this.

• Agile project delivery — Salsa and many other web development companies pretty much exclusively run agile these days. It’s helpful for us (and others) if you include your appetite for agile delivery, and any in-house agile experience.

• Your stakeholders — As well as the website audience, it’s handy for vendors to know who the internal and external stakeholders are in the project.

• Your capacity and capability — Understanding the internal level of capacity and capability in terms of the project also helps us propose a solution.

• Scoring metrics — Set up some scoring metrics so that when you’re reviewing submissions, tender responses are scored against a specific set of criteria and the response with the highest score wins. This takes the emotion and subjectivity out of the process and allows for a clear winner to be decided scientifically.

Final words

So if you’re about to draft a tender or RFQ, or about to submit it, have a look at the checklist above and assess your tender. The better your tender or RFQ document, the more accurate and tailored your responses will be. Good luck!