You Can’t Manage a Secret

Takeshi Uchiyamada had a problem. He had just been named Chief Engineer for arguably the most revolutionary product in Toyota’s history. The goal for this program, initially identified as G21, was to achieve nothing less than 1.5 times the fuel economy of Toyota’s best small cars and develop it on an extremely compressed timeline. To make matters worse, Mr. Uchiyamada lacked the technical depth required to develop and commercialize the advanced hybrid technology that would be required. In fact, no single person at Toyota did. He quickly realized that he would need an unprecedented level of collaboration, transparency and speed of decision making to make this program a success.

Consequently his first pathbreaking innovation had nothing to do with engine technology. Recognizing that his job would be to effectively integrate the efforts of diverse experts and keep the project on track to achieve no compromise targets for performance cost and schedule, he created the “obeya management system.” In this system he met every two to three days with all required technical experts in a room in which all pertinent information was posted on the walls. This information was available to everyone on the team at any time. The G21, which the world has come to know as the Prius, went on to revolutionize the auto industry, dramatically raising the bar for fuel economy and leaving competitors years behind. And the obeya system, credited with making a major contribution to the Prius success, became a development staple at Toyota.

I first heard this story nearly 18 years ago while meeting with Mr. Uchiyamada during my research at the University of Michigan. At the time he was working with a team of Toyota engineers who were tasked with standardizing and teaching obeya throughout the Toyota development community. Obeya, of course, is a Japanese word for big room referring to the large open room required to house the functional technical experts required on the Prius program. Obeya, of course, is a Japanese word for big room referring to the large open room required to house the functional technical experts required on the Prius program.

The challenge to the Toyota team was to capture this powerful system for collaboration and transparency without the ability to co-locate all program teams.

They described the system basics as:

1) Engineers are not co-located. The Functional Engineering Staff Leaders meet with the CE on a varying cadence.

2) Paper-based visual management is the key to effective communication. The walls are plastered with important program information including information on design alternatives, test results, status to attribute performance targets, cost status, status to schedule, and supplier readiness levels. The team walks the walls at regular meetings and sub-teams meet there often between meetings.

3) The obeya location moves with the program. Starting in Engineering, moving to prototype and finally to the plant for launch, the cadence of meetings also change as the program progresses. Typically increasing in frequency to daily meetings as the program moves to launch. For a fuller treatment of both the Prius program and obeya history you can reference the Toyota Product Development System.

During my visits to Toyota City earlier this year I saw that obeya at Toyota has continued to evolve through careful PDCA. There were innovations such as adding CAD and simulation capability in order to facilitate real-time design discussions. But the heart of the system remains visual management and the intent to improve communication, transparency and cross-functional integration in order to quickly identify and solve problems.

Transparency and collaboration were also the essence of Alan Mulally’s message at Ford when he said, “You can’t manage a secret” (and I would add, “…and you can’t solve a problem you’re not aware of.”) He challenged us to increase honest, fact-based communication and improve cross-functional collaboration across the enterprise. One of the ways our team responded was with an “obeya system.” Obeya was not only used to manage program performance, but also to integrate cross-functional teams, as well as to help manage the global functional engineering business, in the creation of the global product development system (GPDS).

I was reminded of these experiences when our LPPD Learning Partner companies came together to learn and share their outstanding work in Davis, California last month. While experience levels and specific practices varied across companies, each company was experimenting with obeya and all reported performance improvement. Several teams reported “best ever” results. In our subsequent discussions we learned many nuances of how they were each leveraging the power of obeya. However, all of them found that the real benefits of obeya were in transparency, speed of problem resolution and team engagement.

So the next time you are tempted to get drawn into circular arguments about what metrics or graphs to share, where they should be placed in the room, or even if obeya should be spelled with one O or two (yes, I have actually heard that). Think about Takeshi Uchiyamada, Alan Mulally, our learning partner companies and the real purpose and power of obeya. Consider: how can you best leverage obeya to better engage your entire team and dramatically improve your performance?

PS:

 

Join us at the 2017 Lean Transformation Summit in Carlsbad, California! Eric Ethington and I will be sharing a variety of LPPD experiences as well as details on how the learning partnership works to accelerate your progress at a pre-conference Open House. Also, FMC Technologies, one of our learning partners, will sharing their experiences with LPPD in a breakout session.

We had a fabulous day at the University of Michigan Hospitals last week. Together we identified many opportunities to apply LPPD to improve patient-centered care and deliver ever-better value. This promises to be an exciting frontier for LPPD.

It was great to see the teamwork developing across our partner companies at our most recent learning event. Each company was sharing openly and supporting the progress of the others. Topics included our Chief Engineer concept paper, enterprise transformation, obeya and A3 for developing people. Our LPPD learning partner model continues to evolve and become more powerful. LPPD senior coach Matt Zayko will be writing up and sharing the event more fully on our site leanpd.org.

When Lean Gets Personal

I was dreading the next eight weeks. Multiple surgeries at the University of Michigan Cancer Center had finally rid me of most of the sarcoma cells whose discovery had so worried my family and completely upset my intense and demanding life as a Ford executive. But treatment wasn’t over yet, and I just knew the worst was yet to come – eight weeks of daily radiation treatments. In addition to normal treatment concerns, I envisioned forty very long days of searching for parking spaces, repeatedly filling out mind numbing forms, wasting away in crowded waiting rooms, inexplicable appointment delays and generally more frustration than Windows Vista.

But I couldn’t have been more wrong. My initial consultation put my mind at ease and I sailed through appointments experiencing a precise, efficient and ultimately successful treatment regimen that was patient focused and professional through every step. And this was no accident. It was the result of many months of lean work by Department Chair, Dr. Ted Lawrence, Director Kathy Lash and the rest of the Radiation Oncology team.

Together they used value stream mapping to improve flow and significantly reduce lead times. Their teams used rigorous A3 problem solving leading to root cause-based countermeasures and powerful standards and checklists that helped to create a consistent, high-quality experience for each patient.

