Be among the first to get the latest insights from LEI’s Lean Product and Process Development (LPPD) thought leaders and practitioners. This article was delivered to subscribers of The Design Brief, LEI’s newsletter devoted to improving organizations’ innovation capability. Subscribe now.
At TechnipFMC Schilling Robotics, we make robots! But just as exciting is how we’ve begun to launch products more effectively by experimenting with Lean Product and Process Development (LPPD) principles.
The robots we make aren’t those of science fiction fame, nor are they college lab stunts. Instead, they are remotely operated vehicles (ROVs) and serve as the only credible tool to do work in the most remote place on the planet, the deep ocean. Our customers in oil and gas, offshore wind, science, and defense require products that perform in this hostile environment with exceptional capability, efficiency, and reliability.
Our most recent development, the Gemini® ROV, was intended to, as we say, “revolutionize deepwater productivity” — and would become our most technically advanced, integrated, and demanding product development to date. From a technology perspective, the product is impressive. We developed automation sequences, machine vision, advanced hydraulic control, sensor fusion, and big smiles on the faces of our users. These developments represented a huge stretch not only for engineering but also for manufacturing, quality, supply chain, and our services organizations.
We have a fantastic culture of super talented people and great leadership support. We also had decades of experience grinding out programs and doing whatever was necessary to deliver. We refer to this as “grit.” But we began to wonder if this reliance on determination was blinding us to better ways of working. Must every launch require herculean efforts? Or worse, what if you put in the effort, burned out the team, and still failed to get the product out the door? The more we thought about it, and as the program progressed, the clearer it became that the challenges of Gemini® would require a different way of working.
We decided to give some of the methods and practices of LPPD a try. In addition to many other benefits, LPPD offered us a more synchronized or coordinated way of working concurrently that is far less wasteful and brutal on our teams than past programs. Two areas where we saw the greatest benefits were in purchasing and manufacturing.
On major programs in the past, our supply chain team experienced two significant problems. First, our previous design release Process scheduled a single batch release of more than 2,000 parts on a single day. There was no way our relatively small supply chain team could handle that volume of releases at one time. Second, many of the parts (we did not always know which ones) had never been made before. Consequently, we had no idea how long it would take our suppliers to make them until we saw the designs, so we could not plan lead times. It was simply impossible for our small purchasing team to succeed with this huge design release curve and uncertainty.
For the first issue, the downstream implications of the batch release problem became abundantly clear when we value stream mapped prior program release performance. But mapping also showed that engineering was not completing all the designs on the same day, just working to a single release date. The supply chain and engineering teams worked together to agree to a common design release priority based on long-lead parts and scheduled a stagger in releases that flowed releases into the system on a regular cadence instead of overwhelming the supply chain team.
For the second issue, the unknown lead times of completely novel designs, the supply chain and engineering teams worked early in the program to understand which parts were most likely to fall into this category. For those parts, we proactively problem-solved using incomplete but stable data from our product prototyping rounds: supply chain looked for alternate suppliers, and engineering adjusted the release date if necessary. Addressing these issues before the critical procurement window was far less stressful for the entire team.
Previously, we waited until after production launch to do our first kaizen activities and develop our manufacturing cells. With the Gemini® program, we started when engineering was in their prototype round of development. This earlier start allowed us to give specific and meaningful manufacturing feedback when there was still time to incorporate it into the product design.
We also changed our kaizen process such that during the engineering prototyping rounds, we created prototype manufacturing cells (think cardboard fixtures and folding tables). Then, when the engineering design was finalized, we were able to complete the cell design more quickly than with our previous process.
Tying in the Enterprise
Finally, we leveraged our weekly cross-functional obeya meetings and milestones as an effective way to manage the work in real time. As with any program, things did not always go as planned, and these meetings enabled us to make changes on the fly in a coordinated and transparent way.
Positive Cultural Changes
In the end, developing the Gemini® was a tough program, and launching the product was a super challenging ordeal. Healthy doses of grit were still required. But what we did was turn the impossible into the possible. It wasn’t easy, but we now have a product in the field “revolutionizing deepwater productivity.”
Perhaps the more meaningful result is the positive change in people’s behavior. We watched techs giving design feedback, engineers flexing schedules to improve the loading of buyers, and a true enterprise-wide understanding of the flow of efforts that lead to shipment.
We have a long way to go, and I’m sure we could stand to dial back our appetite for pain. However, I certainly wouldn’t want to lose anything we’ve tried or learned by synchronizing workflows.