Requirements and vendor selection. Someone reading the quote on your side.

What you get

Four documents, and they are yours

Not a methodology deck. Four artefacts that engage the other party, and that keep working after we leave.

• 01

  A requirements document that engages

  Readable by a director, usable by a developer. The real processes, the edge cases, and explicitly what is out of scope. Gathered from the people doing the work, not only from the people commissioning it, because the workarounds they have built are the map of the actual requirements.

• 02

  Acceptance criteria, written before the build

  The section almost nobody produces, and the one that decides how the project ends. Verifiable conditions that turn « is it finished » from a negotiation into a line-by-line yes or no. Without them, acceptance happens when everyone is tired rather than when the work is done.

• 03

  A comparison grid, with the awkward questions asked

  Exclusions read before inclusions. The integration missing from the estimate. The data migration mentioned in one line that represents a third of the work. And the technical questions a supplier does not expect, which is where the value concentrates.

• 04

  Acceptance, signed against what was written

  Testing the edge cases and real data volumes, not the path that works in a demo. Qualifying each gap against the criteria set at the start, and separating a delivery defect from a new request. Then signing when it is genuinely delivered.

Before you commit

Four questions to put to anyone.

• Why not let the vendor write the requirements?

  Because a supplier lives off its own solution. Asked to write your requirements, it will produce, by construction, a document describing what its product already does. That is not dishonesty, it is a mechanical bias, and the result is a need shaped around an offer instead of an offer chosen for a need. The requirements come from you, or from someone with nothing to sell you.

• Do you write the RFP itself, or only the requirements?

  Both, and they are different documents. The requirements describe what the system has to do and how acceptance will be judged. The request for proposal wraps that in the commercial frame: what you are asking bidders to price, what they must disclose, how you will compare them, and the deadline. Plenty of consultations fail not because the requirements were weak but because the RFP never told bidders what comparison they were entering. We also review the statement of work before signature, since that is the document you will hold the winner to.

• Does the person doing this need to be technical?

  On a software project, yes, and it is the most discriminating criterion. Most people in this role come from functional consulting: they run a workshop well and hold a schedule, which is useful and insufficient. At the decisive moment, when a supplier says an interface cannot do what you asked or that a data migration will take three months, someone without build experience can only relay the answer. They become a conduit rather than a counterweight.

• You also build software. Is that not a conflict?

  It is, structurally, and it deserves to be named rather than glossed over. Whoever writes the selection criteria cannot then compete against them. So the rule is simple: on this engagement, if the scope goes out to bid, we do not bid. The reverse is fine and stated openly, we can be your builder, in which case this role stays with you or with a third party. What never happens is holding both positions on the same money.

• Is this worth it on a small project?

  Not always, and a straight answer matters more than a sale. Below a certain stake, this costs more than it protects. It earns its place as soon as there is real money at risk with a supplier, several departments to reconcile internally, or a data migration to work out. If your case does not justify it, a short scoping exercise is enough to write the requirements and the acceptance criteria, and you go to market on your own.