And perhaps most importantly, they had leaders like Ted and Kathy who lived and consistently communicated patient-centered care from the patient’s first consultation to the department wide applause as patients ring The Bell celebrating the conclusion of their treatment regimen.

Following my cancer experience I had the privilege of participating on a team commissioned to further enhance the Center’s performance through a “patient centered care” initiative. Through this work we were able to support the dedicated professionals who worked tirelessly to find a “better way.” This experience allowed me to learn about all the great work going on more broadly in lean healthcare. But perhaps most importantly it enabled me to meet with other visionary health care leaders like Dr. Jack Billi, who gave the best advice possible to an engineer newly diagnosed with cancer (N=1) as well as incredibly talented administrators like Linda Larin, whose excellent book, Inspired to Change, is impacting the way medical professionals think about health care.

Additionally I learned that the very best health care organizations are thinking about how to be “lean” from the very start of facility and process design. Identifying how they can make step change improvement in patient-centered, health care performance through the application of LPPD principles and methods from concept development forward. In some cases, like Baris Lostuvali and Cathedral Hospital in San Francisco they are applying LPPD to the management of new facility construction. Others like University of Michigan, Akron Children’s Hospital, Stanford and Virginia Mason are going even further by involving both staff and patients through basic 3P techniques and designers in “seven ways” exercises up front in facility design and construction.

While much progress has been made, recent visits and discussion with health care professionals made clear, there is still tremendous opportunity.

Rapidly changing technologies, new interventions, shifting demographics, and constraining regulatory requirements are combining to create an ever more challenging and dynamic operating environment for health care providers.

An environment in which facilities designers, clinical designers and health care leaders will increasingly find themselves with significant product and process design challenges where the decisions they make may resonate for many years to come. One in which concepts, methods and tools from LPPD like improved design reviews, front loading, compatibility before completion (CbC), rapid learning cycles and the creation of new patient-centered value streams will be invaluable.

Will LPPD enable health care providers make the kind of dramatic improvements that it has done in other industries? I guess we’ll see. We intend to do the experiment. Because in addition to all the macro reasons that it is crucially important, in the end, healthcare is intensely personal.

I remain cancer-free, and my family and I are forever grateful to my surgeon Dr. Sybil Biermann, Dr. Ted Lawrence, Kathy Lash, Dr. Jack Billi, Dr. Kuzan and so many others at UMHS not only for their incredible professional skills, but for their willingness to explore, experiment and work to continually improve performance for the patients sake. And while my experience turned out well, remember here too N=1. There is still so much more to do and the work is so important.

Focus Your Operating System To Bring Your Strategy to Life

While I hear a great deal from companies these days about how their latest initiative will create greater “organizational synergy,” what I actually find is nearer to “organizational antagonism” where the performance of the whole does not equal anything near the sum of talent of its individuals. Well-intentioned leaders add new initiatives in the hope of tapping into unused human potential but then find themselves facing greater entropy because of the increased chaos the initiative creates in the system.

This was certainly the case when Alan Mulally arrived at Ford in 2006. At the time, there was no shortage of sophisticated initiatives designed to improve organizational performance. Nor was there a shortage of incredibly talented and hardworking people to carry out those initiatives. But those things together were somehow not enough to keep Ford from steadily losing market share, boatloads of cash, market cap and experiencing a chaotic downward spiral.

So what was the problem?

Every functional organization, every geographical organization, and even every program team seemed to have its own unique plan to fix the company.

In part, it was a lack of organizational focus. Every functional organization, every geographical organization, and even every program team seemed to have its own unique plan to fix the company. What’s more, we also lacked a comprehensive methodology for leveraging the capability of the entire organization to effectively move the company in the same direction. We lacked a focused operating system.

What’s more, we also lacked a comprehensive methodology for leveraging the capability of the entire organization to effectively move the company in the same direction. We lacked a focused operating system.

From his first day, Alan worked with his senior executive team to develop “One Ford” – the product-led revitalization plan that would align the entire enterprise. He initiated global functional organizations to better leverage capability around the world, he divested brands to increase leadership focus, and he worked to enroll each and every employee in the plan through effective strategy deployment and tireless communication. He consistently urged the team to take a “laser focus” on creating products our customers would truly value.

But he did much more than talk. He also created a powerful operating system that breathed life into the One Ford plan, leveraged the talent, changed the culture and moved the enterprise forward together. It was the operating system he created that animated the strategy and brought the company together to deliver.

In this context, an operating system is the cadenced management activities that move an organization toward its objectives in order to accomplish its mission.

Further, the system is a single, integrated system made up of interdependent parts. It is not a hodgepodge of departmental plans that do not hang together, or a string of episodic management interventions. An effective operating system is purposeful, transparent, multileveled and cascades throughout the organization, establishing clear, aligned roles and responsibilities in order to deliver the plan. It knits together, and drives, critical organizational value creating activities such as strategy deployment and continuous improvement, new product delivery, people development and working environment, manufacturing and supply chain. Finally the operating system provides its own performance feedback on how you are doing.

At the heart of Alan’s operating system was his Business Plan Review (BPR). Every Thursday Alan brought together all functional and regional leaders to review the business environment, progress on the plan and status of key objectives. Only new issues and changes from the previous week were reviewed. Alan worked hard to get issues out in the open by telling execs “We can’t manage a secret” and making it safe by assuring them that “You have a problem, you are not a problem” and setting the tone by saying, “The neatest thing about this process is that we are going to get back together next week and I know you will make progress by then.”

He also utilized Special Attention Reviews (SAR) for deep dives on particular issues. One example of this was during the Great Recession when a number of our suppliers (and two of our North American competitors) declared bankruptcy. We used SARs to align and coordinate activities across the enterprise in a rapidly shifting environment. For a fuller treatment of BPRs and SARs see Bryce Hoffman’s excellent book “American Icon.”

