The demo is not the criterion

The problem it solves

The demo is built so that everything works, and everything works. The data is clean, the case is simple, the flow never stalls and the presenter knows every screen by heart. None of that is dishonest; it is how a presentation is prepared. The trouble is when that hour becomes the basis for a decision that will stand for years.

What follows has a pattern. The criteria get written after the options have been seen, so they describe the one somebody already preferred. The departments that will use the tool hear about it once the decision is effectively made, and only then bring the odd case that accounts for a third of their volume. The comparison collapses into features and price, because those are the two easy columns to fill. And the questions that decide the long-run outcome go unasked, simply because nobody had them written down.

The cost surfaces later and gets attributed to the wrong thing. The company finds that its information sits in a shape it cannot easily get back, that nobody inside can keep the tool running without outside help, or that a version change disturbs the flow it had carefully adjusted. When that happens, the internal verdict is usually that the tool was poor. Almost always, what failed was the selection.

What it covers

The workshop reverses the usual order. It begins with the requirement, drafted from the process rather than from a feature list: what a person has to be able to do, at which moment, with which information at hand and under whose authorisation. Working from a worksheet, each participant turns their process into a list of checkable demands and discovers how many of the ones they arrived with were in fact preferences inherited from the tool they use today.

The second part builds the scoring matrix before anything is seen. In a group exercise the criteria and their weights are agreed, including the ones no presentation offers unprompted: who owns the information and in what shape it can be retrieved, what it would take to stop using the tool, who inside the company could keep it running, what happens when the version changes, and what is required for it to work with what already exists. Fixing the weights before meeting the candidates is the whole mechanism: after that, the criteria can no longer be bent to fit a preference.

The third part is about running the evaluation. Participants assemble a demonstration script from their own cases, including two difficult ones and one currently handled by hand, then rehearse through role play the conversation in which you ask to see that case rather than the prepared one. The reference conversation is worked too: what to ask another company using the tool in order to get something other than general praise.

The closing section settles who decides and how the decision is recorded. It separates whoever recommends from whoever approves and from whoever will use, and produces a short record explaining why one option was chosen, what was ruled out alongside it, and which assumptions would have to fail for the choice to turn out wrong. That record is what makes it possible to assess the selection later without reconstructing the conversation from memory.

What participants learn

• Develop a requirement list derived from the process rather than from a supplier's feature catalogue.
• Design a weighted criteria matrix agreed before any available option has been seen.
• Evaluate the criteria no presentation volunteers: ownership of the information, cost of leaving and who sustains it internally.
• Apply a demonstration script built from your own cases, including the ones handled by hand today.
• Compare options through a decision record that states what was ruled out and on which assumptions.

Agenda

1. 01From process to requirement: what a person must be able to do, and when
2. 02Preferences inherited from the current tool, dressed as requirements
3. 03The criteria matrix and why the weights are fixed first
4. 04Ownership of the information and the shape it can be retrieved in
5. 05Cost of leaving: what it takes to stop using a tool
6. 06Who keeps the tool running from inside the company
7. 07A demonstration script built from your own and your hardest cases
8. 08The decision record: what was chosen, what was ruled out, on what assumptions

What the organisation leaves with

• A written requirement list derived from the company's own process.
• A weighted criteria matrix agreed before any option has been seen.
• A demonstration script built from the company's own cases, including two difficult ones.
• A decision record format capturing what was chosen, what was ruled out and the assumptions behind it.