change – Allan Kelly

Is AI repeating the historic mistakes of BPR?

Agile / allan kelly / March 17, 2026 / ai, bpr, change, technology change / Leave a Comment

Back in my coding days I worked on a death-march. Six days a week and on the seventh carried a pager. The aim was to redesign the way British Railways operated. Now everyone in the UK knows how that story ended.

While politically driven it was also a case of Business Process Reengineering – BPR. It was aggressive, IT lead and became synonymous with expensive failures.

It started with some very clever (i.e. well paid) people saying “Look at the way this company operates, with new technology you could do it so much more efficiently.” The mantra was “Don’t Automate, Obliterate.” This was more than just restructuring, it was creating “Leaner and Meaner” companies.

It went beyond individual process. It meant rethinking the way the whole company operated. My railway programme was not just about selling the industry, it sought to reimagine how trains operated: companies would run trains on the same routes just a few minutes apart and compete on price.

Expensive failures

Many, probably most, BPR efforts were expensive failures. It might be easy to flowchart a process but doing so often missed vital elements. Employees tacit knowledge which made things work was overlooked. Programming a business process the way you programme a computer ignored knowledge, experience, needs and variability of people. BPR programmes used unproven, scaled and stretch technology to a degree not done before.

BPR programmes laid off vast numbers of workers before they were finished. Many of these where hired back later when the BPR effort failed, like at British Railways.

The overworked and under valued staff who weren’t laid off had to pick up the pieces. The new systems frequently didn’t work and complaining about them was not well received. (It was against this background that the British Post office and Fujitsu started the Horizon system which would see staff put in prison and commit suicide.)

Is AI repeating the mistakes of BPR?

Which makes me ask, are companies repeating the mistakes of BPR in their rush to AI?

Like BPR, AI is being driven by technologists. Rather than start with the business need it starts with technology. How is less clear, there is much hand waving. The technology is cutting edge and by definition high risk.

Rather than showing staff how AI can make their life better, staff are being forced to use AI whether it makes sense or not. Complaints are not welcomed and there are frequent examples of how AI creates problems – like at Amazon.

The attitude to workers and aggressive language is very reminiscent of BPR. Some companies claim to be laying people off because of AI and almost everyone seems to be worrying about the prospect of AI redundancies. That is not conducive to successful change.

Tacit knowledge is being ignored again

LLMs only work with explicit knowledge: that which has been written down. If it hasn’t been written into words then LLMs don’t know it. Nor does it hold any kind of philosophy or design of how things should be done. AI might write something good today but what provision is it making for changes tomorrow? Humans are still needed to guide intent.

Before anyone says: “LLM have read millions of books so they have fewer blind spots” let me point out that there is very little written down about how YOUR company actually works. Even if you have a service manual or a standard operating procedure you may well find that people use considerable ingenuity in making the standard process work or finding ways to get work done despite it.

Most AI is a solution in search of a problem.

Most people do not spend their days writing documents, neither do most people spend most of their time reading. That an LLM can write a document is another example of a technology dog walking on its hind-legs. Clever but what use?

Get away from these “party tricks” and you find AI systems – like IT systems before them – need to work with the people, processes and systems that are already there. In time AI might replace these as well but today you have the people you have, the processes you have and the legacy systems you have. Changing more increases risk.

Thus Anthropic, OpenAI and friends are not going to replace SAP, Sage, Microsoft, SalesForce, or the other corporate applications any time soon. The remaining people would need retraining, other systems would need to be integrated, formal contracts and terms and conditions might need changing. Before that, sales need to be made, which means to salesperson needs to displace salesperson. The risk of introducing a new ERP system is enough to make any CEO reach for the whiskey.

Learning from BPR failure

BPR never really went away, it was moderated and became BPM – business process management – and BPI – business process improvement . We in the IT profession learned to work in small steps, integrate feedback, let business and users drive, and to manage the change with employees rather than bludgeoning them.

