The Concept Paper for a New Product: The Kickstart of a LPPD Project

Lean product and process development is not an easy undertaking, neither to understand nor execute. The concepts, tools and practices are often found to be technical, complex and counterintuitive, making it a challenge to launch new initiatives.

Luckily, there is a tool that can help remedy this ever-common problem: the Concept Paper.

“As more companies engage in the transformation of their product development system and the whole enterprise using the Lean Product and Process Development (LPPD) approach, there is a need for better understanding of some of LPPD’s key practices,” writes Jose Ferro of Lean Institute Brazil in his new white paper on concept papers. “One important yet frequently overlooked tool is the concept paper, a fundamental mechanism to kickstart a new project. This article will present the concept paper, define its purpose, outline its main content elements, and explain its importance to a LPPD transformation.”

You’ll learn:

  • The purpose and importance of the concept paper in a LPPD transformation
  • What a concept paper must consist of in order to be most effective
  • Who should be given responsibility for writing and presenting the concept paper
  • The process for studying and researching all of the information and data necessary for writing
  • And more.

Read the whitepaper here.

Michael Ballé, Jim Morgan, Durward Sobek featured in MIT’s Sloan Review

Skilled people, not processes or new tools, create great products, according to an article on innovation by Lean Enterprise Institute researchers appearing in the Spring 2016 issue of MIT Sloan Management Review. “Why Learning is Central to Sustained Innovation,” by Michael Ballé, James Morgan, and Durward Sobek II, is part of a special report on product development.

For your convenience, we have licensed the article for download for a limited time.

According to the authors, evidence shows that people and people systems are the most important parts of a product development system, because people generate the knowledge necessary for innovation in new products, new manufacturing systems, and more robust supply chains. The authors recommend that companies ask three fundamental questions to improve developers’ skills and capabilities.

Forward-Looking Companies Attend LEI’s Lean Product and Process Development (LPPD) Open House at Summit Week 2017

Forward-Looking Companies Attend LEI’s Lean Product and Process Development (LPPD) Open House at Summit Week 2017

A wide range of industry participants came together on March 6th, 2017 in Carlsbad, CA the day before the annual Lean Enterprise Institute (LEI) Summit to learn about product and process development. Invited representatives came from a variety of industries, including medical devices, healthcare, mining technology, golf equipment, digital printing, and others. The audience actively engaged with key thought leaders and case study presenters as part of showcasing LEI’s Lean Product and Process Development (LPPD) initiative. Duplicate morning and afternoon half-day sessions were organized to provide flexibility for the attendees.

Introductions & Survey Themes with Eric Ethington

Eric Ethington, program manager for LPPD with LEI, kicked off the open house with introductions and an overview of the agenda. Eric reiterated that the purpose of the LPPD program was to focus on changing the way new value is created. Prior to the session, each participant was invited to complete a voice of the customer survey with two questions being discussed at the session:

  • What is your definition of LPPD?
  • What are key success factors for successfully applying LPPD thinking in your organization?

With the first question of LPPD definition, many of the responses were around two themes: process and customer-focus. Scott Schmidt from US Synthetic responded that a “declared process is tough for many organizations to follow in LPPD.” Dr. Jack Billi and Dr. Ted Lawrence from Michigan Medicine reiterated that the customer (patient)-first theme resonates in healthcare.

For key success factors, the trends were leadership priority, culture change, PDCA cycles, structuring the organization, and getting the knowledge. Dr. Billi commented that knowledge is not enough for success, as evidenced by the survey results. In addition, Eric Ethington stressed that there were many “people” elements for success, yet we do not strongly acknowledge this in our definition typically.

The Ford Story & Experiences with Jim Morgan

Jim Morgan, Senior Adviser for LPPD with LEI, next shared his experiences with LPPD and Ford’s product-driven revitalization that he helped lead. Over the course of 45 minutes, Jim summarized the key points of the eleven-year journey that Ford took in the LPPD space under his guidance.

Development typically drives 70-80 percent of committed costs and quality for a new product, which is why it is a competitive advantage to find success in LPPD. In addition, it engages the entire enterprise and creates your future. During the late 1990s / early 2000s, people were starting to notice Toyota’s success with LPPD because their development times were 50 percent lower with 33 percent fewer resources and the highest profits per vehicle in the industry.

When people studied the Toyota development system, they found it was foundational for Toyota’s Production System, plus it was a disruptive model for continuous product development versus the traditional automotive industry model of “batching” model releases. The basic principles of LPPD include people, process, and tools. People and learning are at the heart of LPPD. Every time you develop a new product, you are creating knowledge.

