R&D processes

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 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.

This requires quite some negotiations before the project starts, and a project should only be allowed to start if the basic conditions are fulfilled. But if so, R&D should do everything it can to deliver as committed w.r.t. timing (on-time as planned, no slip), performance (meeting the functional and performance specification requirements) and price (product cost as targeted). And yes, the occasional slip will still occur, but it should be an exception, and early and transparently be communicated.

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:

PCP milestone/gate definition and corporate acceptance
definition of milestone/gate meeting review items and pass conditions
project management structures and processes (as part of R&D!!)
definition of Key Performance Indicators (KPI) to measure and control the project execution an the total R&D project pipeline
feedback loops for optimizing the PCP, both on a per-project and overall organizational level. This can include internal or external auditing.
documentation, data management and project management tools, driving productivity improvement

But R&D is not an isolated function, and there are multiple interactions with other functions and departments that require synchronization, alignment and should be used in the projects:

Synchronization between product development (PCP) and the underlying technology creation process (TCP, which often means separate TCP's for front end and back end technologies), IP creation process (IPCP) or software creation process (SCP). Essentially this means that the sub-processes need to have a maturity ahead of the top-level PCP. And each of these other creation processes need to be defined in the same way as PCP!
Early incorporation of requirements and experience from supporting functions into the PCP and product definition. This is often called "Design-for-X", e.g.
- Design-for-Test; optimizing the product architecture to allow the easiest, fastest, cheapest and most complete testing
- Design-for-Quality; optimizing technology choices and product design methodology to attain the highest possible quality level, maximum yield and lowest field call rate
- Design-for-Manufacturing; optimizing the product design for the smoothest possible manufacturing and assembly. But also to design the product for the standard manufacturing process, avoiding unnecessary dedicated production lines.

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:

product definition; the interaction on and convergence to a common view between marketing (on behalf of or even involving the customer) and engineering (architects, lead designers, project leader) on the to-be-developed next product. This phase can also be reviewed and gated, like the PCP.
project planning; realistic yet ambitious project set-up, given the required complexity, timing, intermediate deliverables, technical risks, available competencies and available resources from all contributing functions.
making the business case for the next product (family)
project prioritization; essentially ranking the order of next projects based on business priority, expected return and risk
resource allocation process; essentially mapping the to-be-executed projects on the available resources. Projects that are not staffed should not be started until the resources come available!
final project selection and kick-off decision making. After this step the project is under the PCP for execution.

Although the above may sound simple, in actual fact this PSP is in most companies very weak, unstructured or worst case absent. As such it is one of the root causes for bad R&D execution.

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:

pre-development should be tightly inked to the roadmaps (see next), de-risking the next product or generation. It is NOT intended to be exploratory research, although that might be desired NEXT TO pre-development. But having both research and pre-development means there are 2 hand-overs, which is usually not good for fast execution. There are very few markets that need and can afford this three-stage approach!
internally or external; internal pre-development makes the hand-over to product development easier, but at the risk that the resources are "stolen" for short-term development projects.
dedicated pre-development people or teams, or (almost) all engineers to be involved in pre-development on a rotating basis?
how much pre-development? Too little reduces innovation in the new products, too much can not be absorbed by the product development processes.
and there is an even more conceptual debate on this topic: instead of the "standard" sequential pre-development-product-development approach, bring it together by having all innovation under the product development. In fact the standard approach of most start-ups. An interesting risk-reward discussion!

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.

are they structured per market segment?
are they over-crowded (no focus) or too empty (no plans)?
is there consistency in the underlying technology use?
is there sufficient innovation per (main) step?
are they at least 2 generations out?
do they show the right balance between new main platforms and derivatives?
are the underlying technology and product roadmaps properly synchronized?

Although the resulting roadmaps may look surprisingly simple (and they should!), getting there is an intensive process. Having all relevant voices into the discussion is prerequisite for a solid and balanced roadmap. But having an - independent - experienced discussion leader and coordinator is often required to come to a meaningful result. See under Services!

R&D Organization

Example of a three-layer business structure (BU-BL-PL) and the integrated functional reporting of R&D. In this example PL R&D is under the Business Line R&D manager for more synergy and less scattered sub-critical teams.

Typical (but not the only!) department structure of a semiconductor development 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:

a balanced R&D reporting structure, between the operational business execution and functional reporting to ultimately the CTO. Which reporting axis is responsible for what?
the boundaries of R&D responsibility, especially on the non-development functions like project management, test and product engineering, application support, quality, documentation, lay-out etcetera.
progress reporting flows; who reports what, how is it consolidated upwards, when and where is it reviewed?
site policy. Although new sites are usually imposed on R&D from acquisitions, R&D site policy has a major impact on efficiency and effectiveness. Big centres with small satellites or all sites fully independent with all support functions? How to keep all sites connected? And of course the discussion on R&D in remote because supposedly cheap sites and all its pros and cons.
R&D in the businesses vs. Central R&D. A usually highly political discussion, where either of the two extremes can have disastrous effect on R&D effectiveness.

Additionally there are other topics, more related to optimising the R&D performance:

implementation of a dual ladder system or similar, to offer career opportunities and recognition for the key technical experts.
competency management, to connect experts working on the same technology across the company.
training, both on individual level but also events like internal seminars or conferences
stimulating and managing patent generation. (Useless patents are an expensive hobby!)

Since almost all these topics have a scope that goes beyond the individual R&D teams, an effective implementation of all this depends strongly on the power and effectiveness of a company-level R&D board, usually led by the CTO or Engineering Manager.

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:

tool performance and efficiency; does the tool indeed provide the claimed productivity improvement, making it worth its money?
flow integration; to complete e.g. an IC design multiple tools are required, each performing its own task, integrated into what are called design flows. Suppliers, but also foundries, will push for integrated flows from a single supplier, but is this the desired situation?
integral EDA cost. In advanced IC-design the EDA cost per designer seat can be around 30% (especially in low labour cost locations) but increase to 50% in case of e.g. digital back end verification. Keeping control of EDA cost is thus very important and requires active supplier and tool portfolio management. How to allocate cost; per seat or based on actual use?
tool standardization; this is probably the biggest headache, since every engineer is deeply attached to the tools he/she is using, and even the suggestion to switch to another tool can meet deep resistance. Standardization of tools in big companies, required for cost decrease as well as inter-working between sites and groups, is thus a very time-consuming activity. Which re-starts with every acquisition!
legacy tool management; although one can switch over to new tool sets for new designs, the old design must still be accessible in case of e.g. quality issues. Especially in the Automotive market this is required for up to 15 years, demanding some sort of archiving of legacy design flows.

Next to EDA there is a second set of tools that is not so much focused on the design but on the co-operation and interaction within and between teams:

collaboration and productivity tools; especially in case of multi-site developments it is important that everybody is working on the latest design version, that issues are centrally collected and tracked, and that project management can have a full overview of the project status.
verification and validation (V&V) flow; in order to avoid re-writing of specification and test requirements it is much more efficient to work on the basis of an integrated V&V flow, where specs are management in a single V&V data base and handed over from architects to design to verification to validation and finally operational testing. V&V increasingly will be integrated into tool (flows) because otherwise design complexity becomes unmanageable.

And finally the Information Technology (IT) infrastructure should not be forgotten. EDA is only the tool, which must run on a combination of PC/workstations, requires increasingly enormous data storage, requires worldwide availability and tracking, data exchange between remote sites, quick installation in case of new employees or sites, and all that with as much as possible on-site support. Engineering IT and EDA are thus both extremely and equally important.

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:

Scatter, which causes defects or waste because the right knowledge doesn’t get to the right place. Management is often the biggest source of waste! Well-known scatters are adding more people to a team in trouble instead of identifying the root cause, or starting new projects before the previous ones are finished (pipeline overloading!).
Handoffs; a hand-off occurs when we separate knowledge, responsibility, action and feedback. Decisions have to be taken by people who don't have all required data/knowledge and/or are not in the position to drive execution. This often happens when organizations are split into many (small) teams focused on only one single task. So .. handoffs create finger pointing, inefficiencies (waiting time between teams) and errors (“I thought the other team would do it”)
Wishful Thinking; a behaviour strongly related to risk avoidance, and denial of the fact that we mostly operate in a very dynamic environment. A good example is the specification and project definition document at the project start, which often is expected to specify every detail down to the last decimal, not allowing any deviations once the project has started. And of course the structurally optimistic shortest possible planning, not allowing for any hiccups or set-backs. There is never time to do it right … always time to do it over!

Although LEAN is primarily a mentality, there are very useful tools and methods to support it, e.g. Agile development (mainly used for software development), Value Stream Mapping and Kaizen. Implementing LEAN is a difficult but rewarding improvement way for each (R&D) organization!

LEAN in R&D

BACK

R&D Processes