Header

Thursday 22 August 2013

MS 58 IGNOU MBA Solved Assignment -What resources are required for R&D activity? Discuss critically the availability of relevant resources for R&D in India.

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