Don't just focus on the tool - failure of Best Practice Replication at Engico

---

Yesterday I blogged about the success of Best Practice Replication (BPR) at Ford.

BPR was such a simple idea, and Ford licences the software to other companies, so why should it not work everywhere?

And yet it didn't work everywhere.

Here, to balance the success story, is an interesting case study of how BPR completely failed at Engico, and how that failure persevered for 4 years. For me the most interesting sentence in the whole article is this one

"Under certain circumstances, failure can reinforce belief; one merely needs a good reason to explain the failure".

Here's what happened.

• In 1999, Engico read about BPR and said "we want that." BPR was seen as addressing varius problems related to silo working and resolution of common problems

• They attempted to licence the Ford BPR system. 

• Negotiations failed and they decided to build their own system

• The new system was launched, on a new platform rather than the existing Lotus Note platform, and supported by plans for communities of practice.

• For the innovators, the launch was almost ideological. "For them the “idea of BPT as such” was so powerful, so positive and so strong, that they fully believed “soon, everybody will be using the BPT process because it is so clearly the right thing to do”. Now, all that needed to be done was to launch the process".

• The engineers in the factories were not interested in voluntarily submitting best practices. "Their focus  lies firmly with their own organization…their own work with improvement. And they have their network, and they have their meetings via telephone…and they meet once or twice a year in this network. And they are probably satisfied"

• A German factory submitted several best practices, and then waited to see if others joined in. When they didn't, the German factory refused to submit any more. "Why should I waste my time on distributing my stuff, if I don’t get anything in return? Show me first of all that the others are submitting something."

• The users blamed several things - they lack of involvement in the design process, the difficulty of assigning value to practice improvements, and problems with the IT (which was unfamiliar, hard to use, and ran into connectivity and network problems).

• So the innovators decided to fix the technology, and in 2001 removed the IT tool for rework. At the same time the underlying IT platform was being revised.

• By 2002 there was a new version, but this had become more complex, and still did not work.

• Work continued. Deadlines slipped.

• "After struggling for nearly three years to get the BPT process underway by attempting to convince the process development managers out in the divisions to establish new communities, by obtaining a commitment from managers who had already established communities, by solving the technical difficulties, and by persuading the members of the existing communities to describe and submit their best practices through the system, to no avail, the innovators acknowledged towards the end of 2003 that the BPT project was a failure".

I think we can see several reasons for failure here. 

• The BPR approach did not help the workers by providing them with solutions, but added more burden. 
• The tool was rolled out as "the right thing to do" rather than a work aid. 
• The tool was seen as the solution
• The tool was too new - new platform, new technology, new processes. 
• When the tool was not met with the correct behaviours, the solution was "change the tool" rather than change the behaviours (probably because changing the tool was seen as the easier thing to do, and because of the ideological belief described above).
• Engico persevered with the tool for 4 years before giving up. The author describes this as "A Surviving Failure" (ie a failure that continues to survive) and sees the cause for this as the innovators' strong belief in "the technologies inherent goodness". He says

"The innovators were disappointed, but they did not give up. As is often the case in KM projects and innovation projects in general, they put the blame on the intended users and others who did not understand the tremendous benefits of using the new technology and/or technical problems. And when the technology resisted, when they encountered technical problems with the IT infrastructure – especially with the CoolSnake Intranet platform – the innovators argued that once the problems were solved, the BPT process would work, because the “idea of BPT as such was good” and in any case “had nothing to do with the IT system”. The BPT innovators were certain that once their machine worked, everybody would be convinced of its goodness. But, the machine did not work and therefore could not “convince anyone because of its good working order".