A Trial That Can Fail

A trial designed around a demonstration script proves the demonstration script works. The useful version runs your awkward cases.

Decide the criteria first

Written before the trial starts.

The scenarios that must work, taken from your own hard cases rather than the vendor's examples.

The rules that must be configurable by you, not by their consultant.

The integration that must be proven, at least one direction, with real data shapes.

Who decides, and what result would mean no. If nothing would, the trial is a procurement formality.

Structure it honestly

Configure it yourself. If the vendor's implementation team sets it up, you have measured their team rather than the product, and after go-live you are the one configuring it.

Use real data, or realistic data with the same awkward shapes: the split shift, the midnight crossing, the interrupted break, the retrospective correction.

Include the users who will actually record time, not only administrators.

Run it long enough to include a period close, because that is where products differ most.

The scenarios worth running

A correction after approval, and what it does to an already-exported payroll file.

A rule change mid-period. Does it apply retrospectively, and can you choose?

A person moving between jurisdictions or contract types.

Bulk correction of a misconfigured rule across two hundred people.

An export of everything, including the audit trail, and opening it in something else.

A subject access request: produce everything held about one person.

These six find more than any feature comparison, and several products fail at least one.

During the trial

Note every time you had to ask the vendor how to do something. That count is your future support load.

Note what you could not do without them. That is your future change-request bill.

Time the routine tasks: entering a week, approving a team, running the period.

Check the defaults, including whether any monitoring capability is on.

Afterwards

Score against the criteria written at the start, not against impressions.

Delete the trial data, or migrate it deliberately. Trial data becoming the first month of production history by accident is a real and annoying outcome.

Write down what failed, because the same product will be proposed again in two years and the file is the answer.

Concluding no is a successful trial. It cost a fortnight instead of a three-year contract.

Configure it yourself

The single decision that determines what a trial measures.

If the vendor's implementation team sets it up, you have measured their team.

After go-live, you are the one configuring it, and the trial should tell you whether that is possible.

Note every time you had to ask them how. That count is your future support load.

Note what you could not do at all without them. That is your future change-request bill, and it is the number that should inform the contract.

Delete the trial data

Or migrate it deliberately, which is a decision rather than an accident.

Trial data becoming the first month of production history is a real and annoying outcome, and it corrupts the earliest part of your record.

If people recorded real time during the trial, it is real data with real obligations — notice, retention, access — and cannot simply be left.

Decide before the trial starts which it will be, and write it into the plan.

Include resource planning in the trial

Recorded time only becomes useful when it informs a decision. This resource-planning case can supply a realistic output test.