R&D
To the average manager R&D (or product development) is simple: to develop new products such that they can be taken into production. The sooner the better. And the most heard complaint about R&D is thus "they're always late", highlighting one of the biggest problems in R&D: project slip, or in other words finishing projects (much) later than planned, delaying production ramp-up and market introduction (assuming the market is there, which is an altogether different discussion).
To be fair there are not many R&D-organizations where all projects are executed perfectly according plan; slip is an omni-present issue. This can be regarded from two sides. |
From the one side it is absolutely true that R&D is complex, especially in the case of e.g. IC's in complex and/or advanced semiconductor technologies, complex devices containing a mix of electronics, optics, mechanics and software, and of course for complete systems. A thousand things can go wrong, and statistically things will go wrong; therefore slip is inevitable. In this way expectation is the mother of all delays. The problem with this mind set of inevitable slip is that R&D becomes an unpredictable and unreliable function within the company organization, resulting in a lot of negative energy being burned in useless discussions about the reasons for the delays. Often external forces ("management") will impose measures on R&D that will make matters only worse.
However, I'm of the opinion that R&D organizations should strive to be "perfect", which is pretty much equivalent to "predictable". In other words, project slip should be an exception and the majority of projects should run as planned. A well-organized R&D or Engineering organisation should for every project to negotiate with the business stakeholders:
The ideal situation is thus R&D/Engineering as a well-oiled smoothly running execution machine. Most R&D organizations will have to execute multiple (which can be tens) parallel development projects, which means that the above way-of-working should be embedded in the organization and not something that needs to be discussed and negotiated on a per-project basis. R&D should thus be treated as a well-defined process, which can be split into two main sub-processes: the Product Selection Process (PSP, focussing on definition, planning and priority setting) and the Product Creation Process (PCP, project execution).
Having been in R&D for over 30 years, of which 25 as R&D manager at all levels, I am of the strong belief that solid process methodology is the foundation of every successful Engineering organization. Where on a case by case basis the proper mix between process formality and flexibility must be identified and maintained. Below some aspects that are relevant for each of the sub-processes in R&D.
However, I'm of the opinion that R&D organizations should strive to be "perfect", which is pretty much equivalent to "predictable". In other words, project slip should be an exception and the majority of projects should run as planned. A well-organized R&D or Engineering organisation should for every project to negotiate with the business stakeholders:
- the required resources given a solid assessment of the complexity of the product, the amount of re-use, technology and IP risks, etcetera and given a target planning. If fewer than the required resources are made available the up-front planning will delay!
- the targeted performance (which is more than just the specification). Again, if more and/or risky features are added to the wish list, effort (resources) and/or planning will shift.
The ideal situation is thus R&D/Engineering as a well-oiled smoothly running execution machine. Most R&D organizations will have to execute multiple (which can be tens) parallel development projects, which means that the above way-of-working should be embedded in the organization and not something that needs to be discussed and negotiated on a per-project basis. R&D should thus be treated as a well-defined process, which can be split into two main sub-processes: the Product Selection Process (PSP, focussing on definition, planning and priority setting) and the Product Creation Process (PCP, project execution).
Having been in R&D for over 30 years, of which 25 as R&D manager at all levels, I am of the strong belief that solid process methodology is the foundation of every successful Engineering organization. Where on a case by case basis the proper mix between process formality and flexibility must be identified and maintained. Below some aspects that are relevant for each of the sub-processes in R&D.
Product Creation Process (PCP)
|
Most PCP's are milestone- driven or gated, where the project is only allowed to the next phase if in a (milestone or gate) review meeting the conditions with respect to project status and product maturity are met. This involves amongst others:
|
Project Selection Process (PSP)
|
The PCP above essentially deals with the "HOW" of product development and R&D. However, even the most efficient R&D organization is useless if the "WHAT" is not in order. In other words, which products are developed. This is of course not a question for R&D only but instead of the business team to which the R&D belongs. But the R&D organization, through its Engineering manager, project managers, product architects and lead designers, should have an important say in this Project Selection Process (PSP). The initial product definition and selection phase, before the actual project execution starts, is extremely important for a smooth operation of Engineering! It covers a number of activities:
|
Pre-Development
|
The next pre-condition for smooth product development execution is being prepared. For technology, IP and features this usually means pre-development, or demonstrating and de-risking through prototyping. Simple as it sounds, pre-development is far from obvious and there are quite some challenges associated with it, be it for big companies or start-ups:
|
Roadmaps |
Although there are more ways to present the strategic product and technology planning, I am a big fan of roadmaps, which show the different generations and their relations over time. Roadmaps visualize the product and technology strategy of the business, and give a lot of insight.
|
R&D Organization
|
The structure and organization of R&D are on the one hand very dependent on local company culture. At the same time there are a number of topics related to the organization structure that can be seen as universal, and valid for all companies that have at least a minimum desire to implement a consistent structure across their (international) R&D and/or Engineering. Typical topics on the basic R&D structure:
|
EDA and Tools
|
The more complex the product to be developed, the larger the development teams, the more diverse the technologies used and the higher the costs of prototyping, each of these drives the need for advanced tools to be used by the developers. Where tools here almost always means Electronic Design Automation (EDA), software tools to support the many simulation, design, verification and validation steps. It is one of the primary roles of R&D management to provide their teams with the required, preferably optimized and up-to-date EDA tools. There are only a few down-sides: tools tend to be horribly expensive and there are many alternatives. EDA and tool management is thus far from obvious. A few aspects:
|
Although "Lean" is one of those expressions that can easily be over-hyped or misused, I'm a strong believer in this concept. LEAN should help to close the loop, of what are extremely complex R&D processes (see all topics higher up on this page). Essentially LEAN works on avoiding WASTE, which is everything that avoids a project or organization to perform optimally. There are three main causes for WASTE:
|
LEAN in R&D
|