Digitising a business is an operating decision, not an IT one

A million-dollar platform investment is easy to defend once assets have gone from $675 million to $4.25 billion. It is very hard to defend in the week you propose it.

When I took on the operations of an ailing wealth and investment management business, the problem was not really the operations. It was that nobody could see them. The management information was too thin to run the company on: we could tell you what had happened by the time the quarter closed, and by then it had already happened.

What we did about it was, on paper, a technology project — a million dollars into a platform that digitised the business end to end, from asset management through to fee generation. What it actually was is an operating decision that happened to involve software. The distinction is not semantic. It determines who sponsors the work, how it is scoped, what you measure, and whether it delivers anything at all.

Why these projects fail

Most failed digitisation programmes I have seen failed the same way. The business handed the problem to technology, technology delivered exactly what was asked for, and the business did not change.

You can spot it in the success criteria. If the project is judged on delivered to time, delivered to budget and went live, it is an IT project and it will produce an IT outcome: a system, running, that people work around. Nobody lies about this. Everyone does what they were measured on.

The other failure is subtler and more expensive. You digitise the process you already have. If that process is bad — and in a business that needs turning round, it is — you have not fixed anything. You have made it fast and wrong, and you have hard-coded it so that fixing it later costs three times as much.

Four rules I would apply again

1. The sponsor is the operator. The chief operating officer, the chief executive, whoever actually owns the P&L. Not the CTO, who should be building it rather than justifying it. If the person defending the investment at the board cannot describe the business outcome without using the product name, you have the wrong sponsor.
2. Start from the question you cannot answer. Not from the system you want. Ours was simple enough to say out loud: what is actually happening in this business between quarter ends, by asset, by adviser, by fee? Write your question down before you look at a single vendor. It becomes the specification, and it becomes the test.
3. Sequence around the money. The revenue chain first — assets in, activity, fees out. Everything else waits. This is unpopular with everyone whose function is not the revenue chain, and it is the reason the investment can be defended at the halfway point, which is when it will need defending.
4. Fix the process before you buy the platform. Every one of these programmes is an opportunity to retire a decade of accumulated exceptions, and the opportunity closes the day configuration starts.

Making the case to a board

The difficulty is that the return is real and the timing is unprovable. You are asking for a large cheque against a benefit that arrives in eighteen months, in a business that is currently underperforming, which is precisely when a board is least inclined to write large cheques.

Three things helped. First, framing the investment against the cost of the current state rather than the promise of the future one — not “this will grow assets”, which nobody can promise, but “this is what we currently spend producing numbers we do not trust”. Second, being explicit that the platform was necessary and not sufficient: it would make growth possible, and people would still have to go and do it. Third — and this is the one most people skip — agreeing in advance what we would report every month while the thing was unproven.

That last point matters more than the pitch. A board’s confidence in an eighteen-month investment is not built at approval. It is built in months four through nine, when there is nothing to show and you are still turning up with something honest to say.

What to measure while it is unproven

Not milestones. Milestones measure the project, and the board is not buying a project.

At ninety days: is the revenue chain data complete and reconciled, and how far behind real time is it? At six months: how many of the manual processes it was meant to retire have actually been retired — a number that is almost always lower than the plan, and the gap is the honest status report. At a year: can a manager answer a question about their own part of the business without asking anyone for a report?

That last test is the one I care about. The technology was never the achievement. The achievement was that we could finally see the business — and once you can see it, the decisions that had been guesses become ordinary management.