A well-written IT RFP (request for proposal) is one of the strongest predictors of whether an IT project will be delivered on time, on budget and as intended. When the document is vague, vendors fill the gaps with their own assumptions, prices swing wildly, and the organisation ends up comparing proposals that describe entirely different projects. When it is clear, the market responds with offers that can be scored side by side, and the winning vendor knows exactly what it has committed to deliver.
This guide walks through how to prepare an IT RFP for a software, infrastructure, website or managed-services project: what to include, how to write requirements, how to set evaluation criteria and how to avoid the mistakes that most often derail procurement.
If you are a government entity, your tender will be governed by the Government Tenders and Procurement Law and is typically published through the Etimad platform using the applicable standard templates. The advice below focuses on the technical substance that sits inside that framework.
Before you write: define the problem, not the product
The most common reason an RFP disappoints is that it starts with a solution rather than a need. "We need a new ERP" is a product statement. "Our finance and warehouse teams re-key the same data into three systems, and month-end close takes eleven days" is a problem statement, and vendors can propose far better answers to it.
Before drafting, agree internally on:
- The business objective: what should be measurably better once the project is live.
- The scope boundary: which departments, sites, users and systems are in, and which are explicitly out.
- Constraints: budget envelope, deadlines, hosting or data-residency requirements, and existing licences and contracts.
- Stakeholders and decision-makers: who signs off requirements, who scores proposals and who approves the award.
A few weeks spent here saves months later.
The essential sections of an IT RFP
Effective RFPs tend to follow a similar structure. Headings vary from one organisation to the next, but every one of these elements should be present.
1. Introduction and background
A short description of your organisation, the current situation and why the project exists. Vendors price risk, and context reduces it.
2. Scope of work
A clear statement of what the vendor will deliver: software, hardware, services, documentation, training, data migration, warranty and support. List the deliverables and, where possible, the phases and milestones.
3. Functional and technical requirements
The heart of the document, covered in detail below. Include integration points with existing systems, security requirements, performance expectations, hosting and Arabic/English language support where relevant.
4. Service levels and support
Response and resolution times by severity, support hours, on-site versus remote coverage, and how performance will be reported.
5. Project governance and timeline
Expected start and end dates, key milestones, reporting frequency, the client's own responsibilities and the acceptance procedure for each deliverable.
6. Vendor qualifications
What you need to see: relevant experience, the proposed team and their CVs, references, local presence and any mandatory registrations or certifications.
7. Proposal format and submission instructions
A required structure for responses (ideally mirroring your requirement numbering), page limits, the pricing template, the deadline, the clarification process and how long offers must remain valid.
8. Evaluation methodology
How proposals will be scored, published in advance so that vendors know what matters and your decision is defensible.
9. Contractual terms
Payment terms linked to milestones, intellectual property, confidentiality, penalties or service credits, warranty periods and termination.
How to write requirements vendors can actually price
Good requirements are specific, testable and prioritised. Compare:
- Weak: "The system must be fast and user-friendly."
- Strong: "Search results must be returned within two seconds for 95% of queries with 200 concurrent users. All user-facing screens must be available in Arabic (right-to-left) and English."
A few rules consistently improve quality:
- Number every requirement (for example FR-012 or NFR-004) so vendors can respond line by line and evaluators can trace each answer.
- Classify priority with a simple scheme such as mandatory, important and optional. Mandatory items should be genuinely non-negotiable: every unnecessary "must" narrows the field and pushes prices up.
- Describe capabilities, not brands. Naming a specific product restricts competition. Describe the capability you need and accept "or equivalent".
- Separate functional from non-functional requirements. Functional requirements cover what the system does; non-functional ones cover security, availability, performance, scalability, accessibility and compliance.
- Ask for a compliance matrix. Require vendors to state, for each requirement, whether it is met out of the box, through configuration, through custom development, or not at all.
Setting evaluation criteria: technical versus financial weighting
Publishing your evaluation criteria in the RFP is good practice and, in many procurement frameworks, a requirement. The central decision is how to balance technical quality against price.
- For commodity purchases such as standard hardware or licences, price can carry most of the weight once minimum specifications are met.
- For complex projects such as custom development, system integration or managed services, technical quality should dominate. Many organisations use splits such as 70/30 or 60/40 in favour of the technical score.
A robust and widely used approach is the two-stage evaluation:
- Score the technical proposals first, without seeing any prices.
- Set a minimum technical pass mark. Only proposals that clear it proceed.
- Open the financial proposals of qualifying vendors and combine the scores using the published weights.
Within the technical score, break the criteria down further: understanding of requirements, proposed solution and architecture, implementation methodology, team experience, relevant references and the support model. Define in advance what earns full marks, partial marks and zero for each criterion.
A published, weighted scoring model protects the organisation as much as the vendors: it makes the award explainable to management, auditors and unsuccessful bidders alike.
How to compare vendor proposals fairly
Even with a strong RFP, proposals rarely arrive in perfectly comparable form. To keep the evaluation fair:
- Use a panel, not a single evaluator, and have members score independently before they discuss.
- Normalise pricing. Insist on a mandatory pricing template that separates one-off costs (licences, implementation, hardware) from recurring costs (subscriptions, support, hosting) over the same period, such as three or five years. This reveals the true total cost of ownership.
- Check assumptions and exclusions. A low price often hides a long list of them. Anything a vendor labels "client responsibility" or "out of scope" still has a cost.
- Verify claims. Ask for demonstrations against your own scenarios, speak to references and, where appropriate, request a proof of concept.
- Document everything. Record scores, the reasoning behind them and any clarifications exchanged, and share clarifications with all bidders equally.
Common mistakes to avoid
- Recycling a previous RFP without adapting it to the current project.
- Over-specifying with unnecessary mandatory requirements that eliminate capable vendors.
- Under-specifying non-functional needs such as security, backups, availability and support, which are the areas behind most disputes after go-live.
- Setting unrealistic timelines for both the procurement and the delivery.
- Leaving out acceptance criteria, so that "done" is open to interpretation.
- Ignoring post-launch costs such as support, licence renewals and hosting.
- Leaving data ownership and exit terms vague, which makes changing vendor later difficult and expensive.
The bottom line
A strong IT RFP rests on four things: a clear problem statement, a numbered set of testable requirements, a published scoring model and a pricing template that forces like-for-like comparison. Get these right and the rest of the procurement becomes far simpler.
Solutions Plus supports organisations throughout this process, from defining requirements and drafting the RFP to evaluating vendor proposals and checking that delivery conforms to the contract. Learn more about our IT consulting services, or get in touch to discuss your project.