Silicon Forest University Project Management Risk Report

This report provides a comprehensive analysis of a project management case study at Silicon Forest State University's Office of Information Technology (OIT). The OIT faced communication challenges due to different departments using varied ticketing software. The project aimed to implement Request Tracker across all departments. The report details the risk management plan, including risk identification (cross-departmental collaboration), risk analysis, and response strategies. It outlines plans for monitoring and controlling identified risks, justifying the proposed risk management approach, and concluding with the benefits of implementing a unified ticketing system. The implementation of Request Tracker aimed to improve communication and efficiency, replacing the flawed Remedy software. The report also references several academic sources.

Running head: PROJECT MANAGEMENT
PROJECT MANAGEMENT
Name of the Student
Name of the University
Author Note

2
PROJECT MANAGEMENT
Table of Contents
1. Introduction..................................................................................................................................4
2. Background of the case study......................................................................................................4
3. Risk management Plan................................................................................................................4
4. Identify risk associated with this project (case study).................................................................5
5. Risk analysis for identified risks..................................................................................................5
6. Risk responses plan for identified risks.......................................................................................5
7. Plan for monitoring and controlling identified risk.....................................................................5
8. Justification of your proposed risk management plan.................................................................6
9. Conclusion...................................................................................................................................6
10. References..................................................................................................................................7

3
PROJECT MANAGEMENT
Executive summary
The office of the information technology in the silicon forest state university uses a ticket system
software remedy in order to report bugs across the different departments in OIT. The main drawback
was that other department used different applications as result of which communication between the
departments were not so easy. After gathering requirement a common application was taken up which
was Request tracker which would be implemented by all the departments so as to achieve easy
communication possibilities.

4
PROJECT MANAGEMENT
1. Introduction
The office of the Information technology (OIT) of the silicon forest state University (SFSU)
uses a ticking system in order to record bugs across the various department in the OIT in order to
emphasize on maintaining the information system as the SFSU level. This is mainly done with the
prospective of the front end which mainly include back end user interface which include network,
database and server. A software which is known as remedy was chosen. This decision with the
implementation of the software was somewhat “flawed” this is due to the fact that not all the
department within the concerned organization support the software [1]. The software worked well for
the front end of the OIT but it was a concern with the back end because the back end worked under the
UNIX system
2. Background of the case study
The OIT (Office of the Information technology) is mainly a functional organization. The
company mainly has four major departments which included the information system department,
computing and networking service department, the inspector and the research service department and
the student support [6]. The different department used different ticketing software as a result of which
there lied a gap in means of how the information is being processed. The main process in the system
was that the front end used the remedy which of translated or converting the message which was the
format of the message used by remedy with regards to reaching the back end team.
3. Risk management Plan
In a meeting, the body of the concerned organization agreed with the fact of the problem in their
hand with the system involved in ticketing and they need a solution to the problem. With regard to the
university it was on budget constraints and the OIT is among one of the many departments in the
concerned sector that experienced the most severe budget cuts. Through the use of their emailing chain
the users passed along their own requirement [5]. These suggestions were addressed in their weekly
meeting. The whole process in order to implement and set a goal took about three months of time.
Taking into consideration of all the aspects of the requirement and the scrutiny of the options available,
they decided to replace remedy with request tracker. The request tracker was used by some of the
departments of the OIT. Since the software was already in use, the time spend on learning how it works
can be reduced greatly and with regard to the change it would need changes in only few departments.

5
PROJECT MANAGEMENT
4. Identify risk associated with this project (case study)
One of the most concerned factor with the implementation of the project was that the project is
a cross departmental project. According to the case study Ron reported to Baken who was his superior
and Harry and its team reported to someone else not to Baken. The procedure in which organization is
structured is become very difficult to convince other departments which were on the same level to work
on this kind of a project. This is due to the factor that the other departments would be focusing on their
own responsibility and would indirectly give less propriety to those projects that mainly come from
other department [7].
5. Risk analysis for identified risks
The risk analysis was that the project would be thoroughly maintained by emailing and the
system of ticketing which was request tracker. The team UNIX and other back end time used the
request tracker in order to manage the system [3]. In order to manage the project they usually send a
ticket when they required an action item to be done.
6. Risk responses plan for identified risks
The response of the ticket generated whenever there would be an action required would be
taken care of by the expert who would be from within the organization or a volunteer not from within
the organization.
7. Plan for monitoring and controlling identified risk
In order for the monitoring aspect after the ticket is generated the task goes to the Planning for
monitoring and controlling identified risks expert who would be from within the organization or a
volunteer not from within the organization. After the concerned person completes the task, a reply
ticket would be generated which would be send back through the request tracker [4]. The main aim of
sending the reply of the ticket generated is that, everyone especially the person who has generated the
ticket would be able to know who had worked in the concerned situation and in further problem from
the same sector can be addressed by the same personal. This would directly reduce the cost related
factor because the concerned person would have pre knowledge of the system and the time required in
order to know the system would be minimized [8].

6
PROJECT MANAGEMENT
8. Justification of your proposed risk management plan
The risk management plan is justifying in the sense that the total implementation would be
taking a time of six months if the proposed plans every made and justification is given to each of the
implementation [2]. The plan would be beneficial since all the departments would be working on the
same software and before this implementation the time which was taken in order to transfer message
would be decreased highly.
9. Conclusion
It can be concluded from the report that the overall change of the ticketing software would be
highly beneficial for all the departments in the concerned case. Before the implementation of the new
ticketing software which is request tracker, remedy was used and there was one more problem that each
and every department would be involved in different ticketing application as a result of which the
communication between them was very difficult rather inappropriate. The new implementation which
is the request tracker would be a common application for all the departments. The main advantage with
the implementation of the ticketing application request tracker is that it was used before in some
departments this is beneficial because the time needed in order to know how the system works would
be decreased considerably and the implementation of the application would be quite easy as well as
working with the application.

7
PROJECT MANAGEMENT
10. References
[1] Balakrishnan, Srinivasan, and Mitchell P. Koza. "Information asymmetry, adverse selection
and joint-ventures: Theory and evidence." Journal of economic behavior & organization 20.1 (1993):
99-117.
[2] Drucker, Peter F. The Theory of the Business (Harvard Business Review Classics). Harvard
Business Press, 2017.
[3] Orlikowski, Wanda J., et al., eds. Information technology and changes in organizational
work. Springer, 2016.
[4] Orlikowski, Wanda J., et al., eds. Information technology and changes in organizational
work. Springer, 2016.
[5] Sabherwal, Rajiv, and Anand Jeyaraj. "Measuring the business value of IT: simplify with
caution." LSE Business Review (2016).
[6] Schulze, William S., et al. "Agency relationships in family firms: Theory and evidence."
Organization science 12.2 (2001): 99-116.
[7] Tallon, Paul P., et al. "Business process and information technology alignment: construct
conceptualization, empirical illustration, and directions for future research." Journal of the Association
for Information Systems 17.9 (2016): 563.
[8] Teece, David J., et al. "Understanding corporate coherence: Theory and evidence." Journal
of economic behavior & organization 23.1 (1994): 1-30.