Project Management
Introduction
This project discusses the risk management plan that helps to identify the risks that are associated with the project. At the same time, for the identified risks in the project the risks are analyzed, risk responses plan is developed for the identified risks. This project is also helpful to discuss the process of planning and monitoring the identified risks.
Executive Summary
This paper discussed the risk management plan and identified the risks that are associated with the project. The project has also analyzed the risk, developed the risk responses plan for the identified risks, also developed a plan for monitoring and controlling the risks identified. The justification has also been discussed for the proposed risk management plan.
Background of the case study
There is an organization known as OIT. It includes four major departments: the Computing and Network Services Department, the Information System Department, the Instruction and Research Services Department, and the User Support Services Department. Some of the departments use different ticketing systems while some others.
Risk management plan
- Identify the risk: OIT uses a ticketing system to report the bugs across the various departments. At some point, the Remedy ticketing was been used while not all the departments needed the ticketing system which supported Remedy (Grobauer et al., 2011).
- Analyze the risk: Some of the department uses different ticketing system software- Request Tracker or RT and Remedy so there exit a gap in the way information is processed. The front-end uses Remedy, must manually translate the message from the remedy format to the RT format so that it can reach the back-end users. It creates many problems like it is time-consuming and also resources consuming.
- Evaluate the risk: The risk was that Remedy worked fine with the front-end side of OIT but at the same time, the back-end was maintained by UNIX.
- Treat the risk: The way adopted to treat the risk is that replace the Remedy with the Request Tracker. This will help the company as the Request tracker tool is already been used by some of the departments so they won’t need much time to teach the departments which earlier used Remedy.
- Monitor and Review the risk: The project is monitored and controlled by emails and a ticketing system (RT). To manage the project effectively the UNIX team and other back-end teams use RT.
Identify risks associated with this project
OIT is a functional organization that uses a ticketing system to report the bugs in between the various departments that maintain the IT system at the SFSU level; from the front-end (user interface) to the back end (database, server, network). . There were some departments which use Remedy ticketing system but this was not supported by all the departments. Some departments use different ticketing systems so it became difficult to process the information. Another risk was that it too long to convert the messages from Remedy format to the RT format which results in making the response time relatively slow.
Risk analysis for identified risks
Some departments use request tracker, or RT (UNIX- based) and some Remedy (windows-based) so it became difficult to process the information. The Front-end side uses Remedy and the back-end use RT so it becomes difficult to convert the message from the Remedy format to RT format. So, all this process results in consuming more time and consuming more resources. Also, Remedy provided many features which are not needed by OIT such as finely detailed features which are not required or do not fit the OIT organization (Sagiroglu, and Sinanc, 2013).
Risk responses plan for identified risks
The risk was that Remedy worked fine with the font-end side but the back-end was maintained by UNIX. So the organization OIT adopted ways to treat this risk. The OIT organization replaced the Remedy with the Request Tracker. This will help the company to save time as well as resources. This results in helping the company as already some of the departments was using this ticketing system software (Almorsy et al 2011). So it took less time to learn the system by the other departments which earlier used Remedy. This was implemented as Remedy features made the reporting process confusing for people to understand. Some of the information was also lost during the translation, as the front-end uses remedy so the messages should be converted from the Remedy format to RT format for reaching the back-end teams.
Plan for monitoring and controlling identified risks
The plan for controlling and monitoring the identified risks was that the company planned to monitor the project through emails and a ticketing system (RT). Further, the UNIX team and the back-end teams also made use of the RT to manage the project. They sent a “ticket” if they need an action item to get done. The action items came up on the fly sometimes and were assigned to people who will volunteer to take the action as per the capabilities and availability. Mainly they have used emails to communicate and manage projects with the team members (Jansen, 2011).
Justification of your proposed risk management Plan
The risk management plan which is been laid down is effective in controlling the actions taken. Request tracker is been replaced by remedy because the remedy system was used by some departments not all. Using this system resulted in time and resource consumption. So the company decided to replace it as it will help to save time and resources. Further, the remedy has some of the features which are not required by the OIT like the detailed forms that request much information which fails to fit with the organization like OIT (Almorsy et al., 2011).
Conclusion
It is been concluded from the above project that OIT use ticketing system software to report the bugs that are among the different departments which maintain the IT system. The OIT has also replaced the remedy system with the Request Tracker system. At the same time, it is also concluded that the Request tracker is more effective than the remedy as it takes more time and resources. Additionally, the company has used emails and RT to manage the project.
References
Grobauer, B., Walloschek, T. and Stocker, E., 2011. Understanding cloud computing vulnerabilities. IEEE Security & Privacy, 9(2), pp.50-57.
Jansen, W. A. (2011, January). Cloud hooks: Security and privacy issues in cloud computing. In System Sciences (HICSS), 2011 44th Hawaii International Conference on (pp. 1-10). IEEE.
Almorsy, M., Grundy, J., & Ibrahim, A. S. (2011, July). Collaboration-based cloud computing security management framework. In Cloud Computing (CLOUD), 2011 IEEE International Conference on (pp. 364-371). IEEE.
Sagiroglu, S. and Sinanc, D., 2013, May. Big data: A review. In Collaboration Technologies and Systems (CTS), 2013 International Conference on (pp. 42-47). IEEE.