interview – in this q&a, the chief of transformation of oil and gas company technipfmc tells us about their experience implementing lean product and process development.
interviewee: allison weber
roberto priolo: what are the key differences between a chief engineer system and a traditional approach to new product development?
allison weber: in our experience at technipfmc, the focus of traditional new product development is on getting the technology validated, but not the entirety of the processes supporting the creation of the finished product. for example, you don’t perform an in-depth analysis of how feasible the manufacturing of the product is or, like in our case, you don’t validate the supply chain in the same way you do 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 lppd is known for. in traditional npd, you use concepts to select your design – essentially having to base your decision on “what looks best on paper”. unfortunately, as you approach the finish line and you get into the details of the engineering process, challenges inevitably appear. not with lppd. alan labes, former chief architect for our subsea 2.0 product, would have us detail all possible designs and even prototype them, to see how manufacturable they really were. i don’t remember one single design that stayed the same after we did that (we would typically combine the best elements from the prototypes we produced into the final solution). this way of working takes longer, and it feels like it costs more, but it is actually faster, in that it prevents mistakes, failures and corner cutting.
rp: interestingly, a chief engineer has the responsibility for a product, but not necessarily the authority over the team. what does that mean for his or her daily interactions? do you think that having a lean culture in place, creating a flatter organization where open conversations happen all the time, makes it easier to work with a chief engineer system?
aw: definitely. in a non-lean culture, hierarchy is everything. leading without authority is possible when your vision and your knowledge are so profound that people want to get on board with it, but that’s not always the case.
when we adopted lppd in 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 didn’t always go off well with people, but five years later, everyone is used to that kind of behavior, because they know it’s the best way to get information. so, leading without authority is certainly not easy, but you can work through it.
rp: from a results standpoint, what has lppd meant for the organization?
aw: we split up the development in two scopes – product and process. from the perspective of product development, which alan led, our strategy was to develop the subsea 2.0 system to be faster, cheaper, and better than 1.0. there was substantial product development necessary to achieve that and alan – rightly so – decided not to translate cost and lead-time into engineering deliverables. instead, we used as kpis part count, weight and size: we wanted to achieve half as many parts, half as much weigh and half as much size, and we wanted to overtake the exact same market. that made the concept phase seamless.
compared to the overall assembly of the whole portfolio in 1.0, we reduced the part count by over 75%, part size by 45%, and weight by only 30%. the main reason we struggled with the weight target, so much so that we eventually de-prioritized it, is that people were using it the wrong way, trying to do things that added cost for the sake of reducing weight.
when we got to the process side of development, as we developed a new configure-to-order process, we started to implement more cross-functional targets: lead-time to be 12 months and cost to be 25% lower. we looked at the gap we faced for each part of the product and started to figure out specifically what areas of it we wanted to attack first, with the result that our lead-time dropped from 24 months to 13 months.
rp: what are the main challenges of introducing such a system?
aw: one big challenge is governance. as we got close to the end of product development, when parts were being released and the project was being buttoned up, we had a lot of push-back from other areas of the organization that expected to take on the governance of the product. traditionally, they we would have, 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 solve problems to determine how to accomplish customer value without messing up our fixed and flexible parameters.
that same challenge existed in the process side of things, where the team had to protect their decisions around supply chain manufacturing, for example.
rp: what was your biggest learning about lppd over the past seven years?
aw: everything we do is about developing people and keeping them safe. being able to keep your product stable enables your and your suppliers’ manufacturing flow to also be stable, and that in turn means having the chance to perfect things and make the work easier for people, leading to work improvements (and to people being accountable for those improvements). the connection between product design and the people who do the work gets lost sometimes – it is twenty steps down the process, after all – but to me it is what it’s all about. without stability, a company culture based on accountability cannot be created. of course, it can take years to get there, so perseverance is key.
the interviewee
allison weber is director of flow control value stream and chief of transformation at technipfmc.