But to stop at Alan’s BPR level is to miss the point. The system was not limited to a small circle of the most senior executives – it permeated the entire enterprise. While my boss, John Fleming, EVP, attended Alan’s BPR, my colleagues and I attended his. In turn, my chiefs attended my version and their managers attended theirs throughout the company and around the world. We had the same plan, focused on aligned priorities and utilized the same format. If I had to attend Alan’s BPR to talk about an issue, I did not prepare new slide decks. I utilized the same thing we all used every week – just my level of detail was different. Tightly coupled with other key mechanisms such as design reviews, development milestone reviews and Matched Pair meetings, we created a powerful and cadenced operating system that brought us together and moved us forward as a global team.

I believe that this system was one of the most important elements of Ford’s historic, product-led turnaround. It clarified our priorities and focused initiatives, leveraging their interdependencies toward a common set of goals, (in our case, around creating products our customers would value). And most importantly it enrolled everyone in the effort.

An effective operating system brings strategy to life. It synchronizes critical activities, enables the organization to respond quickly to a changing environment and allows plans and teams to move together. What’s breathing life into your strategy, or is it just a collection of lifeless documents hanging from a wall?

Best Regards

Jim Morgan

 

PS:

LEI held their annual global meetings last week with their Lean Global Network (LGN) affiliates. Thirty-one people from 18 countries came together in Cambridge to plan their strategy for making the world better through lean in the upcoming year. We dedicated an entire day to LPPD and innovation by sharing developments in our LPPD Learning Partners and our fast-growing LEI LPPD community as well as planning for future LEI-LGN collaboration. We also visited with our friends at MIT D-Labs and the Cambridge Innovation Center. We have two large, joint LEI-LGN global projects underway with excellent partner companies and several more in the works. Energy and enthusiasm for LPPD continues to build around the world!

The folks at MIT D-Lab continue to do amazing work simultaneously educating students and bringing innovative products to underserved markets. Evaluation Manager and Researcher Kendra Leith shared with us how lean principles and methods are helping them to accomplish their crucial mission.

img_6025_720 kendra

We plan to further leverage the LEI-D-Lab partnership to both educate and deliver ever better value to all our customers.

Save the date! LEI is planning much more LPPD content in their annual Lean Transformation Summit in 2017. The event will be in Carlsbad, Cali. on March 7-8. Stay tuned for more LPPD-related details.

Orchestrating Your Product Development Process with Milestones

Effective milestones are an important part of a company’s development process, especially in today’s era of team-based sprints and stand-ups. Yet many companies struggle to successfully create and employ milestones; and some don’t even understand their relevance beyond updating senior leadership. In fact, the topic comes up so frequently in my travels that I thought it would be worth a slightly longer discussion than usual.

Well-designed, thoughtful milestones do a great deal more than just mollify senior leaders. Milestones can and should be like the sheet music that, along with a skilled conductor, aligns and guides your development orchestra. To that end, I’ll share some thoughts on the purpose of milestones, how to create useful ones, and a few tips on holding effective milestone reviews.

Milestone Purpose

Milestones, as the name implies, provide important information to the development team to guide them on their development journey.

1)  They provide a reference to determine normal from abnormal conditions: Milestones tell the team if they are on track so that they can decide how best to proceed, like the lines on the floor of an assembly-line workstation. In these stations, a set of yellow lines can indicate the percent of work to be completed at that point in time. If the worker is at the 50 percent line, and only 25 percent of the work is complete, he or she can pull the andon to signal for help. The

Milestones tell the team if they are on track so that they can decide how best to proceed

team leader can then come over to help fix the issue in station without disrupting the rest of the line. Of course, this system is worse than useless if the team identifies abnormal conditions but has no signaling mechanism, or if leadership does not provide real help to the team. (One example of leadership help in this regard is the cadenced design reviews discussed in my previous e-letter. However, the goal is ultimately to identify and resolve issues early and effectively – to shorten management cycle time and keep the project on course.)

2)   They act as key integration points: Milestones are an important part of synchronizing work across functional groups.  They should be designed to recognize key interdependencies between disciplines like software and hardware or design and manufacturing and provide common reconciliation points. To do this effectively you must understand both the tasks, and sequence of tasks, within each functional discipline. This detailed knowledge allows you to sync up work across those functions. This in turn lets you maximize the utility of incomplete but stable data to optimize concurrent work. The better companies get at this, the faster they can go. In fact, this synchronization is far more effective in shortening lead-time than attempting to reduce individual task time.

3)   Milestones are a critical component of a company’s development operating system. Senior development leaders typically have many different programs to manage simultaneously. They must have the ability to recognize issues, respond quickly and effectively to struggling project needs and make adjustments as required in the rest of the development factory. A project-health dashboard built from milestone feedback can be a powerful tool to enable this work if you have properly designed milestones.

Creating useful milestones

My experience here is that milestones, like most things in life, are just about as effective as you make them – both in terms of design and adherence. I’ve found that useful milestones share these qualities:

1) A real purpose: Start by asking yourself, “Why do we have this milestone?” You need to be able to create a clear, concise, product-oriented purpose statement. If you can’t, you should question the need for the milestone. Another way to think about this is, “What problem are you trying to solve with this milestone?” Milestone purpose statements should optimally be linked to the Chief Engineer Concept Paper and reviewed in the program kickoff event. It is also crucial that you align cross functionally on the milestone purpose statement.

2) Clear Quality of Event Criteria (QECs): Many companies create milestones based on activities or events.  While this may be necessary it is not usually sufficient. Just completing an activity does not tell you very much about the program status or health. For example, you may complete an early prototype build event, but have done so with component parts that are not the correct pedigree for design or manufacturing process level, thus rendering subsequent testing and learning spurious. You have not closed the required knowledge gap nor reduced risk to a sufficient degree.

