project management

Assignment Description Project risk management is critical for delivering successful projects. Most projects operate under the triple constraints of scope, schedule and budget. Project risk management provides a systematic process to manage risks without missing project deadlines, compromising scope and increasing cost. As a competent project manager you have been asked by the Vice President of Technology, Pike Gresham of the Silicon Forest State University (SFSU) to design a risk management plan based on the information provided in the case study below. Your document should include the following: 1. Introduction 2. Executive summary 3. Background of the case study 4. Risk management Plan 5. Identify risks associated with this project (case study) 6. Risk analysis for identified risks. 7. Risk responses plan for identified risks. 8. Plan for monitoring and controlling identified risks. 9. Justification of your proposed risk management Plan 10. Conclusion Comprehensive guidelines and procedures for managing risk are available from many published research sources. For this assignment you are required to follow the Project Management Institute process for managing project risks. BN205 Project Management Page 3 of 6 Prepared by: Samira Baho Moderated by: DR Karthik Nagarajan July, 2017 Case Study:The Ticketing System Mathias Sunardi The Office of Information Technology (OIT) of the Silicon Forest State University(SFSU) uses a ticketing system (software) to report bugs across different departments in OIT that maintain the information system at SFSU level; from the front end (user interface) to the back end (database, server, network). At some point, Remedy ticketing software was chosen. However, that decision was somewhat “flawed” in the sense that not all departments that needed the ticketing system supported Remedy. Remedy was Windows - based client software and it worked fine with most of the front - end side of OIT, but OIT’s back end was mainly maintained under UNIX. This led the UNIX team, and several other groups that maintained the back - end resort, to use a different tool (Request Tracker) which was Open - Source software, and worked under the UNIX system. This case discusses project communication management, among multiple departments involved in software development project. BACKGROUND The OIT is a functional organization. It is under the supervision of the Vice President of Technology, Pike Gresham. OIT has four major departments: the Computing and Network Services Department, which manages the network system at SFSU; the Information System Department, which manages and implements all administrative systems for the university including databases on UNIX servers; the Instruction and Research Services Department, which provides equipment, hardware, software, resources, training, and support to students, faculty, and university staff; and the User Support Services Department, which is essentially the interface for users: students, faculty, and staff to the rest of the OIT when help is needed with technology- related issues. The ticketing system is used throughout these departments to communicate all the technology - related reports, issues, and requests. Given that some of the departments use different ticketing systems — Request Tracker, or RT, (UNIX - based) and Remedy (Windows - based) — there exists a “gap” in the way information is being processed. The front - end side, which uses Remedy, must manually translate/convert the message from the Remedy format to the RT format in order for it to reach the back - end teams. This causes several problems. First of all, the process is time and resource consuming. It means that someone had to be on standby to do the “translation”, and it took a lot of time to do, which made the response time relatively slow. Second, Remedy is more of an enterprise - level tool that provides many features which are not needed by OIT, such as finely detailed forms that request much information which does not fit with an organization like OIT. Those features make the reporting process even more confusing to the users. And finally, some information might be “lost in translation” — when the message is translated, there may be some information missing or misinterpreted. This issue has been on everyone’s nerves for three years. IT STARTED OFF, FINALLY Ron Bashley has been working with OIT for three years and just recently has been promoted to Desktop Support and Project Coordinator. Ron was going through his daily email - checking ritual that he noticed an email from his manager, Baken Dryhed, the Director of User Support Services (USS) Department. The subject read: “We need to fix the ticketing system”. “Finally!” Ron screamed in his mind, “We’re going to do something about the ticketing system.” The body of the email was an invitation from Baken to all the users of the ticketing system for a meeting to discuss a solution for their problems. The meeting was to take place in their usual weekly meeting. The meeting was attended by everyone who had been invited in the email, which includes: Baken, as the head of the USS Department; Ron, who manages user interface with the ticketing system; Harry Bonnett, the BN205 Project Management Page 4 of 6 Prepared by: Samira Baho Moderated by: DR Karthik Nagarajan July, 2017 Director of the Information Systems Department; and the directors of Instruction and Research Services Department, Computing and Network Services Department, and some of their managers who work under them; and Bob Biyon, the Technology Manager from the School of Liberal Arts and Sciences. Bob is not working under OIT, but he uses the ticketing system to maintain the computer lab at the school. Together, they formed a committee for the project, as is usually required in most projects at the university. TIMELINE In the meeting, all attendees agreed that they have a problem with the current ticketing system and they need to find a solution for it. The university has been on a tight budget, and OIT is one of the departments that experienced the most severe budget cuts. The cost of licensing Remedy at $20,000 per year, along with earlier disappointments by several other third - party software companies, leads the team to decide to find an open - source software solution. Baken proposed that the project be done in a year. Based on resources availability, Ron and Harry thought the project could be done sooner than that. They proposed that the project be done in six months. For the following few weeks, the team collected requirements from everyone in the meeting: what they wanted the software to be able to do; what they hated about the current system; etc. Ron and Harry and their teams were responsible for investigation into the search for options. Through their email mailing list called Listserv, the users passed along their new requirements, in addition to the ones already mentioned in the first meeting. These requirements were collected, and, together with the options they found, were brought to their weekly meetings to be discussed. DECISION The whole information - gathering process took about three months before they reached a decision. After considering all the requirements and the available options, they decided to replace Remedy with Request Tracker — the tool already being used by some of the departments in OIT. This was a good thing for them — Since the software was already in use, they wouldn’t need to spend a lot of time learning how to use it, and the change would only be implemented in the few departments that previously used Remedy. MAKING IT HAPPEN For the migration process, Ron became the team leader, and his team consisted of himself, Harry from the UNIX department, and one programmer from Harry ’ s group. In addition to being the team leader, Ron was responsible for creating the user interface, and Harry and his team were responsible for replacing the Remedy system — patching, updating, and so on. From this point forward, the committee from the previous meetings did not meet any longer; only Ron and his team met weekly and discussed progress. Ron described the whole process as being “very informal.” The action items sometimes came up on -the- fl y, and were assigned to whoever would volunteer to take action according to their capabilities and availability. One major concern for Ron was communications. This is a cross – departmental project — Ron reports to Baken, his supervisor, and Harry and his team report to someone else, not Baken. With the way the organization is structured, Ron and Harry are basically at the same level. According to Ron’s experience, it is usually difficult to convince other departments on the same level to make time to work on this kind of a project, since they would be mostly focused on the department ’ s main responsibilities, and assign low priorities to those projects that come from other departments. The project is to be managed through emails and the ticketing system (RT). The UNIX team, and the other back - end teams use RT to manage the project; they mainly sent out a “ticket” if they needed an action item to be done. The person who would do the item is either assigned or they volunteer to pick up the action. After the person completed the item, a “reply ticket” will be sent back through RT, so everyone — especially the requester — knew who worked on the item, and when it was done. BN205 Project Management Page 5 of 6 Prepared by: Samira Baho Moderated by: DR Karthik Nagarajan July, 2017 However, Ron’s department and the rest of the front - end team do not use their ticketing system (Remedy) to manage projects in the same way. Rather, they mostly use emails to communicate and manage projects with the team. So in this project, when Ron has some requests and/or bug reports, he would send emails through the team ’s mailing list to Harry ’s team, and Harry and/or his team would send a ticket regarding Ron ’s requests which will be communicated with the rest of the team. The transition is expected to finish in six months as agreed in the meeting.