The Ford story that Jim shared began in 2005. At that moment in time, the company was on pace for a $17 billion annual loss and was in its twentieth year of a steady market-share decline. The company was losing money on every car that it produced. Customer satisfaction was the worst in the industry and the stock was hovering at a distressingly low $1.90. There was a culture described as “cage-fighting” with massive layoffs occurring to offset the shrinking volumes. In 2006, Ford brought in Alan Mulally to lead the company after being CEO at Boeing. Mulally summed up Ford with the statement, “I was right—Ford’s problems weren’t as bad as Boeing’s. They were much worse.”

Fast forward eleven years, the turnaround that was reached based on the product-led revolution was dramatic—industry-leading customer satisfaction, $9 billion in annual profits, $15 stock price, and hiring of new employees. A key decision was Ford leadership securing $23 billion in loans in late 2006 before the credit markets later seized up in 2008. The leadership invested in new product, not spreading the money to poor existing infrastructure or programs that were not core to the future. The goal was to “create products that people actually want”.

People: The Best People Create the Best Products

In order to develop products that customers actually desired, the new global development process at Ford focused on not just developing products, but simultaneously developing people. Ford evolved their development organizational structure to support this vision, eventually settling on the product-focused matrix. A chief engineer had full responsibility for a product from idea to post-launch in this new structure. Groomed to be super engineers and superb leaders, Ford found it difficult to find and develop chief engineer candidates, but worth the effort.

Chief Engineer & Supporting Organizational Structure for People Development

Within the product-focused matrix, each function had an integration leader that was dedicated to the program (F-150, Mustang, etc.). In addition, there was an assistant chief engineer (ACE) that was being developed for possible future chief engineer role. The ACE would support regional development work. “A Faster Horse” available on Netflix tells the story of the development of the 2015 Mustang and the chief engineer at Ford.

In this structure, the functional leader’s job is to make the chief engineer successful. The chief engineer owns the “what,” and each functional leader owns the “how.” As Jim noted, “organizational software trumps organizational hardware,” meaning the behaviors and interpersonal relationships drive the success. And one yardstick for measuring success is product award recognition.

As for individual people development, prior to 2005, Ford typically hired engineers from the best, top-ranked engineering schools. Once hired, there was not much personal development, but rather a tendency to move around to get promoted faster. This eventually led to limited technical depth at key levels. One countermeasure in order to build “towering technical competence” was crafting technical maturity models (TMMs) that were plans for individual development. As Jim noted, most technical skills are “tacit” not explicit, so there needed to be a deliberate, intentional plan to develop the expertise.

One participant asked Jim how an organization could develop a chief engineer. The first step could be acting as the integration leader for a function (functional “chief engineer”). The second step could be as project manager for the chief engineer (“keep the trains running on-time”). The third step could be as a regional assistant chief engineer (ACE), with the fourth step as a possible chief engineer. Some companies start out with a Commercial Leader and Technical Leader (matched pair) that share the chief engineer role since it is difficult to start with one person with the appropriate skills and experiences.

Design reviews are another key people-development aspect of LPPD. Design reviews can be cadenced or event-driven (product-level) and led by the Chief Engineer. The purpose is to make it safe to surface problems with the development program to help improve the product outcome while also developing people. In addition, it improves the leaders’ knowledge. Design reviews should focus mainly on the current issues or teams will run out of time each review session.

Another participant asked how a design review would look in an LPPD organization. Jim recommended limiting (“outlawing”) typical presentation materials, while focusing on data and direct evidence. Hold the reviews outside of conference rooms and in the “gemba” (Japanese for “actual workplace”), whether that is at dealers, tool rooms, model shops, etc. Surface real problems…and get them solved—this will increase the interest and attendance, while minimizing other unnecessary meetings. Allocate enough time to discuss conflict and risks so leaders can prioritize the right actions.

Extended Enterprise

The development of people does not just stop within the internal organization. Supplier content made up about 50-60 percent of Ford’s end products, making it critical to work more proactively with key suppliers. Within six years of engaging more closely with the supply base, Ford’s overall supplier quality levels went from worst to third-best in the industry. Some ways that Ford worked closer was by matching up key pairs of engineering and purchasing leaders (matched pairs) to support longer term relationships, to experiment with expanded commodity plans, and to visit supplier gemba locations on a planned cadence.

The Process Components for LPPD

Jim next introduced the three components of the LPPD process: Study (“kentou” in Japanese), Execution, and Reflection. The Study phase is the most important since the challenge is to find and create the right product. Voice of the customer, immersion, concept paper, set-based concurrent engineering, and other techniques of LPPD are found in this phase. Jim also cautioned the group and quoted former basketball coach Johnny Kerr in that “if you listen too much to the fans, you end up sitting with them.” The Concept Paper helps compile a vision for the product from the mind of the chief engineer after gathering wide input. After incorporating this input and communicating it out, the Concept Paper then serves to align the organization, and then ultimately becomes a contract for the product success.