By establishing QEC for the milestone, the team gets a more realistic picture of where they are really at in the development journey.

However, because the team completed the prescribed activity, they and their leadership might be lulled into a false sense of security. By establishing QEC for the milestone, the team gets a more realistic picture of where they are really at in the development journey.

Four things I like to think about in evaluating QEC: A) The QEC should be the critical few predictors of project success, not a wish list of every possible failure mode you can brainstorm. B) Is the requirement binary? C) If it can’t be binary, is there a quantitative range that can be established and measured, and D) If it can’t be binary or quantitative, is there clarity about who decides?

3) Clear roles and responsibilities: It is important that participants are aligned on who is responsible to do what at each milestone. The time to align on this is at the start – not when you reach the milestone.

4) Scalability: Not all programs are alike. Levels of content, complexity and risk can vary significantly across projects. Well-designed milestones can be reconfigured to best fit the program without losing their basic intent or effectiveness.

Milestone Reviews:

1) The first principle in milestone reviews is to support the team. Updating leadership is important, but the primary intent should be to provide help and guidance as required.

2) It’s okay to be red, but it’s not okay to stay red. “What’s your plan to green?” was a question I first heard from Alan Mulally while I was at Ford. While you want to drive fear out of these reviews, you don’t want to eliminate accountability. The team must deliver on commitments.

While you want to drive fear out of these reviews, you don’t want to eliminate accountability.

3) Define who should attend each milestone review. Some reviews require senior leaders, functional representation or particular specialists – others not. Consider the milestone purpose for guidance here.

4) Milestones are an opportunity for the team to regroup, align and sync up on the way forward. They should energize the team; not demoralize them. Leaders should look at them as a chance to “turbo charge” the team like the old Hot Wheels spin stations. The cars come out with much more energy than they came in with.

5) Hold the reviews at the gemba whenever possible.

I hope that you found at least a few of these ideas useful. So at the risk of overextending the orchestra metaphor, even the best musicians can sound like screeching cats if they are not playing from the same score. Can better milestones help your team play sweeter music?

Best Regards,

Jim

 

PS:

  • Our friends at the Lean Product and Process Development Exchange (LPPDE) will hold their North America 2016 conference on September 26-29 in Philadelphia. The agenda has been designed to create EXCHANGE and learning around key questions in the evolution of Lean Product and Process Development. Learn more at lppde.org.
  • Our next LPPD Partner Learning Event is scheduled for November in Davis, California at FMC’s Schilling Robotics Center. We are looking forward to another incredible learning experience. Stay tuned for details.
  • The 2016 Lean Process Innovation Summit was held at Mackinac Island on August 16 – 18. A great event at a fabulous location that shows the rapidly growing interest in LPPD! Can’t wait until next year.

The Crucible of Innovation

My quick survey of popular business publications seems to indicate that “innovation” may be the modern business equivalent of “abracadabra.” The short version is that with unfettered (even uninformed) imagination, absolute freedom from process, and of course a large enough supply of sticky notes, you too can hatch sufficient break-through ideas to fix nearly any business issue – especially if you can trek through the woods or scale a mountain (but make sure to bring extra sticky notes).

Forgive my facetiousness; it’s just this that kind of stuff drives me crazy! To be clear, there is no doubt that innovation is incredibly important. But there is a far more organic, seamless and effective way to cultivate creativity and collaboration in your organization. And it is likely a practice that you are already doing. It is also one that will help to create an ongoing development cadence and act as a powerful cultural transformation lever. I am talking about design reviews.

Design reviews are an oft-overlooked, even maligned opportunity for real-time innovation. But I’m not talking about what passes for design reviews in many companies. You know, the type that act as a poor cousin to a status review; “wirebrushing” people who identify issues and grilling engineers for design release-dates and tool starts. Or the pre-milestone “dog and pony show” type that serves primarily to give senior management a much desired, but usually false, sense of security. The ones where an engineer’s primary objective is to “get offstage” with minimal negative exposure and never violate the tacit agreement that if you don’t pick on mine, I won’t pick on yours.

Design reviews can be the heartbeat of your development project and a critical part of your overall development operating system.

Design reviews can be the heartbeat of your development project and a critical part of your overall development operating system. They provide a common link for distributed teams and are a primary mechanism for learning and doing, at program speed. Generally, I think in terms of two broad categories of design reviews. The first is a cadenced review used to surface and resolve technical issues in a timely manner. It provides a consistent, recurring forum with required cross-functional participants to work on inevitable technical challenges, thus preventing the waste of engineers chasing down much-needed help. The second type is system focused and scheduled in support of key integration events. These typically involve representatives from the entire development team, who focus on interfaces and interdependencies, and are scheduled such that sufficient time is allowed for post-review work without disrupting the program.

In either case, they should be challenging, rigorous and above all, alive and energizing. They should raise performance expectations for both the product and the team with the aim of making both ever better. This is not a “check-the-box” event; far from it. It is a demanding crucible of ideas – testing, challenging and improving. An event that generates both heat and light. It’s not a PowerPoint show. Participants should bring only those materials they are already using in development such as early prototypes, test data, simulation results, or CAD with perhaps a one-page problem statement. The events themselves should be held at the gemba whenever possible – this creates powerful dynamic. And importantly, problems are not an anomaly and real time learning is why you are there.

Design reviews are a tremendous opportunity for people development and cultural change. It is an opportunity for leadership to evaluate both design solutions and the thinking behind them by asking probing questions and actively coaching in real time. More importantly it is an opportunity for leadership to demonstrate those behaviors they expect from their teams such as collaboration, experimentation, rigor, detail and ultimate ownership. The environment is not punitive, in fact there should be far more pressure on leadership. It is about stretching the team, self-pressurizing to achieve more together than they ever could separately.

This is not a place for individual performance reviews or finger pointing. It is about working as a team to continually improve in order to deliver ever-greater value to your customer.

