The year was 2005. A large mid-west manufacturer was attempting to implement a large ERP system. The first implementations were in the order entry and finance sections of the company. Things moved along fairly smoothly, but then the company attempted the first manufacturing plant, converting the old legacy system into the new ERP system, SAP (from the German company … Systeme, Anwendungen und Produkte).
The first manufacturing plant took 20 months from start to finish and followed traditional phase gate or a waterfall system of development in which each phase had to be completed before the next could start. In the 20-month SAP implementation for the plant, the team spent nearly 3 months gathering requirements prior to starting the development and then, and only then, embark on a massive customization of the system. This meant that no custom code linking the SAP system to other business systems was written until the requirements phase was completed.
When the system was unveiled, 16 month after the start of the project, the users in the plant immediately pointed out that it did not work the way they thought it would, and it did not meet all of their business needs. IT, for their part, insisted they had built the system exactly as the users told them it should work at the requirements gathering stage.
Needless to say, the management team responsible for the implementation of this system was not pleased. Nearly a dozen plants needed to be converted to SAP, and at 20 months each, the entire project would have taken a decade.
Exit waterfall development. Enter lean development techniques for IT systems.
When the teams looked back on the process and analyzed the approach (using value stream mapping techniques), they found that their efforts contained as much as 80% rework because, although the initial requirements were very thorough, they had not anticipated all of the discoveries that were made later in the process. And because the users were not consulted during development, many nuances of their process and techniques were not accounted for in the new SAP system.
The failure of traditional techniques triggers the motivation for change and lean development techniques.
Lean development principles were brought in and taught to the team. Rapid learning Ccycles were used to break the large project into smaller learning events. At the start of each learning cycle, the teams discussed what they needed to learn, and set-out to work on just that set of learning. Users were included in these events as well, thus sharing new requirements as the learning cycles progressed. In each learning cycle, testing and user reviews helped the teams build the system module by module.
Lean development breaks down large projects into smaller pieces.
The whole project was chunked into a half-dozen rapid learning events. Each one was 30 days or less. This let the team create lean flow within the team, and it reduced flow interruptions.
At the end of each learning event, the knowledge gained was reviewed with the whole team and with management. The sharing of knowledge is another important element of lean development.
Lean development practices knowledge capture and sharing.
From the initial failure of SAP development, the team quickly recovered by apply lean principles for the design. They implemented the next plant in a little over 8 months, cutting the time by more than 50%.
Lean development efforts typically finish in 50% less time with improved quality.
The team was complimented on their success, and lean development quickly become the standard for all the subsequent plant SAP implementations. As the team moved on, they standardized on the design methods for IT development.
You can read the whole story, and many others, in the book Innovative Lean Development on Kindle or in book form. Or, better yet, ask us to talk in person to your IT organization about lean techniques in software and system development.