Is switching tools worth it?

What the number assumes

4.33 is the average number of weeks in a month. The switching cost should include migration, retraining and the productivity dip, that dip is usually the largest part and the one people leave out.

The formula defines the arithmetic. It does not define your business. A figure from this page is a starting point for a decision rather than the decision.

How to calculate the return on a tool

The monthly benefit is the number of people affected, multiplied by the hours each saves per week, multiplied by what an hour is worth, multiplied by 4.33 weeks. Subtract the subscription and you have the net monthly gain. Divide the one-off switching cost by that gain and you have the number of months until the tool has paid for itself.

Every one of those inputs is an estimate, which is the honest limitation of the exercise. Its value is not the precision of the answer but the discipline of having to state each assumption where somebody else can disagree with it.

Be sceptical about the hours saved

This is where tooling business cases go wrong, and they go wrong in a predictable direction. An hour a week per person sounds modest and is not: across twenty people at $50 an hour it is over $50,000 a year, which should prompt the question of whether anyone can point to where that hour currently goes.

The test for a claimed saving is whether you can name the task. "Faster hand-off between design and planning" is not a saving; "nobody re-creates the task list from the board by hand, which is forty minutes per project" is one, and it can be measured before and after.

Halve whatever number you first arrive at, then see whether the case still holds. If it does, you have a robust one. If it does not, you have learned something before spending the money rather than after.

The costs that are not the subscription

Administration, integration work, the internal owner who fields questions, and the ongoing cost of one more system to keep secure and to include in every audit. None of these are large individually; together they routinely match the licence fee for a mid-sized deployment.

There is also the cost of the tool you are not switching away from. Adding a tool without removing one means paying for both, and the business case has to be made against that total rather than against the new line alone.

What a reasonable payback period looks like

For a subscription tool, under twelve months is a comfortable case, twelve to twenty-four is arguable if the tool also removes a risk or unlocks something new, and beyond twenty-four the decision is being made on capability rather than on cost, which is legitimate, but it should be said out loud.

Set a date to check the assumption. A tool adopted on a projected saving that nobody ever verified is indistinguishable from one adopted on enthusiasm, and the next business case will be believed less.

Checking the claim after the fact

Set a date three months after adoption and measure the same task you measured before. It takes an hour, and it is the only thing that turns a business case into evidence. Almost nobody does it, which is why tooling business cases are believed a little less each time.

If the saving is not there, the useful question is why rather than whether to admit it. Frequently the tool works and the workflow around it never changed, which is a fixable problem and a far cheaper one than replacing the tool.

Questions