Although initially uncomfortable, your team will begin to thrive on these events, relishing the opportunity to engage and grow as engineers and leaders as long as leaders remember to ask tough questions and challenge ideas, but always support their people. This is not a place for individual performance reviews or finger pointing. It is about working as a team to continually improve in order to deliver ever-greater value to your customer.

Here are a few points you may wish to consider as you think about your next design review:

1)   Actively manage the agenda and scheduling. Make sure all the right people are there for the right discussions – and not present when they don’t need to be (wasteful). Also be sure to allow sufficient time for in-depth dialogue on topics. Event-driven reviews should be scheduled such that they allow time for work – but also create a cadenced (perhaps weekly) review to surface and work through breaking issues.

2)   Participants, especially leaders, should be prepared. Send out critical info in advance whenever possible. Presenters should have a clear problem statement, show work to date and alternative solutions (A3s can be useful for this). This is not a place to just dump a problem.

3)   Hold the review at the gemba whenever possible. Make sure actual product, critical data or CAD is available.

4)   Leaders should ask probing, meaningful questions. Not play “stump the chump” to show how smart they are or just provide answers. If you choose the former, people will shut down, if the latter you will soon find yourself owning a lot of problems.

5)   Encourage robust and candid dialogue – ask the tough questions. Creative tension is an important part of creating great products. But never, ever allow attacks on people. Think about interfaces and interdependencies, and where the program is in the development process.

6)   Remember to “do the experiment.” It’s not a debate club. Ask how can you effectively test a hypothesis.

7)   Capture and apply knowledge. These are your learning cycles, your opportunity to enforce, update and create standards through learning. Be sure to fully leverage existing knowledge and capture new information.

8)   Design reviews should be a foundational part of your overall development operating system. In larger organizations an integrated network of design reviews may be appropriate. And participation is not optional.

9)   Set high expectations for both the product and the participants. But set even higher ones for yourself.

There is no potion, no incantation, not even a magic e-letter that will transform your organization into an innovation machine. It requires hard work, focus and perseverance – but that’s the point, isn’t it? Creating innovative solutions and delivering new value need to be part of who you are and built into how you do your work every day.

Are your design reviews contributing to that goal?

More than a New Product – A New Way of Thinking

Successful entrepreneurs, whether they are lone figures toiling in garages or supporting new work at major companies, are rightly celebrated for creating hit products. But what if there were something better – much better – than creating a product in isolation? What if, in fact, there was a system of thinking that supported the creation of entirely new value streams? And what if the path-breaking innovation was not limited to the product but encompassed all of the steps required to bring value to your customer, and even how it impacted the world? Just think of the potential.

This idea, of course, is one of the foundational elements of lean product and process development. “Creating profitable value streams” as the aim of lean product and process development was the insight of our late friend and colleague Allen Ward. It was one of many topics he, John Shook and I would discuss and debate over beers at Sidetracks while we were all at the University of Michigan. Al’s profound observation is so important because it demonstrates a deep understanding of the powerful thinking behind the LPPD system. In fact, it is the very essence of creating customer value because it requires that you consider every activity needed to deliver that value from product concept through the end of its life cycle.

This comprehensive, and intentional developmental approach is just one of the elements that differentiates lean product and process development from other methods and I am especially eager for those recently bitten by the “lean bug” to graduate to this way of thinking.

So, what to do with this profound insight about seeing beyond one product, and instead thinking through the creation of profitable value streams? This was just one of many challenges I faced as I wrapped up my research and headed back to the daily grind of creating new products and processes in the real world.

While I was at Ford, one of the most useful concepts we developed in thinking about value stream creation was (and is) “Compatibility before Completion” (CbC). It is the fundamental idea that designs must be compatible with the all system and value stream requirements before they are completed and released. It was originally intended as a powerful countermeasure to late-breaking development issues and subsequent spikes in engineering changes brought on by an unhealthy obsession with individual design release speed – and it was! But it turned out to be so much more.

By leveraging the CbC concept we built critical compatibility checks into our development system. This progressive series of checks contained demonstrable requirements timed to match the maturity level of the design at the appropriate point in the development process. You must be careful not to waste time evaluating premature and unstable data too soon – it’s just going to change. But you should definitely not wait until after designs are complete and drive rework. In this way they make up a series of JIT deliveries for development work.

Some typical areas that benefit from such checks include manufacturing requirements, product serviceability, product installation, product and process environmental footprint implications, and setup for aftermarket products. Each of these have their own series of progressive checks. It is a powerful, customer-centered, eco-systemized way of thinking that encourages the team to collaborate as they think through the entire value stream.

Many companies, such as Toyota and Ford, employ the CbC concept in their value stream creation efforts. They both make extensive use of virtual reality, simulation and standards to drive manufacturing Bill of Process alignment to help ensure product quality and manufacturing efficiency. Their efforts start very early in the process by examining master sections and standard locators and then progresses simultaneous with product design maturity all the way to part transportation, presentation and sequencing – with many virtual “JIT checks” along the way. Early Functional builds are an excellent way to check initial part fit, finish and function when development has progressed to the physical world and create a rapid feedback/learning loop before tool finalization. Menlo Innovations compiles disparate code and performs weekly software system runs with their customers to ensure compatibility to requirements and generate industry-changing products. Toyota demonstrated its commitment to the environment by employing a progressive CbC approach to hot stamping technology on a recent development program. The result was a two-thirds reduction in carbon footprint and the elimination of an environmentally risky shot blasting process to remove oxide.

There are many tools and technologies to aid in moving your compatibility efforts up-stream, where they are most effective. We now have everything from stunning virtual reality environments, to incredibly powerful simulators, to the numerous additive-manufacturing technologies that aid in rapid prototyping. But none of these, it seems to me, is as important as the organizational drive to create a truly great total customer experience, an enabling, foundational infrastructure to promote value stream collaboration, and maybe just healthy, hearty conversations between colleagues who are united in their pursuit of better answers…with or without beer.

 

