The Ticketing System

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 is 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, especially software bugs reporting among multiple departments involving in software development.

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. While he enjoyed his new position, he missed his previous office, where he had a nice big window to look out from the second floor of the building. His new office is located in the basement of a different, older building. Regardless, he is enthusiastic about his new position as it is the type of work he has been looking for.

It was July of last year, when 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 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 agree 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 think 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-fly, and were assigned to whomever would volunteer to take action according to their capabilities and availability.

One major concern for Ron was communications. This was a cross–departmental project Ron reported to Baken, his supervisor, and Harry and his team reported to someone else, not Baken. With the way the organization was structured, Ron and Harry were basically at the same level. According to Ron’s experience, it was 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. Although everyone on the team knew each other quite well, Ron proceeded with caution.

The project was maintained through emails and the ticketing system (RT). The UNIX team, and the other back-end teams used RT to manage their projects; they mainly sent out a “ticket” if they needed an action item to be done.

The person who would do the item was either assigned or they volunteered to pick up the action. After the person completed the item, a “reply ticket” was sent back through RT, so everyone especially the requester knew who worked on the item, and when it was done. However, Ron’s department and the rest of the front-end team did not

use their ticketing system (Remedy) to manage projects in the same way. Rather, they mostly used emails to communicate and manage projects with the team. So in this project, when Ron had 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 was communicated with the rest of the team.

Fortunately for Ron, the project ran smoothly with no major issues. The whole OIT team was used to working through emails, tickets, and such electronic media means. No formal forms or records were used other than the tickets and email records. The departments had a high degree of autonomy, and there were little or no interferences from upper management. The interaction between Ron and Harry’s team was almost seamless, and Ron’s concern about the project being cross-departmental and convincing the other department to spare some time to work on the project was unnecessary; everyone hated what had been going on in the ticketing system, and had been anxious to have something done about it, and finally they got the chance. The transition was done by November of that year, one month sooner than the expected schedule of six months.

Currently, the OIT uses RT throughout the organization and they continue to manage their projects using the software, as has been done by the back–end teams since the beginning. Although Ron knows that everyone admits that RT is not perfect, the fact that it is open-source, meaning it will be relatively easy for them to customize it, they were pleased with it, and they would happily say, “Hey, at least it’s not Remedy!”

Questions:

All questions are of equal marks, answer part (a) and (b) of the selected questions.

1. Based on the information provided in this case; [20 marks]
   1. The project does not have a project charter, describe the purpose of a project charter, when and how a charter is developed, and how the use of a charter may have assisted in the management of the project [10 marks]
   2. Design (draw) a high-level work break down structure (WBS) for the project, explain why a WBS is an important tool in managing a project, and provide a high level project scope statement based from the WBS and an explanation why a scope statement is [10 marks]
2. Based on the information provided in this case; [20 marks]
   1. Explain the concept and purpose of project governance, describe how project governance could have been implemented into Ron’s project (a diagram may be useful) and note what difference it may have made to the management of the [10 marks]
   2. Discuss the concept of project scope, change, schedule, and procurement management and their relationship to project governance. [10 marks]
3. Based on the information provided in this case; [20 marks]
4. In terms of stakeholder management, identify the project’s key stakeholders and explain the importance of each stakeholder to the project and place the stakeholders on a stakeholder map, [10 marks]
5. Discuss the linkages between the stakeholder management plan and the communications management plan, discuss the pros and cons of having a project communications [10 marks]
6. Based on the information provided in this case; [20 marks]
   1. Discuss the purpose and importance of a risk management plan, identify, analyse, and categorise the key risks to the project, describe a suitable response(s) (treatment) to each identified Also describe the relationship between risks and issues. [10 marks]
   2. In terms of the risk management processes, describe the relationship between risk management, scope management, project change management, and stakeholder [10 marks]
7. Based on the information provided in this case; [20 marks]
   1. With reference to PMBOK 6th edition explain the role of a project manager and the knowledge areas and how they contribute towards a successful project [10 marks]
   2. Discuss the authority of the project manager and their relationship with the key stakeholders, explain the pros and cons of using a stakeholder management plan and its relationship with the communications [10 marks]