Vendors receive dozens of requests for proposal a month, and most of them look the same: a company background, a wish list of features, a demand for a fixed price by Friday. The good vendors answer those with a template. The great ones don't answer at all. If you want proposals you can compare, the RFP has to make the comparison possible.
Start with the problem, not the solution
The first page should say what is broken or missing and what it costs you. A vendor that understands the problem can propose a better route than the one you had in mind. A vendor that only gets a feature list has to guess, and guesses get priced defensively.
- The situation today: the systems involved, who uses them, what volumes they carry.
- What has to change: the outcome in business terms, with a number where you have one (hours saved, orders per day, closing time for the books).
- What must not change: integrations that stay, data that stays where it is, the go-live window you can't move.
Separate must-haves from would-likes
Every requirement you label mandatory becomes a line in the vendor's estimate. Keep the mandatory list short and make the rest explicitly optional, priced separately. You'll see immediately which vendors have done the optional parts before (they price them low and specifically) and which haven't (they price them high and vaguely).
Ask for the team, not just the price
The price of an IT services project is mostly the price of the people on it. Ask for the proposed team by role, seniority and location, the share of each person's time, and who the escalation point is. Ask whether the people named will be the people who show up. This one question separates vendors with a bench from vendors who will hire after they win.
Give a budget range
Buyers worry that stating a budget invites vendors to spend all of it. In practice it does the opposite: it tells serious vendors whether to bid and lets them propose the right-sized approach. Without a range, the proposals cluster around whatever each vendor guesses you can afford, which is useless for comparison. A range of plus or minus 30 percent is enough.
Fix the format
Ask for the response in a set order with page limits: the approach in two pages, the team in one, the timeline in one, risks and assumptions in one, the price in a table you supply. Vendors will hate this and your evaluation will take a third of the time. Every proposal that ignores the format tells you something about how the vendor will treat your project plan.
| Section | Limit | What you're checking |
|---|---|---|
| Approach | 2 pages | Did they understand the problem, and is the route sensible? |
| Team | 1 page | Named people, roles, seniority, location, share of time |
| Timeline | 1 page | Phases, go-live, what you have to provide and when |
| Risks and assumptions | 1 page | The honest ones are the vendors who'll tell you bad news early |
| Price | Your table | Comparable totals, optional items priced separately |
Set the timetable and keep it
Two weeks to respond is enough for a scoped project; three for a large programme. Publish the question deadline, the response deadline and the decision date, and share the answers to every vendor's questions with all of them. Vendors that see a buyer keep a timetable bid more carefully.
What Scopelyst does with this
If you'd rather not start from a blank page, Post a project asks the questions above and writes the scope of work for you to edit. Matched vendors see the scope, you see their responses side by side, and the first responses are free. The RFP builder does the same for a full request for proposal, or you can upload one you already have.
- RFP
- procurement
- scope of work
- vendor selection
The Scopelyst team
Written by the people who run the marketplace, from what buyers and vendors do on it. No guest posts, no sponsored articles.
