Posted on

Michael Hammer & James Champy: Business Process Reengineering

Continuous improvement had been around for a long time. And that simply built on generations of work to improve the way businesses do things, going back to the Gilbreths and Taylor. But in 1990, a Harvard Business Review article exploded the idea of incremental change, with its provocative title: Reengineering Work: Don’t Automate, Obliterate. It was written by an MIT engineer called Michael Hammer.

And three years later, the revolution was well underway, with a book he wrote with top management consultant, James Champy. Reengineering the Corporation: A Manifesto for Business Revolution was as much a rallying cry for the consulting industry as anything else. But in the few years that followed, hundreds of companies employed thousands of consultants to reengineer their processes and, in so-doing, remove tens of thousands from their workforces.

Michael Hammer & James Champy
Michael Hammer & James Champy

Michael Hammer

Michael Hammer was born in 1948 and grew up in Maryland. He went to MIT to study maths, receiving his BS in 1968. He then took an MS in Electrical Engineering in 1970, followed by a PhD in Computer Science, that he was awarded in 1973.

He remained at MIT becoming a professor in the Computer Science department and also a lecturer at the MIT Sloane School of Management. From there, he formed links with a Boston-based consulting firm, Index, led by founder, James Champy.

In 1990, he authored one of the most influential Harvard Business Review articles,  Reengineering Work: Don’t Automate, Obliterate. This called for a radical approach to creating competitive advantage. It built on thinking that was already around among consulting firms like Index and Boston Consulting Group.

It was so successful that Hammer and Champy collaborated on a follow-up book that was hailed as one of the most important business books of its time: Reengineering the Corporation: A Manifesto for Business Revolution.

Other books followed, along with his own consultancy, and a commentary on the reengineering story as it grew, reached its peak, and then diminished amidst a certain sense of distaste. Hammer confessed to having been naive about the impact his ideas would have on people’s lives, once in the hands of corporations motivated primarily by profit for their shareholders.

Michael Hammer died unexpectedly in 2008, from a brain haemorrhage.

James Champy

James Champy was born in 1942 and studied Civil Engineering, also at MIT. He gained his BS in 1963 and his MS in 1965. He then went to Boston College Law School and received his JD in 1968. From there, he went on to found the consulting firm Index .

In 1988, Index was bought by computer systems giant Computer Sciences Corporation, and became known as CSC Index. Champy stayed on as Chairman and CEO until 1996.  He then went to lead another giant IT consultancy, Perot Systems, until 2009, when it was acquired by Dell.

Champy currently has a wide range of corporate roles, is an independent consultant, and research fellow at the Harvard Advanced Leadership Institute.

Business Process Reengineering (BPR)

A company can get competitive advantage if it can improve its customer service or reduce its operating costs. Continuous improvement methodologies like time and motion studies, and the Japanese Kaizen, had done this for years. But reengineering is a methodology for rebuilding the way a company does things – its business processes – from scratch.

In particular, it emphasises removing whole processes that do not deliver value. The result of this radicalism was obvious in hindsight, though not what Hammer and Champy intended. Companies not only reduced the scope of processes and found significant shortcuts; they removed whole cadres of staff who had previously carried out the tasks that were no longer needed.

The two principle effects of the 1990s’ obsession with reengineering were substantial layoffs and redundancies (described by the now-infamous euphemism ‘downsizing’) and a bean-feast of highly paid work for armies of recently graduated consulting analysts at all of the big consultancies.

By the end of the 1990s, the reengineering bubble had burst, to be replaced by a second wave of technology enhanced cost-saving under the guise of another three letter acronym (TLA): Enterprise Resource Planning, or ERP.

Business Process Reengineering - Michael Hammer & James Champy
Business Process Reengineering – Michael Hammer & James Champy

Some of the Principles of BPR

We can get a sense of some of the principles of Business Process Reengineering from Hammer’s original HBR article. There, he said:

‘At the heart of reengineering is the notion of discontinuous thinking—of recognizing and breaking away from the outdated rules and fundamental assumptions that underlie operations. Unless we change these rules, we are merely rearranging the deck chairs on the Titanic. We cannot achieve breakthroughs in performance by cutting fat or automating existing processes. Rather, we must challenge old assumptions and shed the old rules that made the business underperform in the first place.’

The principles Hammer and Champy articulated included:

  • Organize around outcomes, not tasks.
  • Have those who use the output of the process perform the process.
  • Subsume information-processing work into the real work that produces the information.
  • Treat geographically dispersed resources as though they were centralized.
  • Link parallel activities instead of integrating their results.
  • Put the decision point where the work is performed, and build control into the process.
  • Capture information once and at the source.

What was clearly missing was a recognition that some changes were always going to be more impactful than others. If you fail to address the principal workflow constraints, or make too many changes, then the resulting corporate carnage can be detrimental. This is something Eli Goldratt had realised ten years earlier.

And whenever I think back to my times at a major international consultancy* in the late 1990s, I cannot help but be reminded of something another friend and colleague (Tony Quigley) used to say:

‘The alternative to incremental development is excremental development’

 


* I was involved in Programme Management, not BPR

Share this: