Tool versus task

A tool is a capability. A task is work that gets done. Acquiring the first does not accomplish the second, and the gap between them is where most automation budgets are spent.

The pattern is familiar. A tool is purchased on the basis of what it could do. It is configured for the general case. The specific tasks it was bought to remove are still performed by people, now with the additional overhead of maintaining the tool, and the operation is measurably worse while the project is reported as delivered.

The discipline is to name the tasks before choosing the tool, in the four-units sense: bounded activities with inputs, outputs and rules, that a named person currently performs and would stop performing. Then evaluate tools against that list.

Two questions expose the difference. Which specific tasks stop being done by a person, and who? And on what date does that person stop doing them?

A tool purchase that cannot answer both is a capability acquisition. Those are sometimes legitimate, and they should be labelled as such and given a different success measure, because judging a capability by task removal produces a year of arguments about whether it worked.