Arguing whether or not some work is research or development is all too common on software projects, especially in Software Research & Development (R&D) organizations. On many projects developers tend to declare a large part of the work as "research" and decide not to create any plans for it, postulating that "it is impossible to plan research." This, unfortunately, puts them at a disadvantage: they move forward on the project without a workable plan to guide them. Here are some tips to help you navigate this situation.
- Define research and define research milestones.
- Define development and plan & schedule development.
- Adjust your software process for research and development.
Research, at least as is used in R&D organizations, is an activity with the objective to invent something new, that has never existed. Research, as defined in the dictionary is: "the systematic investigation into and study of materials and sources in order to establish facts and reach new conclusions."
From an R&D perspective, the bottom line is that you have to break new ground. When you try to invent something new, you don't necessarily know when the great idea will come. This type of activity must be time limited. In most R&D organizations the research period tends to be anywhere between a few weeks to a few months.
Once the time allocated to research is exhausted, then you must evaluate the results, and decide about the next steps.
If the research objectives were not achieved, then the decision tends to fall in one of the following three scenarios:
- Continue with the research. Devote more time and perform additional research. Most likely commit more funds to the project.
- Change the solution strategy. Find an alternate solution based on known ways of solving the problem (maybe not as optimal or elegant as originally intended, or possibly more risky).
- Cancel the project altogether, since a solution was not found. This may sound too drastic, but at every milestone you need to evaluate the prospects of the project, and the exhaustion of the research time-budget is such a milestone.
If the research objectives were achieved, then you update your plan and proceed into development.
Development is an activity with the objective to implement the outcome of the research, at least as defined by most R&D organizations. Development tends to work with existing knowledge. Your research just came up with new knowledge, and what at the beginning of the project was unknown, now it is known and ready for development. Since you are building on existing knowledge, this activity can be planned and scheduled.
Many times when developers say that they are doing "research," they are looking to find knowledge that already exists, as opposed to inventing something new. The existing knowledge they are looking for is sample code, or work done by others or themselves earlier. This type of research sometimes is called "library search," or just "search." This search can be planned and scheduled, and as such it can be grouped with other development activities.
Adjust your process: How much research? How much development? As you listen to developers, you will come away with the impression that 80% of the project work is research, and only a small part is development. After working on a number of projects, I found that most of the work, probably over 80%, is in fact development, which includes search for existing knowledge. This conclusion is rather important, because development work can be fully planned and scheduled.
A small portion of the work, often 10% is truly research. This work should take place at the beginning of the project, because it constitutes high risk. Properly time-boxed, this high-risk activity can be dealt with, before the wast majority of the project's funds are spent.
In summary, if you appropriately separate research and development, then you can make project plans that will account for the risks associated with the unknowns. The challenge is to resist the temptation to call most work "research" and properly plan the work.