+ 0 - 1 | § ¶Process Training - the Forgotten Factor?
Throughout 2005 we are carrying out a number of Lean Product Development Assessments / Diagnostics with companies of various types and sizes, and across different industry sectors. Each company has its own particular combination of strengths and weaknesses, but from the assessments we have carried out so far, one common theme stands out - a lack of attention to training. It is almost as if, as development managers we expect that employees will either:
a) Intuitively know what work to do, when to do it, and what linkages their work has with others.
b) Pick things up as they go along by some undisclosed method.
c) Know there is a Quality Procedures somewhere, and have it memorised from cover to cover.
d) Have been taught 'Product Development' at college or university and know all there is to know.
Don't get me wrong, we have not found that training is ignored completely, but we believe that the emphasis and priority in the company is mostly wrong. For example, many companies conduct performance based appraisals that highlight specific skills training requirements (such as CAD training, MS Project, General Project Management practice etc.), but few, if any, identify process training needs. If you are a manager, think back to last year's appraisals - how many employees' training plans included how to run a design review, or how to use an FMEA (Failure Mode and Effects Analysis) as part of a design quality plan, or how to start early design collaboration with a key injection moulding supplier?
Compounding the problem is the fact that companies tend to produce little in the way of detailed and company-specific process training material. Or maybe if material does exist, they lack the capability to schedule ongoing training sessions for new or promoted staff. The result is that even if a company has the most elegant and sophisticated Product Development 'system' in the world, unless every person on the project team understands and executes their function at the desired level of competence, system performance as a whole suffers.
A laisser-faire approach to process training means that development work can be inconsistent, incomplete, time consuming, inefficient or just plain wrong. Referring to our last post, these are the very traits that seem to have been eliminated in the Product Development process at Toyota. I would put a large sum of money on the fact that every project team member at Toyota gets more process-based training than any other development team in the world. 26 Oct '05 - 17:52 | 414 W | | New Product Development | Add Comment
+ 0 - 1 | § ¶Lean Development at Toyota
Lean.org has a link to an interesting paper written recently by two French writers and consultants (link may require registration). The paper is a concise overview of Toyota's New Product Development System. Most people will know that Toyota is the original 'Lean' company, and is probably the most studied manufacturing firm in the world. However, what might seem surprising to many about Toyota's Lean Development methods is that they do not appear to be particlarly radical in any one area. I'm sure many companies use similar techniques in their own product development operations, yet despite this, according to a study cited in the paper, Toyota's new car development cycles are twice as fast as some western car makers and are conducted with only one quarter the number of engineers.
How do they do this?
Toyota's own managers believe it is down to a consistent and pervasive systems approach that shapes Toyota workers' attitudes and work. The paper's authors, Freddy and Michael Balle, have identified four key elements in Toyota's product development system:
1. A focus on customer reactions to products, which in turn drives a strong product vision that is communicated to all those involved in the product development project. This vision serves as THE master reference by which all product related decisions are made.
2. An emphasis on limiting changes late-on in the development cycle. There is a drive towards "perfect drawings" or "Zero-EC" (Engineering Change). This means that designs must be right before passing into the production detailing and ramp-up stage.
3. An optimised, efficient and well-proven process for information flow during the production detailing stage. This is made possible by the lack of late changes.
4. Application of lean manufacturing thinking, including product quality and cost of production, to the manufacturing process development stage.
I'm sure that none of these principles will be news to most product development managers, so why is Toyota's development performance apparently so much better than everyone elses? Logically, it must be down to implementation. They must have found a way to get their staff to carry out their work in such a way as to be totally consistent with these principles. There are a couple of a clues in the paper - during the early phases of a project when idea flux is high and fast communication is critical, progress is driven and co-ordinated by a technically strong Chief Engineer. During the later stages where work interdependence is high and manufactuing and quality issues are crucial, checklists, process sheets and standardised work content are extensively used.
One of the criticisms often directed at 'Lean' is that it works well in optimising repetitive manufacturing or administrative processes where waste can be observed time after time, and tangible improvement results can be seen quickly; but that in inherently chaotic, creative and unpredictable processes like product development, Lean doesn't apply. Toyota are clearly demonstrating that it does. The secret, it seems to me, is not simply having the right principles and strategies, nor is it purely down to wielding a bulging 'Lean Toolkit', it is in finding ways to ensure that people know how do the right thing at the right time.
+ 1 - 0 | § ¶Getting the Best from Knowledge Workers
When it comes to managing your company's knowledge based processes (e.g. new product development) would you say your company's approach was HSPALTA (Hire Smart People And Leave Them Alone)? If so, you are not alone. Accordng to Professor Thomas Davenport, of Babson College, in Wellesley, Mass. most companies probably do the same, and as a result they fail to get the most from their most important Knowledge Workers. In an
interview in CIO Insight magazine Prof. Davenport makes some interesting observations about the skewed emphasis companies tend to place on improving and optimising 'transactional' processes that are more amenable to measurement and control than knowledge processes.
However, Prof. Davenport cites a study by IDC that found that "1,000 knowledge workers can lose as much as $6 million a year just searching for nonexistent data, or repeating work that has already been done". And this is despite years of investment in technology tools such as MS Office applications, CAD, CRM etc. etc.
So what can be done to improve largely unpredicable and unmeasurable processes. The key is in making it easy for knowledge workers to do their work. We can define broad frameworks that will guide knowledge workers to use their talents creatively; define standardised work content for the routine parts of their work; support them with tools and templates; automate non-value adding work; and give them the precise information they need, just when they need it, to help guide decision processes.
All this sounds logical, however implementation of this level of support is far from easy, so why not just leave our smart people to be smart? Well, as Professor Davenport states,
"We have a choice here. We can get more productive with our knowledge work or we can lose our jobs. There are other parts of the world where people are very serious about being more productive, and are doing it for a lot less money than we charge. Twice as many Indian software providers are certified at level 5 on the Capability Maturity Model as U.S. companies. People should realize that unless they do knowledge work better, they're not going to be doing it at all."
