Tool Documents

The Tool Is Not the Process

A tool is bought to support a process. Frequently the process does not exist yet, and the tool supplies one — designed by people who have never seen your organisation.

That is sometimes the best available outcome and it should be a decision rather than a side effect. For a separate operational reference from Monitask, see this overview.

What a tool imposes

A vocabulary. Deal, ticket, sprint, epic. Once the tool is in use these become how people talk, and the vocabulary carries assumptions about how work is structured.

A shape. The data model decides what can be represented — how many levels of hierarchy, whether a thing can be in two places, what a status is.

For broader context, see Computerworld.

A rhythm. Weekly sprints, monthly pipeline reviews, daily standups. Products embed cadences and reporting periods.

And a set of defaults that nobody revisits. The default workflow becomes the workflow, three years later, with nobody able to say who chose it.

When adopting the tool's process is right

Being clear, because this is not an argument for building everything yourself.

When you have no process. A young organisation adopting a well-designed product's conventions is getting the accumulated experience of everybody who built and used it. That is a genuine bargain.

When your process is bad and nobody will fix it. A tool that imposes a structure sometimes achieves what an internal initiative could not.

And when the process is not a differentiator. Expense approval does not need to be yours.

When it is wrong

When the process is how you actually compete. A production workflow, a specialist assessment procedure, an unusual delivery model. Bending it to fit a tool means becoming more like everybody who uses that tool.

When the fit is bad and the answer is heavy configuration. Every deviation from the defaults is configuration that will not transfer and that somebody must maintain. A product needing extensive configuration to fit is usually the wrong product, and the configuration is the evidence.

And when the tool is bought to create a process that people have not agreed on. Software does not settle a disagreement about how work should be done; it hides the disagreement until the tool is blamed.

The order that works

Describe the process first, in a page. Who does what, in what order, what has to be recorded.

Then find tools that fit it, rather than tools with the most features.

Then decide, explicitly, which of your steps you will change to match a product's conventions — and write that down as a decision.

The written page is also the specification for what the tool must do well, and it is what makes a trial conclusive rather than impressionistic.

The failure this prevents

Buying a tool to avoid a conversation.

The process is contested, nobody wants to decide, and a product is purchased in the hope that its structure will settle it.

It does settle it — badly, invisibly, and in favour of whoever configured it first. Two years later the argument reappears as a complaint about the software, and a replacement is bought.

The short version