Project Management


This project discusses about 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 developed for the identified risks. This project is also helpful to discuss the process of planning and monitoring of 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 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 department use different ticketing systems while some other.

Risk management plan

  1. 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).
  2. 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 resource consuming.
  3. 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.
  4. 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 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.
  5. Monitor and Review the risk: The project is monitored and controlled by emails and ticketing system (RT). To manage the project effectively the UNIX team and other back-end team use RT.

Identify risks associated with this project

OIT is a functional organization which uses ticketing system to report the bugs in between the various departments that maintains 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 department use different ticketing system 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 department use request tracker, or RT (UNIX- based) and some Remedy (windows-based) so it became difficult to process the information. Front-end side uses Remedy and 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 does not fit 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 its time as well as the 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 to 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 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 the 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 department not all. Using this system resulted in time and resources consuming.  So the company decided to replace it as it will help to save time and resources. Further, 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).


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 Request tracker is more effective than the remedy as it take more time and resources. Additionally, the company has used emails and RT to manage the project.


Grobauer, B., Walloschek, T. and Stocker, E., 2011. Understanding cloud computing vulnerabilities. IEEE Security & Privacy9(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.

Leave a Comment