A core element of the Execution phase includes process milestones. The milestones are not treated as traditional “gates,” but rather to provide functional integration points to determine normal from abnormal for progress. Milestone points need to have clear purpose statements and quality of event criteria in order to synchronize all the LPPD activities. Compatibility before Completion (CbC), Digital Pre-Assembly (DPA), Perfect Drawing Plans (PDPs), and other techniques of LPPD are critical in this phase. The Reflection phase is capturing the key learning to embed into the next cycle of development.

TechnipFMC Schilling Robotics: A Brief Introduction to their LPPD Experience

David Furmidge, product development manager, shared the learning and experiences that the Schilling Robotics division of TechnipFMC has had as an LEI LPPD Learning Group member with their Gemini development program. Jeff Fritts and Hannah Waldenberger also joined with David to share the learning. Gemini is a remote operated vehicle (ROV) for the subsea oil and gas industry. The innovative new design greatly enhances the productivity of the tool changes, leading to a competitive advantage for the product that traditionally costs up to $1 million per day for customers.

Hannah Walderberger – TechnipFMC Schilling Robotics

David discussed two areas where the Gemini team started experimenting with concepts with LEI’s LPPD coaches—Post-Launch Design Changes and Late Product Launch. For Post-Launch Design Changes, the concepts were A3 problem solving, obeya/visual management, and strategic planning. For Late Product Launch, the concepts were set-based design, trade-off curves, question mapping, high-tech anthropology (HTA from Menlo Innovations in Ann Arbor), storyboards, product roadmaps, and product development value stream mapping (PDVSM). David shared an assessment of each of the experiments with the concepts. In reflection of the activities, the 2016 goals were met two weeks early, which was a critical success for the new Gemini product.

LPPD at LEI with Eric Ethington

Eric Ethington provided an overview of LPPD at LEI for the last part of the session. LEI’s LPPD program is made up of four initiatives—Learning Group, Research, Education, and Community. The program began in early 2015 with Jim Morgan with a couple of partner organizations. His vision was to create a learning experience that could not be rivaled by any one conference or event. Since then, the LEI LPPD team has expanded with an additional four coaches supporting learning group partners Herman Miller, Bose, TechnipFMC (four sites), GE Appliances, Michigan Medicine, and Honda R&D.

Eric Ethington, LEI LPPD Program Manager

Eric focused in on the levels of engagement that an organization can have with LPPD at LEI, starting with monthly newsletters all the way up to co-teaching partner in the learning group. Eric also showed the unique learning model that the LPPD coaches and the learning -group partners use together.

The outreach event concluded with a question-and-answer session with Jim Morgan and John Shook, Chairman and CEO of LEI.

Enabling Fast and Innovative Product Development at Bose

Product and process development is how new value is created through delivering great products that meet customer needs with profitable value streams. The decisions made in product and process development have an outsized influence across the entire value stream. The faster an individual or organization can learn, the greater the knowledge available is to make better decisions, and/or the quicker decisions can be made. This enables products to get to market faster and start providing customer value.

Indeed, Toyota founder Kiichiro Toyoda said this about the importance of rapid learning: “We are going to build cars. Let’s all learn as much as we can, and work together to create something our customers will buy. My job is the same as yours: to learn as fast as I can.”

LEI Lean Product and Process Development Learning Partner Bose Corporation sees the value in enabling rapid learning and created a “Rapid Prototype Development Center” at its Framingham, Massachusetts headquarters. Its goal was to enable fast and innovative product and concept development. Now LPPD coach Katrina Appell tells the story of the RPDC and the benefits Bose is enjoying from it.

You’ll learn:

1. How the RPDC is providing Bose with a competitive advantage.

2. How the design of the RPDC enables higher levels of creativity, greater collaboration, and increases employee engagement.

3. Specific examples of the tangible benefits realized through the RPDC.

4. How Bose is learning through the LEI LPPD Learning Group while continuously improving rapid prototyping capabilities.

The case study may be found here.

What are the key traits I should look for in a potential Chief Engineer? A Q&A with Katrina Appell

What are the key traits I should look for in a potential Chief Engineer?

The answer to that question depends on what your expectations are for a chief engineer:

  • Do you want someone with deep technical expertise in a domain, as the term is commonly used in many organizations?
  • Do you want a system integrator, which is more in line with the role as practiced within lean product and process development?
  • Do you want someone that deeply understands what the product must be, which is also in alignment with the role as practiced within lean product and process development?

Even more important to ask: Why do you want a chief engineer? What problem(s) will a chief engineer solve for your organization?

