What Software Cannot Fix

A good deal of what gets presented as a software requirement is an organisational problem wearing a feature request.

Rules nobody agrees on

The symptom: the requirement says "configurable overtime" because two sites do it differently and nobody has decided which is right.

No product resolves this. It will implement whichever you configure, including both, indefinitely.

What does: a decision, taken before configuration, about which rule applies.

People not recording time

The symptom: a requirement for reminders, escalation and compliance reporting.

What the product will do: generate reminders that people ignore.

What actually works: reduce friction, cut the category list, make the data visibly useful, and check whether the tool fits the work. A team that consistently does not record is usually telling you something about the system.

Managers not approving

The symptom: a requirement for automatic approval after a deadline.

What that produces: approval that means nothing, which is worse than late approval.

What works: exception-based approval, so a manager faces six items rather than forty.

Distrust of the workforce

The symptom: a requirement for screenshots or activity scoring.

What the product will do: provide it, and the records will become defensive.

What works: addressing the underlying concern, which is usually about visible output rather than about hours. Monitoring answers a question nobody was actually asking.

Estimates that are always wrong

The symptom: a requirement for forecasting.

What the data can do: show the factor between estimate and actual by category.

What it cannot do: make the next estimate right, which is a practice change rather than a report.

Bad reference data

The symptom: a requirement for a better project picker.

What the product will do: render your unusable list more attractively.

What works: pruning the list, which is nobody's job and takes an afternoon.

How to use this during a procurement

For each requirement, ask what would change if the product provided it perfectly.

Where the honest answer is "nothing, unless we also decide X", the requirement is a decision in disguise.

Take those out of the specification and into a meeting, which is cheaper, faster, and frequently shortens the specification enough to widen the shortlist.

The requirement that is a decision

A test to apply to every line of a specification.

Ask what would change if the product provided this perfectly.

Where the honest answer is "nothing, unless we also decide X", the requirement is a decision in disguise.

Take it out of the specification and into a meeting, which is cheaper and faster.

This regularly shortens a specification enough to widen the shortlist, because the removed items were the ones no product could satisfy.

Visibility is not management

Even employee screen monitoring software cannot repair unclear priorities, weak supervision or work that lacks a measurable outcome. Those remain management responsibilities.