Ticket Management System (TMS) - Overview

TMS has been created having in mind the need to create a communication interface between customers, coders and project/team leaders in order to help and automate traditionally "time consuming" procedures in a typical project life cycle.

These procedures have to do mostly with inter-person communication, information flow and tracking: the distinct lack of professionals with the competence to deal with these issues has often a negative impact on the project life, leading to loss of information, loss of precious time (and precious money) and, in short, loss of project profitability or diminished product quality.
br> The third aspect TMS wanted to explore was customer relationships. One of the most time-consuming and entropy-generating activities in project management, either at design time or at manteinance time, is dealing with the customer. In plain wording, dealing with confused project requirements and end users that are even more confused is extremely time-taxing: if we add to this the absence of an automatism to trace the information passed from user to developers, actual (evaluated) needs and some planning we come out with one of the most entropy-generating situation of modern project building.

TMS provides automated and extremely simple-to-use functionalities for a quick solution of these issues, without having to resort to dedicated professionals (lacking in most non-large projects), adhering to extremely detailed software engineering normatives (like ISO-12207 or ESA's PSS-05) or having to force professional developers into wasting their precious time in activities that aren't strictly "productive". All of TMS' solutions for the problems above are strictly coupled togheter, in order to provide end users, developers and project lead with all relevant information at a glance, with "relevant" meaning "relevant to their point of view of the project".

The intuition that led to the creation of TMS spews forth from the concept of "Trouble Ticketing", a paradigm mutuated from the world of Network Management. Trouble Tickets relate strictly to problems or, generally speaking, issues that are ordered by priority and (in TMS' case) deadline; A Trouble Tickets is created and "floats" until its priority and urgency demands solutions and treatment.
TMS implements this relatively easy paradigm at its state-of-the-art, adding much more information and functionalities typical of the world of project management (which isn't much different from the original Trouble Ticketing idea).
The realization of its finalities and implementation of the paradigm are made via an easy and lightweight WEB interface, whose portaling functions are created with the aim of pointing out clearly roles, information flows and work organization in the project's life. TMS' interface provides different functions and different information to different user classes, and is able to function as a project management tool, a work scheduler and trouble ticketing system, a customer care relationship team, a support team management tool, a project manteinance portal... and much, much more: with TMS all the information otherwise buried God knows where is no more than three clicks away.
Moreover, the Web interface allows for a system use outside the production environment, for easy integration in already existing Customer Care systems, and easing up installation issues (there is simply no software to install save on the server machine); it allows all involved people to be connected to the project "hive mind" everywhere with a simple mouse click. In the era of distributed teams, cooperative projects and Internet this can be a potential life-saver.
For those not familiar with the idea of Trouble Ticket, here is a quick explanation of the typical life cycle of a simple TMS ticket.

• End user (called Customer in TMS), or development team members (called Operator), opens a ticket. A freshly created ticket is placed in Pending status, and calls out to the Supervisor (project lead) for evaluation, usually via an automatically generated e-mail. A pending ticket always floats to the top of the ticket list, since unplanned work is always the most critical.
• The supervisor evaluates the ticket: evaluation means assessing gravity, versioning, category within the project, and assigning it to a project operator. The ticket now floats on the operator's list too, and this information automatically reaches the operator via an email message (or SMS). The customer, too, is informed of ticket status. A ticket so evaluated goes into Assigned status; all evaluation data is saved. Of course the supervisor can reject the ticket, putting it in Rejected status and prematurely ending its life.
• The operator works on the ticket (exchanging mails and ticket-related messages if he so wishes in the meantime) and at the end calls out (via the TMS) for closure. The operator places the ticket in Closeable state, a state in which the ticket is almost closed but needs supervisor approval. Relevant data are, of course, saved into the ticket.
• The supervisor, warned by the TMS of the potential end of the ticket, reviews it and puts his/her "final word" into it, either transitioning it to Closed state, or reverting it to assigned status if the operator's work was lacking in some way. In either way, relevant data is saved and involved people are automatically informed: in case of a ticket actual closure the customer is informed that his problem was solved.

This is only a short preview of a minimal subset of TMS' possibilities: there is much more detail into the Ticket concept (as well as the Activity concept) as presented in TMS.

http://tms.inera.it