Why banks kill good recommendations, and what survives

I started as an IT person, and we always propose technology. Then I went over to the bank side and understood what nonsense I had been proposing. Sitting there, I thought: what are you talking about? That is not what my head hurts about at all.

I had been a strategy director in a bank, and it was very difficult for me to narrow strategic initiatives down to three to five. It was at least ten. I started from twenty-five.

An outside recommendation arrives into that funnel and has to beat the twenty-four already in it.

Most of the time it is not politics

The team is loaded with operational work and its own pipeline. The backlog is completely full, most likely with very important tasks that were approved at board level, and there is no getting off them.

So new hypotheses are hard to test. As a rule, to get something approved and into the product backlog, you have to test it, understand the metrics, the business metrics. How customers behave, what the penetration is, what the retention is, maybe how they use it at all or what they say about it, before you defend it and start investing in it.

Read that list again from the position of the person you are asking to champion your recommendation. That is the work you are handing them, before they can even argue for it.

And sometimes it is politics

Say we take the consulting, and we strain, and we do it well. It hurts us, but it is always good. And we put that paper on the desk of a deputy chairman of the board.

Where does that paper go next? He passes it down to the technical director. The technical director says: nobody agreed this with me, and I think differently. And these people who wrote it, are they going to implement it themselves? Then go ahead, please, take my place.

I would have done the same in his place. Someone from outside, not tied to the bank at all, is advising something that puts his competence in question. That is simply a dead end. You will not break through.

So I would try to reach the CTO first, get to know him, and present the whole thing as help to him. Through helping him you can then go up to the leadership. Otherwise he will stall everything, and we will simply have done empty work. We help him, we tell him what we see, he gives his opinion, he says they are fine as they are, and that is it. You end up with two different opinions, and the bank decides which one looks better argued.

There is often nobody to answer you

I suspect there will not be one responsible person on their side. We will have to assemble a whole crowd, and working out who is responsible for each question is going to be difficult. We need a proper project kickoff to understand who owns what, and why they should answer us and disclose that information at all.

There is no documentation. They take no responsibility. You have to keep pushing them, managing the projects, and so on. On a banking software project that is not a complication at the edges. It is the shape of the work.

Design the work so it survives you

This is the part a buyer can act on, and it is worth asking a supplier for by name.

The first stage is discovery, and the important thing is that discovery creates an artefact you can detach. I say this to clients directly: I hope it will not happen, but if you decide to switch to another provider, it is still a useful document. It is not something you throw away.

The output should work in two directions at once. On one side you show it to the regulator. On the other, you pull whatever the service is missing into implementation. And it should be the minimum that is actually sufficient, not the maximum. You need someone who has done it before and knows how little you can describe and still be accepted.

The same test applies to the code. We are completely transparent with our customers. We work in your repository and we submit all the source from day one, so it does not mean you receive everything only at the end.

What honest timing sounds like

Nobody, and not only a bank, nobody can set a task in enough detail that you can sit down and program it.

You will see an increment every two weeks. But for the first month it is necessary to set everything up, so there is nothing to show in the first month.

Consulting must not run longer than three months. Nobody needs it that long. It is not that we start from the scope and then disappear for years. Whatever we can deliver in three months, we deliver. A long consulting project is always a stillborn product.

From zero to a first live mobile MVP with real clients, with fintechs and banks, is usually six to eight or nine months, depending first of all on how cautious the client is. Five months happened once, with a genuinely fast client. That is rare. And there are clients we carry for a year. That is fine.

A note on the numbers you have been shown

Our industry sells this work on failure statistics, and they do not hold up. There is no primary source for a bank-specific figure on how often these programmes overrun. The best evidence on IT projects generally runs the other way: Flyvbjerg and colleagues studied cost overruns across a large sample of IT projects completed between 2002 and 2014. They found overruns and underruns roughly equally common, and the median project on budget. The average is dragged upward by a long tail of a few catastrophic cases.

Most of this work lands somewhere near plan. A small share goes very badly wrong, and that small share is where the money is. The UK National Audit Office has published the anatomy of both kinds.

You cannot tell in advance which one you are in. So you buy the detachable artefact and the three-month ceiling as insurance against the tail.

Where the failures do cluster once the work starts is a separate question, and we wrote it up separately: core banking transformation fails in the seams, not the ledger.