Roberto Priolo: What are the main differences between a Chief Engineer system and a traditional approach to new product development?

Allison Weber: Our experience at TechnipFMC is that the focus of traditional new product development is on getting the technology validated, but not on the entirety of the processes that support the creation of the final product. For example, you don't conduct an in-depth analysis of how feasible the production of the product is or, as in our case, you don't validate the supply chain in the same way as the development of the technology. Conversely, in a Chief Engineer or LPPD system, you want your development to validate as many elements of the process as possible, which is the best way to find problems quickly and learn from them.

The other difference lies in the set-based concurrent engineering approach that LPPD is known for. In traditional NPD, you use concepts to select your design - essentially, you have to base your decision on "what looks best on paper." Unfortunately, challenges inevitably appear as you approach the finish line and delve into the details of the engineering process. Not so with LPPD. Alan Labes, former chief architect for our Subsea 2.0 product, had us work out every possible design and even make prototypes to see how manufacturable they really were. I can't remember a single design that stayed the same after we did that (usually we combined the best elements from the prototypes we produced into the final solution). This way of working takes longer and feels like it costs more, but it's actually faster because it avoids mistakes, failures and cutting corners.

‍

Roberto Priolo: Interestingly, a Chief Engineer has responsibility for a product, but not necessarily authority over the team. What does that mean for his or her daily interactions? Do you think a lean culture, creating a flatter organization where there are constant open conversations, makes it easier to work with a Chief Engineer system?

Allison Weber: Absolutely. In a non-lean culture, hierarchy is everything. Leadership without authority is possible if your vision and your knowledge are so profound that people want to participate in it, but that's not always the case.

When we introduced LPPD to the Engineering team (it was 2016), from day one our Chief Engineers worked closely with our sponsor, a Vice President, who skipped a few levels of management to be close to the development work. That was not always in good taste with people, but five years later everyone is used to that kind of behavior because they know it is the best way to get information. So leading without authority is certainly not easy, but you can get through it.

‍

Roberto Priolo: What has LPPD meant to the organization from the perspective of results?

Allison Weber: We split development into two scopes - product and process. From the product development perspective, which was led by Alan, our strategy was to develop the Subsea 2.0 system faster, cheaper and better than 1.0. It took significant product development to achieve that, and Alan decided - correctly - not to translate cost and lead time into technical deliverables. Instead, we used number of parts, weight and size as KPIs: we wanted half as many parts, half as much weight and half as much size, and we wanted to capture the exact same market. That made the concept phase seamless.

Compared to the total assembly of the entire portfolio in 1.0, we reduced the number of parts by more than 75%, the size of the parts by 45% and the weight by only 30%. The main reason why we struggled with the weight objective, so much so that we eventually deprioritized it, is that people were using it the wrong way and trying to do things that cost extra because of weight savings.

When we got to the process side of development, as we developed a new configure-to-order process, we began to implement more cross-functional goals: lead time 12 months and cost 25% lower. We looked at the gap we were running into for each part of the product and started figuring out specifically which parts we wanted to address first, with the result that our lead time dropped from 24 months to 13 months.

‍

Roberto Priolo: What are the biggest challenges in introducing such a system?

Allison Weber: A big challenge is governance. As we approached the end of product development, when parts were released and the project was closed, we got a lot of opposition from other parts of the organization that expected them to take on the governance of the product. Traditionally, we would have done that, but we wanted to keep it close to the product and within the team, because we knew that's where the knowledge of the product lives. The team can problem solve to determine how to achieve customer value without confusing our fixed and flexible parameters.

The same challenge existed on the process side, where, for example, the team had to protect their decisions around production in the supply chain.

‍

Roberto Priolo: What have you learned most about LPPD over the past seven years?

Allison Weber: Everything we do is about developing and keeping people safe. If you're able to keep your product stable, the production flow from you and your suppliers can also be stable, and that in turn means you have the opportunity to perfect things and make the work easier for people, which leads to improvements in work (and to people being responsible for those improvements). The connection between product design and the people doing the work is sometimes lost sight of - after all, it's 20 steps in the process - but to me that's what it's all about. Without stability, there can be no corporate culture based on accountability. Of course, it can take years to get to that point, so perseverance is essential.

‍

THE INTERVIEWEE