The chief engineer as practiced within lean product and process development (LPPD) is a countermeasure to problems that are both inherent to developing products and to the organizational design in which it is used.

For example, the fundamental purpose of product development is to develop a product that customers will value, which is likely solving a problem the customer has. And in most organizations this needs to be done profitably. The chief engineer system is a key part of understanding what the product needs to be for the customer and the business.

The chief engineer system is also a countermeasure to problems that occur in companies that are organized functionally. Functional organizations can be great at developing deep technical expertise. But they also run the risk of contributing to sub-optimized products if each function optimizes within their function. You could have the best technical design, but if it can’t be manufactured or sold profitably those are major problems for the product and organization.

To overcome the problems inherent in a functional organization, another common organizational approach is to organize around the product. This organizational structure can be effective for cross-functional collaboration and optimization at the product level, but often results in a lack of focus on developing deep technical expertise. The problems this causes become more evident as years go by.

Organizations sometimes flip back and forth between being organized by function and by product as each organizational structure solves the problems of the other one. The chief engineer system is one approach to get both the benefits of deep technical expertise within functions and optimizing the product to meet the customer and business needs. The chief engineer system might be the right approach for your organization, but have you considered others?

In the chief engineer system, as typically used in LPPD, the organization is organized functionally. The chief engineer, with support from a small team, has full responsibility for the success or failure of the product. This doesn’t just include development, but ultimately the profit and loss for the product and everything else that encompasses as well.

In this system the chief engineer has full responsibility without authority over most people working on the product. Each function’s role is to support the chief engineer to be successful and to develop people’s technical expertise within the function. In this system the fit between the chief engineer and the rest of the organization is what is important for success. If you have a mature functional organization experienced in working this way with a new, inexperienced chief engineer, the functional leaders can help develop and support the chief engineer to be successful.

And then there is the organizational-change aspect to consider. Organizations are a collection of people and both individuals and the organization are or should be constantly changing – hopefully growing. When you make a change in one part of the organization, the rest of the organization reacts to it. If you introduce a chief engineer into your current organization, how will the rest of the organization respond? How do you want the rest of the organization to respond?

Mutual trust and respect between the chief engineer and the rest of the organization are a good starting point to set the conditions for success. What other traits are needed to get engagement and support to make the product successful with no authority? And given your current organization and what you expect a chief engineer to do within it, what are the key traits that individual needs to be successful?

What’s a good “small step” to start off my LPPD transformation? A Q&A with Katrina Appell

What’s a good “small step” to start off my LPPD transformation?

Visual management (VM) is a great place to start your lean product and process development (LPPD) transformation, especially if you have prior experience using VM. A VM system works the same in LPPD as it would in manufacturing or any other environment. And if you don’t have experience with VM it is a great place to start any lean transformation.

There is tremendous value in making things visual – a picture is worth a thousand words. When things are visual, everyone is able to see the same information, which helps to ensure that everyone really is on the same page. This is especially important in knowledge-work environments, such as LPPD, in which the work is hard to see. Visuals become even more valuable in a management system, as you can create one for anything that has a plan or standard – schedule, budget, resources, quality, knowledge gaps, etc.

Visual management is a great first experiment with lean as the benefits can be seen relatively quickly – good news for results-hungry management. You can create a daily or weekly cadence to identify and solve problems. A short cadence also enables more PDCA cycles in your LPPD transformation, which helps build momentum. As with any lean method, your experiment with VM should be connected to a problem. The type of problem(s) you need to solve should influence what comprises your first VM experiment(s). If you are working with a constrained resource, such as lab testing, that might be a good place for an experiment. Or if you need to manage a product development project, obeyacould be a great experiment to start with.

When creating a VM system to address your problem(s) important components to include are:

  • Tracking actual versus plan
  • Identifying problems – when actual deviates from the plan
  • Effectively communicating problems
  • Effectively responding and solving problems

677_large

Image above:

  • Cool mint green: On schedule, no work in process
  • Dark green: In process
  • Dark green with check mark: Complete
  • Yellow: Risk identified, team working on a resolution
  • Red: Risk identified, resolution requires outside/management support

This actually might not be easy, but it is easier to learn on a small scale with rapid PDCA cycles connected to real problems than to learn lean thinking through larger scale experiments. Lean is fractal and your visual management system should address the questions in the lean transformation framework:

  1. What is the purpose of the change–what true north and value are we providing, or simply: what problem are we trying to solve?
  2. How are we improving the actual work?
  3. How are we building capability?
  4. What leadership behaviors and management systems are required to support this new way of working?
  5. What basic thinking, mindset, or assumptions comprise the existing culture, and are we driving this transformation?

As you address these questions in your VM experiments you are building a foundation of lean thinking in product and process development, which can be expanded upon as you start experimenting with other LPPD methods.