What resources are required for R&D activity?
Discuss critically the availability of relevant resources for R&D in India.
Ans 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
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. Risk
diversification is a sound approach when there is a mandate to innovate.
Freezing
specifications
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.
No comments:
Post a Comment