Best Regards

Jim

 

P.S.

  • We had a sellout crowd for our first LPPD Learning Partner Event of 2016. All of our partner companies had outstanding experiments and improvements to share and GE’s First Build was inspiring as always, but I thought that the growing respect and strengthening relationships between company leaders was the event highlight for me.
  • Our friends at the Lean Product and Process Development Exchange (LPPDE) will hold their North America 2016 conference on September 26-29 in Philadelphia. The agenda has been designed to create EXCHANGE and learning around key questions in the evolution of Lean Product and Process Development. Learn more at lppde.org.

The Importance of Embracing Development Conflict

Far too many product development professionals take sides in the (alas, unnecessary) conflict between the unlimited potential of human innovation and the incredible power of good standards. On the one hand, the “free spirits” fear that lean standards limit creativity and lead to painfully boring products. On the other, the “technocrats” are haunted by visions of cost overruns and operational chaos that result from unconstrained imagination run amuck.

Whenever I encounter someone using this limiting form of binary thinking, I remind them that those who can embrace conflict find it to be a huge source of opportunity. And this is definitely the case here.

An effective way to think about this dilemma is to see it not as an either/or problem, but as an “and” opportunity. The “fixed and flexible’ philosophy emerged out of work with my colleagues at Mazda more than a decade ago with significant benefit to both companies. I believe this seemingly simple concept can have profound implications for your development capability.

“Fixed” elements in product development are often expressed through standards that are experienced-based solutions for typical/recurring problems. Or they can be critical, progressive “quality of event” criteria built into the development process in order to help teams determine normal from abnormal conditions during a development project. In both cases, these standards are a powerful mechanism for applying the learning from one project to the next.

Over time, experience and knowledge accumulate, standards are updated and developers are able to make decisions faster and with better quality. These clear criteria (which are captured and communicated to the team) make the ability to learn and apply new knowledge a true competitive advantage in a very real way. Developers do not have to waste time and resources learning things over again. Aligning on the fixed portion of the project is also crucial in understanding and managing the program’s risk profile.

“Flexible” aspects of product development are those in which innovation and creativity add the most customer value through resulting differentiation. They are the very heart of the product’s unique value proposition – the “why” we are doing this project. In this case the high level vision of “what” we are trying to do may be understood but the how is not. Consequently the risk profile and gaps in knowledge are significant in this part of the project and will require substantive innovation.

Fortunately, the fixed elements mentioned above allow developers to focus their energy and creativity where it will provide the greatest possible return in the product. A deep understanding of how this product will deliver value coupled with a compelling vision for the product is essential. It is equally important that the organization is aligned around this vision and that each team member understands how he or she will contribute to achieving success. The Chief Engineer concept paper and related activities are incredibly helpful.

Product and Process Examples

Here are a few straightforward examples of fixed and flexible in product and manufacturing processes from the auto industry. The first one is individual part interface standards for components that are part of a larger system like modules or platforms. Focusing on proven standards only at critical interfaces allows for maximum creativity on the majority of the component design while simultaneously safeguarding critical system performance by fixing a very few key design attributes.

Another example comes from the car front hood assembly. The inner hood, whose function goes largely unnoticed by customers, is created from standard geometry and only modified to fit the specific shape and size application (fixed) while the outer hood which is crucial to vehicle styling and appeal is left largely to the creative direction of the designer (flexible).

Finally, common part locating strategies and basic standard assembly sequences are fixed to create a standard Bill of Process while the majority of the vehicle is designed to deliver its own unique value proposition. This allows the best companies to build eight or more very different vehicles on the same assembly line creating incredible efficiencies and manufacturing flexibility with high degree of quality without resorting to mere “badge differentiation” between products.

I think it is important to emphasize that the fixed portions of design should always be limited to the critical few elements. In this way you can maintain critical to quality, performance and manufacturing requirements while simultaneously enabling innovation.

At Ford, understanding and executing to fixed and flexible aspects of our products and processes helped enable us to deliver some of the most exciting and innovative designs in Ford’s history. Body fit and finish were among the best ever, all while simultaneously reducing investment costs and lead-time and improving product quality.

A more recent example of this is the Toyota New Global Architecture, in which the combination of breakthrough technologies and powerful standards created from decades of experience have led to a 20 percent reduction in resources required for development, lower manufacturing investment costs, and products with dramatically better ride and handling characteristics. It is an important part of what continues to give them the highest profit per vehicle in the industry.

The fixed and flexible concept applies equally well to your development process, management system and organizational strategy. However, the real secret of making the concept work for you lies in understanding what and how value is delivered to your customers and development teams. Ignorance is expensive and wasteful; deep knowledge is key. And don’t forget that creative tension – conflict can indeed be a tremendous opportunity if you know how to leverage it to get the most out of your development system.

Best,

Jim

 

P.S.

Our learning partnership continues to grow. Our latest partner is FMC Technologies, a global leader in undersea oil and gas exploration technology whose products have to function flawlessly at more than 5,000 feet below sea level. After an outstanding kickoff week, we are working with FMC on major projects in Brazil, California and Texas. We think they will be an excellent add to the partnership.

I had the honor of speaking at GE Appliance’s annual Presidents’ Council Summit in Louisville last week. This is an outstanding event that brings together about 160 of the most senior leaders of GE’s top suppliers with GE’s CEO and his leadership team to share their strategies and solicit input on how to better work together to bring ever greater value to their customers. This event is an important part of their strategy to engage suppliers as partners to create an extended lean enterprise.

Congratulations to our friends at LPPDE on a successful conference in the UK last month! I have heard it was an excellent learning opportunity for students of LPPD.

Our next Partner Co-Learning Event will be held at GE Appliance in Louisville later in May. We will see firsthand the role of GE’s path-breaking “First Build” in capturing, understanding and delivering customer-defined value in new products. We are bringing in globally recognized experts John Drogosz and Durward Sobek to help deep-dive trade off curves and set-based innovation and discuss our partners’ experiences with these methods in the real world. We will also share the incredible progress several of our partners have made in building product-differentiating craftsmanship into their products.

