On the evening of Sunday 22 April 2018, a TSB customer in Hertfordshire opened his banking app to see how much he had spent at the pub the night before. His own accounts were there. So were three that belonged to someone else: a £35,000 savings account, an £11,000 ISA and a business account.
That weekend, TSB had moved its 5.2 million customers onto a new IT platform. The date had been the fixed point from the start. A review for TSB’s board later found that its new owner had picked the Sunday for the switch back in 2015, without detailed knowledge of what TSB needed, and that the habit stuck: choose the end date, then make the plan fit.
When the schedule is already tight and nothing else changes, holding the date means deciding what else will move.
A coin on a triangle
In 1969 a British project manager named Martin Barnes was teaching a course on controlling time and money on construction contracts. During one session, he later wrote, he made a point the course had left out. Managing a contract wasn’t only about cost and time. You also had to deliver what had been specified.
He sketched a triangle with time, cost and quality at its corners. Then, on the overhead projector, he moved a coin around inside it to show the three pulling against each other. “This concept really caught on,” he recalled. Later versions swap in scope, performance or specification for quality, and the shape became known as the iron triangle. The everyday version is a joke: fast, good, cheap, pick two.
The idea is simple. When time and money are already tight and nothing else changes, squeezing one means adjusting another. You might spend more to try to finish sooner, though money doesn’t always buy speed. You can cut features to stay on budget. Or you can keep the date, the budget and the full list of features, and let the quality of what you build absorb the difference.
It isn’t a law of physics. A fixed date can be perfectly achievable if there is slack, or if the team finds a better way of working. Scope and quality are not the same thing either, and three numbers are not enough to say whether a project succeeded. Researchers who study the triangle have pointed out exactly these limits. Its use is narrower and more practical: it makes people talk about the trade-off out loud.
The corner that gives quietly
Of the three, quality is the easiest to squeeze without anyone noticing. A missed date is public. An overspend shows up in the accounts. A test that never ran shows up only later, in front of customers.
That is what the TSB reviewers found. When the app failed its load test, the target was lowered, and the summary of results didn’t make the change clear. Testing elsewhere was squeezed in similar ways as the date approached, as the case describes.
Saying which corner moves
Imagine a bakery owner who wants an online ordering page live before a food fair three weeks away, on a budget of £2,000. The designer agrees to everything. The page goes live on time and on budget. On the first busy Saturday, half the orders placed on phones never reach the kitchen, because nobody tested checkout on a small screen.
Nobody lied. Maybe three weeks and £2,000 could have covered it, maybe not. Nobody checked. The plan had no time set aside for the testing that mattered, and nobody had said what the page must do at minimum before it went live: take an order from a phone and get it to the kitchen.
The triangle is most useful as a question asked early. Once one corner is fixed, which of the others is allowed to move, and who will be told when it does? A team that agrees to keep the date but drop the gift-card feature, or move the date, or pay for extra help, has made a decision. A team that keeps everything and quietly skips testing has made one too. It just hasn’t told anyone.
A dial for AI
With AI, the triangle can be a setting. Anthropic’s Claude models take an “effort” parameter. At high effort a model spends as many tokens as the task needs. Lower it, and the documentation says you are “optimizing for speed and cost while accepting some reduction in capability.”
Lower effort may reduce capability. It doesn’t mean every task gets worse, and higher effort doesn’t guarantee a good answer either. So the documentation’s advice is the TSB lesson in one line: step down to medium or low for routine work “once your evals show quality holds.” Evals are tests for the model’s output. Without them, the time and money you saved are easy to see. A change in quality is easy to miss.