Today’s blog post will handle Toyota’s terrific anti-clogging systems in Lean Product Development, used to avoid the two types of Organisational Clogging symptoms, too many people and too many activities. In these two blog posts, about the too many people and too many queues of activities symptoms, there is more information about the details.
Here is how the chains of symptoms looks like for the Organisational Clogging symptom in the Prefilled Problem Picture Analysis Map.
I am sure you have heard about some terms that are specifically associated with Lean Product Development that is originally for hardware development, like; Shusa, Set-Based Design* or Set-Based Concurrent Engineering*, Multiple Concepts, early prototyping, integrated and concurrent development, supplier collaboration, voice-of-the-customer, that are some of them.
Note! Set-Based Design/Set-Based Concurrent Engineering must not be confused with Multiple Concepts, because they are totally different, but can be used intertwined. SBD/SBCE have instead of solution points, a solution space for different parameters for parts that later will be integrated. The reason is that the decision can then be taken as late as possible, when choosing the different parts to be intergrated. The parameters can for example be; emitted pollution, electricity need, form fit, volume needed, noice level, emitted EMC, EMC sensitivity, life length, quality, price, etc. where of course the legal aspects and price are very important parameters.
Mutiple concepts by itself, are often used for choosing between different designs, for example of the whole car, and can start with many different designs in some cheap and easy-worked material and the fewer designs that are left, the more real material are used, until the final one is chosen.
SBD/SBCE and Multiple Concepts are preferrably used when trying to take a technology step (pre-development in the project), where a safe concept always is needed to not risk the total project time plan.
Integrated and concurrent development, is the same as having teams working in parallel, and in Lean Product Development the team of teams, lead by the shusa, is of course cross-functional, but the teams themselves are I-shaped. Here is the picture showing parallel work again, with the details about working in parallel in this blog post.
And in order to work in parallel, the interdependencies need to be thoroughly tracked, to not clog the system with activities, and this is taken properly care of the Shusa and his team of teams, as well as all time planning, short-term as long-term. The time planning root cause is therefore properly solved.
Regarding the too few people with T-shape root cause, Toyota has taken care of them in the following way over time:
- Shusa – the chief engineer, that with more than 20 years at Toyota is an broad expert, but can be expert of organisational knowledge, or research test engineering instead, including the voice-of-the-customer.
- Product Development Engineer – has also spent time in production and always considers manufacturing technologies
- Production Engineer – is very broad and is a mandatory part of the Product Development process, signs-off the technical solution
- Simultaneous Engineer – was added in the 1990s, is very broad, and added to get a seamless product development flow, responsible for a certain module like; underbody, front end closure, etc.
As we can see, Toyota’s high-level thinking really shows their priority of cross-functional competence.
Toyota has a good usage of their (T-shaped) people with small meetings for decisions, discussions, etc., making the interactions in the meeting room few. The trust from the manager to the employees are very high, making the meetings more of a formality, since everybody in the room already have been involved.
All together as we all can see, Toyota’s anti-clogging system in their product development, what we call Lean Product Development, extremely well takes care of all these three root causes that solve the Organisational Clogging symptom.
This was all for this blog post, and the next blog post will handle the last symptoms for Organisational Clogging. C u then.
*SBD/SBCE can also be used for software development, and would be appropriate for a platform with modules, that Brad Cox, author of Object-Oriented Programming, in the article “Planning the Software Industrial Revolution”, stated already three decades ago; “The possibility of a software industrial revolution, in which programmers stop coding everything from scratch and begin assembling applications from well-stocked catalogs of reusable software components, is an enduring dream that continues to elude our grasp…” [1].
The development of the modules using SBD/SBCE can for example have the following parameters with their respective solution space; calculation memory needed, physical memory needed, internal speed, communication bus usage, Conway’s law/architectural violations, stability, load, development cost, speed to market, etc., where of course development cost and speed to market many times can be the dominant parameters of choice. But, with clear I/F, a module can later be updated separately if it is “underperforming” for some of the former mentioned parameters.
With clear well-specified I/F, a module can easily be reused, as Brad Cox is pointing at, which significantly will reduce cost for further development, not to mention time to market.
Note! Features is more or less going the other way compared to SW modules, but they can clearly be intertwined, with basic SW modules that are easily used when making the new features.
[1] Cox, Brad J, “Planning the Software Industrial Revolution”, November 1990, IEEE Software Magazine. Link copied 2019-01-29.
http://wiki.c2.com/?SoftwareIndustrialRevolution