Who should be in the room, and who should not
Selections fail late because somebody with a veto was consulted after the decision rather than before it.
The classic failure is not choosing the wrong product. It is choosing a reasonable product and then discovering in month three that IT will not support it, finance will not approve the contract shape, or the team who will use it every day was never asked.
All three are avoidable, and all three are avoided at the start rather than by better communication later. To see how a vendor frames online timesheets in practice, online timesheets is useful as an example to translate into neutral requirements.
Three roles that must be distinguished
- Decider — one person who makes the call. Not a committee. Committees do not decide; they converge on whichever option nobody objects to.
- Vetoers — people who can stop it: IT, finance, legal, procurement, anyone with a compliance responsibility. Their constraints belong in the requirements, at the start.
- Users — the people who will operate it daily. Their input is about workflow and friction, and it is the input most often collected too late to change anything.
Confusing these produces the two standard dysfunctions: a decision made by people who will never use the product, or an endless consultation in which everybody has a veto and nothing is chosen.
A veto discovered at contract stage costs the whole evaluation. A user complaint discovered at rollout costs the adoption.
Ask users about the work, not about the product
Users shown three products will express preferences based on appearance and familiarity, which is not what you need from them.
What they can tell you better than anyone is what the current process actually involves, where it breaks, what the workarounds are, and which steps happen under time pressure. Collect that before the shortlist, and use it to build the trial scenarios later.
Keep the group small
Evaluation groups grow because inclusion feels safer than exclusion. Beyond about five people the group stops evaluating and starts negotiating, meetings become scheduling exercises, and the timeline doubles.
A workable structure is a small core group of three or four, with named vetoers consulted at defined points and a wider user sample involved specifically in the trial. Everyone else is informed, not consulted, and the difference should be stated plainly so nobody expects a vote they will not get.
Name the decider out loud
Where nobody is explicitly the decider, the decision defaults to whoever is most senior, most persistent or most enthusiastic. That is not the same as most informed.
Saying at the outset who will decide, on what basis, and by when, changes the character of the whole exercise. It also means the people who disagree can say so before rather than after, which is where the useful objections come from.
Write down who was asked
Keep a short record of which functions were consulted, what constraints they gave, and when. It takes minutes and it prevents the most tedious conversation in software procurement, which is the one where somebody asserts afterwards that they were never asked.
For an independent baseline when requirements touch security, NIST Cybersecurity Framework provides a public risk-management framework.