AI will probably take the same route. Right now the vendors have an incentive to hype it but in time – and perhaps with some high profile failures – things will moderate. Companies will remember that AI is a technology, and technology needs to be applied to a need. In time processes and companies will change but it won’t happen overnight.

Subscribe to get Allan’s thinking in your mailbox (+ free book)

Is AI repeating the historic mistakes of BPR? Read More »

All agile initiatives are flawed (and thats good)

If I may paraphrase the late Madeleine Albright: “What really troubles me is that agile is getting a bad name because it is identified with imposition and occupation. I’m for agile, but imposing agile is an oxymoron. People have to choose agile, and it has to come up from below.” (Albright was talking about democracy not agile, if like me you associate agile with democracy the sentiment is no surprise.)

I’ve spent much of the last 20 years helping companies and teams adopt agile. A lot of people are cynical about agile today but I still see benefits. A lot of the cynicism comes because all agile initiatives are flawed – every single one.

Whether you call it agile transformation, agile initiative, agile change or simply agile adoption all are flawed. While I like to claim success for many of the companies I’ve worked with I also see flaws in my successes.

Some agile transformations are flawed in conception. I’ve worked on a couple of these and find them soul destroying. Typically change driven from the top, a big consultancy is probably involved, there may be a roll-out plan and success is measured on some kind of “maturity assessment” – are you doing stand-ups? do you have a product owner? is your backlog burning down?

These kind of agile transformations focus on “doing agile” rather than being agile and achieving agility. I feel sorry for everyone involved but what are senior leaders supposed to do? Imagine you are the CEO of a legacy bank: you know agile is good, you know all the other banks are trying it, and you know digital transformation depends on agile transformation but what can you do? You have little choice but to call in a big consultancy and impose it top-down.

The other kind of flawed agile transformation is, to borrow a phrase from Amy Edmondson, “the right kind of wrong.” These are flawed by success, although it might not feel like that. It is hard to recognise and harder to live through. I’ve seen plenty of these too and, if I think about it, some of these flawed initiatives were my greatest successes.

Be agile to be agile

It is because agile transformations efforts are flawed that we practice agile. Agile is not the end state, it is the way you operate. There is no final, fixed, state.

It was Jutta Eckstein who I first heard describe agile as a problem detector. While some agile tools make things better as soon as applied them other help you see the problems you face. There might be an agile tool to help with the problem or you might need to fix it yourself. This is especially true at the level of the organization, Agile OKRs make this really clear.

Agile transformations which work well are flawed because success breeds success: each success lifts you higher and you can see more problems. A successful team will want to make more change. Remember by maxim: “The only thing you can do wrong in agile it doing it the same as you did 3 months ago.”

Before long successful teams find changes are needed beyond the team. Maybe the marketing department needs to forget about annual big launches, maybe the HR department needs to change bonus systems and so on. The successful agile teams sees the initiative as flawed because they need more.

At the same time, people in those other groups might be seeing the successful agile team and want to copy them. But because they face their own obstacles they can’t.

To those on the periphery of these teams – typically managers – this can look like conflict, tension, complaining, and even agile failure.

Whats happening here is learning: agile is learning. When teams are successful they don’t just learn about sprints and WIP limits, they learn what else needs changing to be more successful.

It is actually good that they see failure because failure is a great motivator for change. When something is a success why change? When something fails then fix it! Inside those problems are opportunities to be even better.

Agile OKRs

Which brings us to OKRs, and specifically Agile OKRs. One of the reasons, despite myself, that I like came to like adding OKRs to agile: because they open up new vistas to see and address problems, and thereby enhance agility.

I have been talking about OKRs as “just in time story generators” for some time, increasingly I see them as change drivers. Adding OKRs to agile doesn’t solve problems overnight, but it does make some problems clearer, like the run away backlog. Working with Agile OKRs means ensuring OKRs are set bottom-up, which demands that leaders are clear about strategy. Too often leaders aren’t clear about strategy – sometimes because they don’t have one. Agile OKRs allow us to address that problem.

The challenge is to keep the faith and keep working to fix your flawed agile transformation. It is in being agile that we become agile. Which is pretty much democracy.