Creating New Value and a Lesson in Fundamentals

LPPD is about continuously innovating to find a new and better way to deliver new value. It’s about creating the future. But I recently had an experience that reminded me that not everything should change.

Last month I traveled to Toyota headquarters in Japan with Jeff Liker for a research project. We wanted to learn more about the engineering and collaboration that created the Toyota New Global Architecture (TNGA)the strategy and innovation behind hydrogen vehicles, and how they had adapted and improved their development system to meet the increasing demands of the ultra-competitive global auto industry.

jim_toyota

It had been over a decade since I’d last been at Toyota, and even longer since I’d first learned about the principles and practices that made up the powerful system of lean product and process development (LPPD). So much had happened to both Toyota and the rest of the world since then. And so as our plane crossed the Pacific, I wondered to myself, “How much has Toyota and their development practices changed since I first began my LPPD journey?”

Jeff and I were definitely not disappointed with our visit. From the shop floor to the test track, Toyota shared with us its game-changing new products, powerful new methods and breakthrough technologies. But what impressed me most was what had not changed.

LPPD, as practiced by Toyota, is still an enterprise-wide system that creates new value streams. It is not just a scheme for one-off products or a discipline solely for product engineers. So when Akio Toyoda, President and CEO of Toyota committed the company to creating “ever-better products” he was not just talking to product engineering. He was providing a “true north” for the entire enterprise. Directing everyone at Toyota to provide ever-greater value to the customer through their work on new products and processes. This meant improving both product attribute performance and improving the quality or efficiency of all product delivery mechanisms – especially manufacturing processes.

I’d like to share just a couple of examples of how Toyota continues to simultaneously develop products and processes focused on creating ever greater value for the customer.

The first example is how Toyota went about dramatically improving vehicle ride and handling characteristics. One way to improve a car’s ride and handling is to increase body stiffness. Consequently Toyota set an objective of increasing stiffness from between 30 percent to 60 percent depending on the particular car. One way to reach this goal is increasing the number of spot welds on the body. However, this can significantly increase cycle times and/or drive costly investment in the assembly process. In many companies this conflict would result in cross-functional battles, compromised product and process performance, and far less value delivered to the customer. But Toyota PD and PE engineers worked together to improve product geometry and develop Laser Screw Welding (LSW) technology that requires less than half the cycle time of conventional spot welding and less plant-floor space, yet still delivers the required body stiffness. Nothing less would have been acceptable. LSW also has the added benefit of being far more flexible than traditional spot welding for launching additional new products and can weld multiple material types.

Another product priority for Toyota is to reduce weight to increase fuel efficiency. One way to accomplish this is to engineer parts out of high-strength, lightweight materials that can replace multiple part sub-assemblies and be thinner gauge – thus reducing vehicle weight. However, some of these materials have to be superheated prior to forming. Traditionally, this has required very large, dedicated gas ovens that heat steel blanks in large batches, plus an added operation to remove the layer of oxidation caused by the heating process. While this might be an acceptable compromise for many companies, working in batches and adding operations in TPS is a non-starter.  Once again, Toyota PD and PE engineers collaborated to tailor blanks and create a joule heating process that heats blanks one at a time, in 5 to 10 seconds – and with no added operations required. While some companies are satisfied with improving their products with added costs passed on to their customer, the LPPD system embedded at Toyota enables them to deliver lighter, safer vehicles AND at even lower costs than their predecessors.

These simple examples illustrate Toyota and LPPD at its most fundamental. Leveraging collaboration, learning and innovation in product and process development to deliver solutions that maximize value to the customer.

So what did I learn on my journey? That in the midst of continuous improvement, Toyota is still grounded in the strong fundamentals that make up LPPD and focused on delivering “no compromise” value to their customer.  And by continuing their drive to deliver ever-greater customer value through both product and process innovation, Toyota can achieve improvements far beyond those possible by “product only” solutions.

So, is your organization collaborating to develop both product and process solutions in creating new value for your customer, or settling for compromise?

For me LPPD embraces both a driving passion to make great products and an absolute reverence for the ability to make them well. This is still the most fundamental, and perhaps most powerful way of creating new value.

Best Regards,

Jim

Three Core Capabilities in Any Lean Product and Process Development System

Good development leaders work in earnest to create a “safe culture” for people to share issues. Working to drive out fear, and actively communicating the need for candor and collaboration is both important and necessary. But it is not nearly sufficient for identifying and eliminating technical issues at the optimal time in a development program. Good intentions are not enough.

In addition to fostering a safe culture, your development system needs integrated mechanisms and practices that provide people with: 1) the ability to distinguish abnormal from normal conditions, 2) the ability to communicate abnormal conditions effectively and, 3) the ability to respond to these conditions consistently and effectively.

1. Distinguish Abnormal from Normal

Solving problems, mitigating risk and closing knowledge gaps are a fundamental part of development work. So much so that developers often have difficulty distinguishing normal from abnormal situations in development programs. Consequently development teams must have a method for understanding where they are relative to a performance standard. Are they where they need to be at this point in the project to have a high likelihood of success? Often the reason engineers don’t surface problems “early” is that they are not completely sure when “early” is. They have no model to compare to.

Please understand that I am not talking about the thousands of lines of requirements embedded in you project management standards. More requirements are not the answer; in fact, too much information (if they read it at all) usually detracts from a developer’s ability to distinguish critical criteria. I am talking about scalable guidelines that provide developers with acceptable risk profiles over time (i.e. what are the acceptable number of open issues at each milestone, along with corresponding severity levels), cadenced knowledge gap closure (i.e. what % completion of product design is acceptable at each gate) and a focus on synchronized solution convergence across functions (i.e. time-bound input/output requirements across Functions).

