How These Projects Fail

Timesheet implementations fail in recognisable ways, and the diagnosis matters more than any methodology.

Rules discovered during implementation

The symptom: configuration overruns, and payroll keeps producing exceptions nobody documented.

The correction: rule discovery as a phase before evaluation, because the rule list determines which products are viable.

One parallel period

The symptom: rule errors reach the first live payslip.

The correction: three periods, compared line by line per person rather than by total.

Totals reconciled instead of lines

The symptom: a matching total and individual errors in both directions.

The correction: automate the per-person comparison; it is an afternoon of work.

Payroll not in the room

The symptom: a product chosen on features that cannot express one essential rule, discovered after signature.

The correction: payroll and legal produce constraints before procurement produces a shortlist.

Monitoring arriving by default

The symptom: a workforce reaction out of proportion to a recording rollout.

The correction: exclusions written into requirements and contract, defaults checked at trial and after every upgrade.

Nobody owns it afterwards

The symptom: rules out of date, access never reviewed, retention unenforced, corrections piling up at close.

The correction: a named owner with allocated time and a runbook their deputy can follow.

History migrated badly

The symptom: created-at timestamps restamped with the import date, or an audit trail that did not survive.

The correction: test the export before deciding; where it is inadequate, archive rather than migrate a degraded copy.

Training compensating for configuration

The symptom: an hour of training to record a day's work.

The correction: fix the category list and the mandatory fields; ten minutes is the target and anything longer is a design finding.

No stabilisation period

The symptom: an unplanned scramble for two months after cutover, and corrections made in a hurry that later look like errors.

The correction: plan four to eight weeks of capacity after go-live.

The common thread

Each of these is treating the project as a software installation when the work is rule configuration, reconciliation and organisational agreement.

Installation is an afternoon. Everything expensive here is the part that involves other people, and plans that allocate time the other way round run late in exactly the same place every time.

Diagnosing before buying again

A replacement product bought to fix a failing deployment usually fails the same way.

Work through the list and name which failure you have.

Rules discovered late, one parallel period, totals instead of lines, payroll absent, monitoring by default, no owner, bad migration, training covering for configuration, no stabilisation.

Only one of those is a product problem.

Where the honest answer is that nobody owns it, say so rather than proposing a purchase, because the new one will not be owned either.

Measuring the project honestly

Four questions at go-live plus ninety days.

Were three parallel periods reconciled line by line and signed off in writing?

Can the statutory record be produced for a named person in minutes?

Does the deputy administrator close a period without help?

Has the correction rate stabilised, or is it still rising?

A no to any of these names the remaining work, which is more useful than declaring the project complete.

Test one representative connection

Integration failures are easier to expose with a concrete flow. Use this project example to test ownership, identifiers and retry handling before multiplying connections.