Where to Start

Most time tracking projects start with a product demonstration. The order that works starts with the question.

The sequence

One: name the purpose, from the four, in writing. Most projects cannot do this on the first attempt, which is itself the finding.

Two: establish the legal position for every jurisdiction you employ in. This determines what is mandatory and what is optional.

Three: find out what already exists. Access control, calendars, ticket systems and payroll frequently hold more than anyone realises.

Four: reconstruct one project's true cost by hand, including unbilled effort.

Five: consult, before procurement.

Six: design the category list with the people who will use it.

Seven: pilot with a willing team, with criteria written first.

Eight: then decide what to buy, if anything.

The first ninety days

Weeks one to three: purpose, legal position, inventory of what exists.

Weeks four to six: the hand-reconstructed project cost. This is the most persuasive artefact available and it requires no software.

Weeks seven to nine: consultation and category design.

Weeks ten to twelve: pilot, measuring recording delay and time spent recording.

No purchase required before week ten.

The hand-reconstruction

Worth doing even if nothing else happens.

Pick one completed project.

Ask everyone involved what they actually spent on it, including scoping, supervision, rework and support.

Add it up.

Compare with what was billed or budgeted.

The gap is usually large enough to change how the organisation prices, and it makes the case for a system better than any vendor material.

The governance to establish first

The purpose limitation, written and published.

Who decides on an exception, named.

Worker access to their own record as a requirement rather than a feature.

Retention per jurisdiction, with an owner.

A rules table, versioned.

None of this is expensive and all of it is much harder to introduce after a system exists.

What success looks like at ninety days

A stated purpose everyone can repeat.

One finding about the work, reported, that changed something.

A pilot with measured recording delay and a decision based on it.

Consultation completed with a written response.

And a recommendation, which may be that the existing arrangements are adequate — a legitimate outcome that a project structured around a procurement can never reach.

What ninety days should produce

The output that justifies the next phase, or honestly ends it.

A stated purpose everyone can repeat.

The legal position for every jurisdiction.

One hand-reconstructed project cost.

Consultation completed with a written response.

A pilot with measured recording delay and a decision based on it.

A recommendation, which may be that the existing arrangements are adequate.

That last outcome is legitimate and a project structured around a procurement can never reach it.

What to avoid early

Five moves that make the rest harder.

Buying from a demonstration.

Starting with activity monitoring, which poisons the recording that is actually needed.

Rolling out first to the team you most want to watch.

Setting individual targets before the data exists or is trusted.

Treating a pilot as exempt from notice and consultation, which is the most common compliance failure in this field and is easily avoided.

A concrete product reference

When translating this principle into a buying test, the official Monitask website provides a concrete feature and workflow reference. Verify the relevant behaviour in a trial, retain the exported evidence and judge it against the purpose and limits described above.