The following is a collection of organizational and management tips and facts relating to some of the internal factors affecting the success of R&D and product development activities for innovation based industries. Most are simple, logical and describe 'obvious' truths for which paradoxically, implementation can be extremely difficult. The hardened professional may consider some of them whimsical or utopian because obvious truths and logic are often obscured by other mandates. Some of the 'tips' may appear to be counterintuitive. Many of them are based on my own experience. The reader is encouraged to critically consider these and make their own determination.
…for developing new products are technical feasibility, the existence of a market into which to sell the product and the business resources to make it all happen. When the new product is the result of basic R&D and is innovative, then each of these factors has to be able to accommodate the innovation. The new product development process is as a result fully loaded or stressed because the end result is likely to create changes in technology, the market and the nature of the business. Teamwork and planning are required not only to create the new product but also to prepare for the resulting changes caused by a successful new product.
This simple Venn diagram is very useful as a focus for understanding what is needed for an R&D project to be successful. The diagram comprises three separate overlapping circles or sets which give rise to four subsets, including one labeled Success. The circle denoted by the word Technical describes the set, or complete range, of all feasible solutions which satisfy the technical objectives of an innovation project all the way from Research to Engineering Development through to Manufacturing. Basically, it describes all identified solutions which can be implemented without disobeying any physical laws or requiring any non existent skills, materials or machinery. Marketing refers to the range of identified customer needs and preferences for this type of product and describes basically what will sell, versus the complete range of all the detailed aspects of unit cost, quantity, quality, format, functionality, specifications and so on. Business describes the full range of fits of the innovation versus corporate objectives, corporate structure, resources, management capabilities, current and long range plans and also legal aspects such as regulations governing the industry.
The white areas correspond to solutions which satisfy only one factor. Grey areas correspond to solutions which satisfy two out of the three factors and thus may represent potential projects in the remaining area, and the yellow area of course is the winner's 'circle' of solutions.
1. Teamwork: Technical, marketing and business departments must communicate their objectives, ideas and current solutions to problems and try to mutually support those solutions. Working in extreme departmental isolation limits the quality and flow of feasible solutions.
2. Buy-in: Scientists, engineers, marketing and business managers must all agree to a project at some point otherwise it simply won't happen. In particular, failure to obtain buy in for an R&D project, from senior management is thought to be one of the most common reasons for the failure of R&D projects. Have or request frequent senior management project reviews where objectives are reaffirmed.
3. Performance / Corporate Competence: There has to be an appropriate balance in skills and manpower in each category. Combine creative marketing personnel with creative scientists, engineers and business visionaries and you have an innovation dream team, (provided they agree to work together). Identify and strengthen the weak links.
4. If all else fails, compromise: (The most bitter pill.) Ideal technical solutions, ideal marketing solutions and ideal business solutions rarely overlap. The sad fact is that not every facet of a new technology, or its potential performance, will be needed, not every segment of a market reached, and sales are unlikely to reap such huge profits as to single-handedly solve the current fiscal crisis by the next stockholders meeting. Workable solutions need not be ideal. Optimum solutions giving rise to innovative products will frequently require internal compromises or changes in thinking. The alternative is a lost opportunity or what I call snatching failure from the very jaws of success.
R&D projects require a champion. If your project does not have one, get one as soon as possible. A champion is someone in an influential position who likes and actively promotes the project to the company. Champions emerge or are selected. They often come from technical or marketing and occasionally from business. Communication between the champion and the other departments must be good. Champions from marketing are often more effective. If a project is completed and still does not have a champion it will probably be shelved. This should be no surprise. It means that not even one influential person inside the company liked the project enough to fight for it.
This is sometimes an emotive question. Research labels are glamorous. Research departments feel superior to engineering development departments and so on. It is however virtually impossible to do research without doing some development work and vice versa. This is one reason the R&D description exists. However the categories are quite different and the differences are apparent in the objectives, expectations and results, and thus impact how projects should be planned and conducted. It is thus useful to correctly identify these activities.
It is Research if after you have done all the literature searches, sought and reviewed expert opinions and finally defined an approach, the main objective of a project defines something so new it is still uncertain whether or not it is even feasible. The parts of the project which tackle the technical fundamentals are basic research and the parts which make it possible to conduct are developmental. The key feature of such a project is a high degree of uncertainty in feasibility. The end result will be some form of prototype device demonstrating new technology.
It is Development if the basic technical feasibility of the main objective of a project is reasonably certain and is to build and demonstrate a fully functional model or engineering prototype.
Research and R&D: There are three things least certain at the outset of a new research project and these unknowns make planning the project an unconventional process and one which on conventional planning process diagrams is usually inadequately depicted via one or two boxes labeled 'feasibility phase'. The three unknowns are:
1. Feasibility
2. The resources needed to determine feasibility
3. How long it will take to determine feasibility
As a result, research project planning must incorporate best guesses of time to completion for tasks and milestones and estimates of required resources and these can be expected to change as progress is made, new tasks emerge, others tasks are abandoned and so on. There will be a tradeoff between resources(cost) and time but the tradeoff is uncharacterized.
Because of the uncertainties in feasibility and in time to completion one must never tie a research project to a production schedule.
Instead, one should conduct sufficient numbers of research projects so that the results of research are always available to inject into new product development schedules.
Development projects: Development of a new product also has it's uncertainties. However, technical completion is guaranteed if the basic technical feasibility questions have been satisfactorily answered in the research phase. Here there is the widely accepted tradeoff between the quality of the end result, the time it takes to obtain it and the resources required. Regarding resources, there is an additional consideration. Time to completion is the key consideration for a product development project. Unfortunately, the tradeoff between resources and time is non linear and occasionally an uncertainty. If a project takes twice as long to conduct as required, one may need to triple, quadruple or more the assigned resources to halve the completion time. In fact in heavily resourced projects increasing resources can actually slow a project down. The time at which this happens is called the crash point. A relevant analogy to bear in mind is three women cannot have a baby in 3 months. Without intending any disrespect, the crash point for this particular 'project' can be estimated at around 7 to 10 months.
Project planning software is useful in complex projects but cannot tell you how long individual tasks will take or predict crash points. The plan is at the mercy of the planner, who must be realistic in time estimates, the capabilities of resources, and able to anticipate tasks and alternatives. With respect to research projects, planning software can act as a useful reality focus for a new project by giving projections of milestones and completion times based on a series of initial guesses of the time to complete multiple dependent subtasks. It can help alert you to the impact of resource deficits or potential deficits. Other useful aspects of planning software are the capabilities to identify critical paths and to track progress and not least of all - it forces the planner to define and link objectives. For a research project, I have found it useful to include at the outset a few loosely defined, parallel contingency subtasks to include continuous low level research for alternative approaches for those longer range tasks which are more likely to dead-end. Project planning software can be useful as a reporting tool if used carefully to provide summaries. Care is required because printouts can be highly detailed and cryptic and thus overwhelming to the less informed reader, subverting the objective of the report.
The research is completed and now it is time to turn it into a product. "Anyone know where the engineering department is ?"
This is an important technology transfer stage and it has the potential for being the most stressful part of the project. It is highly advisable to try to avoid an abrupt transition between the research and engineering development phases. An abrupt transition, also known as throwing it over the wall, is implicit in linear project planning processes. Here I'm referring to the ones where one box labeled "feasibility" connects to another box labeled "product design" or "product development" with an arrow crossing a departmental dotted line. The problem with this technique is that engineering won't be prepared. Instead it is important to ease the transition between these major phases by merging them. The only way to merge these phases is to introduce engineering development personnel into, or at least near, the research project team, initially as engineering consultants or project observers. I recommend doing this at some time in the middle of the research project. IF all goes well, then eventually this involvement will lead to concurrent engineering and a less 'bumpy' transition between the research and development phases. Another outcome of merging these phases is the inverse process by which, after everyone has become friends, a few research personnel then remain attached to a project in a similar advisory capacity, even when it is well into the engineering development phase and virtually all of the research has been completed.
When the research and engineering departments are geographically separated by large distances, try augmenting communication via video-conferencing. If you do this, I recommend not wearing red colored clothing !
The outcomes of individual research projects are unavoidably uncertain. If this were not the case the projects would instead be developmental and there would be no need for research. Because of this there is a degree of risk of failure in any project. Just as there is a risk in investing in the stock market, successfully conducting research and successfully investing entails a realistic identification of, acceptance of and a strategy for managing - risk. (See risk strategy analysis at this site.) Risk diversification is a sound approach when there is a mandate to innovate.
During the course of an engineering development project, product specifications can change because:
1. the means for making a series of incremental improvements are discovered by engineering or parallel research - this can be expected,
2. marketing keeps adding features - this will eventually kill a project due to escalating costs and schedule overruns,
3. at a late stage, management wants an even better product for an even lower unit cost - unless a miracle happens, this will immediately kill a project.
Mid course changes in specifications of the first type can be accommodated, but risk slowing a project down if these are adopted too frequently. The improvements should therefore be noted as the project progresses and then incorporated all at the same time on at least one and possibly two scheduled occasions. At a certain point, specifications must be frozen and any changes which appear desirable but are identified after that time must be reserved for a possible future revision or mark 2 product.
The really good, fundamental new ideas usually come from individuals while they are relaxed and engaged in an unstructured activity. If you ask a scientist or engineer responsible for a successful, new fundamental concept how they came up with the idea, the chances are that they will not be able to tell you. Similarly, the chances are that at the outset of the project most other people thought that the idea was either wrong or so unconventional as to be crazy, and possibly even too embarrassing to mention in meetings. This does not mean that all crazy ideas are going to turn into useful, valid new concepts, but it does mean that a valid new concept can often be initially branded, and hence disguised, as a crazy idea.
'Craziness' is not a good indicator of the potential validity of a new idea - even if the brand is applied by an expert. This is because for truly new ideas, by definition there are no experts. Beware of reacting to and discarding ideas just because they initially appear to be crazy or stupid. This will limit the number of valid new concepts. Instead it is worthwhile to allow people a little extra time and resources to think over, refine and defend new ideas.
Limit the maximum size of working meetings where all are expected to participate to 6 people.