2. Effectively Communicate Abnormal Conditions

Next, you have to have a way to make abnormal conditions visible to critical participants in the development system. In lean manufacturing this is a large part of the role of “andon”. It is the flashing light, music, or green painted safe operating range that calls the team’s attention to an issue on production. Think of this step as creating a development andon system. Obeya visual management and associated “dashboard strategies” that contain the vital few indicators is one of the most powerful ways to do this as long as active management is the more important half of visual management. It’s not about decorating the walls.

However, it is not enough to make abnormal conditions visible, just like it is not enough to just detect a land mine, you have to de-fuse or avoid it. Although it seems many companies are content just to predict the explosion, you also need a robust management system that reacts and resolves issues in a timely manner. Without one, most engineers hesitate to surface problems because they have no realistic expectation that they will get the support they need. Just imagine if there was no response to andon on a production line. How long do you think people would continue to pull the cord?

3. Respond Consistently and Effectively

One crucial part of that management system response is a regular cadence of recurring events designed to respond to abnormal conditions and provide rapid support to developers. Regular status reviews for cost and timing are important, but our VP was struggling in particular with surfacing technical issues on programs. And for that a cadence of technical or design reviews is crucial. No, I am not talking about that “dog and pony show” that occurs just before a milestone. I am talking instead about a regularly occurring technical deep dive review designed to surface and resolve thorny technical issues, promote cross-functional collaboration, break up technical log jams, and grow organizational capability. The time must be sacred.

The nature of the reviews morphs over time to support the program needs and provides the pace making function to keep development moving forward. Early in the program they focus on set-based exploration of potential design solutions, later perhaps efficient design, cost target, and attribute delivery is primary, then system compatibility and finally effective response to breaking issues. But at every point in the process it is a place to surface and resolve technical issues, not berate or debate them. It is a place of candor and challenging questions. It’s a “hands-on” cross-functional event held at the gemba when possible, focused on improving both the product and the organizational capability. These events should act like “superchargers” to build momentum and confidence, align participants, and continually move programs forward.

This article is an excerpt from Jim Morgan’s most recent e-letter to the Lean Product and Process Development community. Read the full letter here. Sign up for future e-letters from Jim Morgan here.

Put Your People at The Center of Your Development System

Dear Community Member,

My spidey sense was tingling as my host, the GVP of Product Development, explained that “…of course, it goes without saying that people are our most important asset and so we recruit and hire the top people from the best universities and get out of their way.” By the time he shared their only specific example of their people development strategy as an annual training-hours target, full-blown alarm bells started going off. Especially since one of the reasons I was there was because of high attrition levels among technical people.

“Respect for people” in product development starts with not taking your people for granted. It is your people that provide the skills, energy and creativity. They are the single most important element of great product development systems. They drive the system. Yet many companies leave their growth and development to chance. They are far more excited about their newest additive manufacturing equipment or cloud based collaboration tool. What’s more, it seems that the recent startup craze has exacerbated this problem. Companies seem less inclined than ever to make long-term investments in people – and this is indeed a troubling trend. And what may be worse, few product development “experts” seldom even mention people. Having the right people in the right roles with the right skills is “just assumed.” This is a potentially fatal mistake for the long-term viability of your organization. It is the fundamental responsibility of every enterprise and every manager in those organizations to invest in the development of their people.

It was at the beginning of my own lean journey more than two decades ago that two comments about the role of people in lean really resonated with me. The first was when John Shook told me that “Lean is not people agnostic – people are the center of lean and the reason for it.” The second was when Mike Massaki, President of the Toyota Technical Center explained that at Toyota “we develop people and products simultaneously.” What he meant was that at Toyota, people development was not an extracurricular activity delegated to HR. It was at the very center of everything everyone did. It was part of how they did their work every day. And throughout my next three years of research I saw how Toyota leaders coached, mentored and consciously developed some of the best engineers in the industry and turned that development into a truly lasting competitive advantage.

But it wasn’t until I started to apply these lessons as a development leader that I really understood what it meant to put your people at the center of your development system. It fundamentally changed how we approached our work: how we led our design reviews, how we made assignments, the development tools and processes we created, how we thought about “career paths,” and most of all, how we viewed our roles as leaders. And that helped to transform our organization as well as our products.

While a detailed discussion of each of these topics is beyond the scope of this e-letter, I will leave you with one question to reflect on:Where do your people fit into your development system?
– Jim

Jim Morgan
Senior Advisor
Lean Product and Process Development at the Lean Enterprise Institute

PS:

LEI LPPD Open House: Last month, product developers from 22 different organizations packed into the LEI office in Cambridge for our first-ever LPPD Open House. They came from as far away as Rio de Janeiro and Tel Aviv, as well as all across the U.S., and represented industries as diverse as software, microprocessors, undersea exploration equipment, consumer products and healthcare. It was incredible! In addition to a great networking opportunity, we shared several successful case studies that illustrated the potential of LPPD including the excellent work of our learning partner Herman Miller. We are thrilled with the incredible community growth we have experienced in the last year.

LPPD Learning Partner Event: These events continue to be one of the most unique and powerful opportunities for learning as companies share the details of the challenges and success of their LPPD journey and October was no exception.  Our partners currently have experiments underway on effective LPPD management systems for running product development systems, craftsmanship excellence, creating milestone quality of event criteria and visual management. In addition, Sebastian Fixson, Professor at Babson College led an excellent, interactive workshop on “Design Thinking” and Jim Womack shared his perspective on the crucial role of LPPD in creating a Lean Enterprise.  Our partnership continues to grow in both size and effectiveness and has become a benchmark learning process.

LPPDE Conference: September’s LPPDE North America conference in Austin was a hit! Attendance, energy and post-conference feedback were off the charts. Your next chance to engage with the Exchange will be in the U.K. April 25-27, 2016 and in Philadelphia in September 2016.