Have you ever noticed that the world views Research and Development so synonymously that R&D has become one word.
But one thing I get asked a lot is whether or not the research and development components of a new product program should be separated—not if they should be located in different places, but if they should be treated as different activities.
There are two things you have to consider to answer this question:
Consideration 1: Is your research activity fundamentally more risky than your development activity?
The answer for most companies is an emphatic yes. Take the example of a drug company looking for a cure for any particular disease. In the research stage, they screen thousands of molecules and can easily come up dry. The time to find a solution is both uncertain and unknowable—both indicating high risk.
On the other hand once a class of compounds is identified and a specific molecule is shown safe and effective, drug companies can at least estimate how long it could take to get through Stage 1, 2, and 3 trials. Sure, the trial results are still uncertain, but the amount of risk drops with every step forward in the development process.
Of course, not all situations are as complex as pharma. But if your program requires the understanding and adoption of a new technology, the risk profile will still be high—especially if you try to learn and validate the new technology as part of the development phase. Separating the activities allows you to think about and manage them differently.
Consideration 2: If the risk profiles are dramatically different, how can you decouple them?
Because discovery often constrains pharma companies, most divide their R&D into completely separate activities where developments are actually driven or triggered by research discoveries.
For industries where finding unmet customer needs is the constraining factor, some research or technology development often becomes part of the project. You can separate the risk by using a staged development process with technology development being a key part of feasibility.
If you are managing projects with a Critical Chain approach (CCPM), this also impacts the amount of buffer required. Breaking projects into sub projects allows you to buffer each part according to the level of uncertainty.
