Online Library Management System

Risk Management Plan

Version Number : 1.0 Version Date : 01/11/2013

1.0 Introduction
1.1 Purpose of Risk Management Plan
A risk is an event or condition that, if it occurs, could have a positive or negative effect on a projects objectives. Risk Management is the process of identifying, assessing, responding to, monitoring and controlling, and reporting risks. This Risk Management Plan defines how risks associated with the project will be identified, analyzed, and managed. It outlines how risk management activities will be performed, recorded, and monitored throughout the lifecycle of the project and provides templates and practices for recording and prioritizing risks by the Risk Manager and/or Risk Management Team.

2.0 Risk Management Procedure

2.1 Methodology
The project manager working with the project team and project sponsors will ensure that risks are actively identified, analyzed, and managed throughout the life of the project. Risks will be identified as early as possible in the project so as to minimize their impact. The steps for accomplishing this are outlined in the following sections. The Project Manager will serve as the Risk Manager for this project.

2.2 Roles and Responsibilities

Role

Responsibilities

Prateek Sharma as Risk The Risk Manager or Project Manager is a member of the Manager Integrated Project Team (IPT). The Risk Manager determines if the risk is unique, identifies risk interdependencies across projects, verifies if risk is internal or external to project, assigns risk classification and tracking number. Vinayak Goyal as Risk The risk owner determines which risks require mitigation and Owner contingency plans, generates the risk mitigation and contingency strategies and performs a cost benefit analysis of the proposed strategies. The risk owner is responsible for monitoring and controlling and updating the status of the risk throughout the project lifecycle. Integrated Project Team The IPT is responsible for identifying the risks, the dependencies of the risk within the project, the context and consequence of the risk. They are also responsible for determining the impact, timing, and priority of the risk as well as formulating the risk statements.

2.3 Budget and Schedule

A Risk Contingency Budget can be established to prepare in advance for the possibility that some risks will not be managed successfully. The risk contingency budget will contain funds that can be tapped so that your project doesn't go over budget. There is a total of Rs. 5,00,000 in the Project budget allocated for Risk Management activities. These activities may include, but are not limited to, identifying, analyzing, tracking, controlling, managing, and planning for risks. This also includes creating and updating the risk response strategies and contingency plans. Risks will be identified as early as possible in the project so as to minimize their impact.

2.4 Risk Categories

1) Market Risk - One of the most common risks in software project is to develop the project that no one wants. Market for which the software is meant should be well analyzed. The original idea and objectives should be kept in mind along the way. The library management software has a wide market as it can be used in every library so the market risk is low. 2) Financial Risk - It occurs due to wrong budget estimation, cost overruns, project scope expansion. Cost estimation has been done carefully and considering every aspect of scope. But still Financial problems do creep in the projects. 3) Technology Risk - Technical risks generally leads to failure of functionality and performance. Causes of technical risks are continuous changing requirements, no advanced technology available or the existing technology is in initial stages., difficult project modules integration. 4) People Risk - People risks are associated with the availability, skill level, and retention of the people on the development team. Eg, staff turnover, illness or inexperience. 5) Structure/Process Risk - It is associated with the selection of incorrect process model for the project which will lead to development of ambiguous project. It is the first step in project development so Process model should be chosen carefully otherwise the whole planning and cost get wasted.

2.5 Qualitative Risk Analysis

The probability and impact of occurrence for each identified risk will be assessed by the project manager, with input from the project team using the following approach: Probability High Greater than 70% probability of occurrence Medium Between 30% and 70% probability of occurrence Low Below 30% probability of occurrence

Impact High Risk that has the potential to greatly impact project cost, project schedule or performance Medium Risk that has the potential to slightly impact project cost, project schedule or performance Low Risk that has relatively little impact on cost, schedule or performance

2.6 Risk Documentation

1) Market Risk 1.1) Ambiguous requirements during requirements gathering which will lead to development of a product which wont be accepted in the market. The requirements gathering is one of the most important part of process. Probability : High Impact : High 1.2) Too many softwares of similar kind available in the market also results in less demand of your product. Care has been given taken in market analysis and found that there are not much softwares available of this kind so probability of this risk is low. But if, by chance, this happens then its impact will be high. Probability : Low Impact : High 2) Financial Risk 2.1) Wrong budget estimation may lead to withhold the project. Much analysis has been given in Cost Estimation. Every aspect of cost has been considered. Also, we have made a Risk Contingency Budget which will take care if there is some budget problem. Hence its probability and impact are low. Probability : Low Impact : Low 2.2) Project Scope Expansion or Scope Creep may occur during the development of project which may include or introduce more requirements that may not have been a part of the initial planning of project, while nevertheless failing to adjust schedule and budget. Probability : High Impact : High

3) Technology Risk 3.1) Sometimes, to meet the all requirements and integrate them into one project, the technology is not available or is not able to include all requirements. Our project does not have such problem as technology is easily available to integrate all modules into one. Probability : Low Impact : Medium 4) People Risk 4.1) High staff turnover will harm the productivity because there will be no continuity in the development of project. Each staff member who replaces the earlier one has to be made understood the whole project before he/she can start working on the project. Since our project is not going to take very long duration to develop so this risk has very low probability. Probability : Low Impact : Medium 4.2) Non-availability of technically sound people will slow down the development of project as they have to be trained first. Care has been taken in selecting the team members so that each is technically sound and can start working on the project as early as possible. Probability : Low Impact : Medium 5) Structure/Process Risk 5.1) Selection of wrong process model will lead to wastage of whole effort, time and cost. Waterfall Model has been selected for this project. It is one of the most important part of process planning. Each aspect has been considered carefully so that there is no wrong selection of process model. Probability : Low Impact : High