Choosing and running the software · 4.1
Writing down what you need first
Writing down what you need first. What decides it, what it costs, and what usually goes wrong. For another implementation reference, see this Monitask guide.
Shopping before specifyingThe common failure
The usual sequence is three demonstrations followed by a requirement list assembled from what the demonstrations contained.
This feels efficient and it inverts the process: the requirements end up describing the products rather than the business, and the feature that impressed somebody in a demonstration acquires a place on the list it would never have earned on its own. For broader background, see Verint.
What the list has to contain
The claims. What the record must support, from the entry on that subject. This is the foundation and it is the part most lists omit.
The entry contexts. Where people are when they record: a desk, a phone at a gate, a machine terminal, a call. Each is a different product requirement.
The constraints. Offline operation, devices people actually have, languages, jurisdictions, and any consultation obligation.
The integrations. Named systems, with which direction the data flows.
The refusals. What you will not accept.
The refusal list is the rarest and the most useful
Almost nobody writes one, and it is the section that does the most work in an evaluation.
No screen capture. No activity scoring. No ranking of individuals. No collection people are not told about. Data exportable in a readable form. Records not silently alterable.
Six lines, and they eliminate a substantial part of the market before any demonstration is booked, which saves everybody's time.
Every item on that list is a property of this product rather than a setting.
Which means it is a commitment you can hold a supplier to rather than a configuration somebody could change after purchase.
Must, should, will not
Three categories, not five. Anything in the first must be demonstrated rather than asserted. Anything in the second is a tiebreaker. Anything in the third ends the conversation.
Lists with weighted scoring across forty criteria produce a number that nobody trusts and a decision taken on other grounds anyway.
One page
If it does not fit on one page it contains requirements nobody will check. A long specification is also an invitation to a long response, and comparing two hundred-page responses is not an evaluation.
Who writes it
Whoever will be entering time, whoever consumes the output, and whoever owns the systems it must connect to. Three people, one session.
A list written by procurement describes procurement's concerns, which are real and are not the ones that determine whether the thing gets used.
Revising it after the first demonstration
Legitimate, once, and it should be a deliberate act with the reason recorded. What must not happen is silent accretion, where each demonstration adds a requirement and the final list is a portrait of the last product seen.
Requirements that are really preferences
Half of most lists. A particular report layout, a colour, a workflow somebody is used to from a previous employer. Each is legitimate as a preference and each is corrosive as a requirement, because it eliminates products for reasons unconnected to what the record must support.
Test each line by asking what fails if it is absent. If nothing fails, it belongs in the second category.
The requirement nobody writes
That people will actually use it. It is the requirement on which everything else depends and it appears on almost no list, because it is hard to express as a feature.
Express it as a measurement instead: entry in under some number of seconds, demonstrated on your device by one of your people. That is checkable and it eliminates more products than any other line.
Budget as a constraint
State it, including the recurring figure and the internal time you can allocate. Suppliers who cannot work within it will say so, which saves two demonstrations.
Withholding it in the hope of a better price mostly produces proposals aimed at the wrong scale.
Reviewing the list afterwards
Six months after deployment, read it again. It shows what you thought you needed against what turned out to matter, and it is the single most useful input into the next evaluation, whether that is yours or a colleague's.
A worked one-page list
Must: entry in under ten seconds on a phone, demonstrated by one of ours; offline capture on site; attribution to client and cost code; export of every entry with corrections; payroll integration; each person sees their own record.
Should: approval workflow; a mobile widget; reporting by project phase.
Will not accept: screen capture; activity scoring; any ranking of individuals; silent alteration of entries; an export we cannot read without the vendor.
Fifteen lines. Every one is checkable in a demonstration, which is the property that makes a list useful rather than decorative.
What to do with it afterwards
Send it to suppliers before the first demonstration. It shortens every conversation, it produces responses addressed to your situation rather than to a generic buyer, and one or two suppliers will decline, which is a useful outcome that costs you nothing.
Where to start
Write the refusal list first. It is the shortest section, it takes ten minutes, and it eliminates more of the market than the rest of the document combined.
One line to carry
A requirement list written after the demonstrations is a description of the demonstrations. Write it first, keep it to a page, and lead with what you will not accept.
Also in choosing and running the software
Why timesheets are left blank
A timesheet asks somebody to reconstruct a fragmented day hours later. The reconstruction is a guess and everybody knows it.
Choosing the categories
The list somebody picks in week one governs everything the record can later answer.
Reminders, nudges and escalation
Reminders, nudges and escalation. What decides it, what it costs, and what usually goes wrong.
What a manager should do with it
What a manager should do with it. What decides it, what it costs, and what usually goes wrong.