Posted: Wed Sep 05, 2007 8:04 pm Post subject: Jira implementation of Incident and Problem management
I’m following this forum since a while and now I’d like to drop my contribution to this interesting discussion.
I work for a little company (~ 70 employees) with an important customer base (~1500 customers that use our web application on a regular basis)
I’m trying to organise the support desk service, something new in the organisation; before it was managed directly by the development team. We have decided to follow the ITIL approach, mainly to adopt the incident and problem management (and eventually further on start working on the release and configuration management), so far I refer to V2.
I would like to make the adoption of the ITIL approach as smoother as possible and for this reason I’m trying to use Jira as tool to manage Incident and problem management.
-It is a tool already used in the company so most of the employees feel familiar with it
-Jira is not designed with ITIL in mind, therefore some aspects of the ITIIL Incident/problem management don’t fit comfortably or don’t fit at all in a Jira project.
To make simple the approach -that I’m already testing with real world beta use since a couples of weeks- is the following:
Use a dedicated Jira project to manage incidents (INC)
Use a dedicated Jira project to manage problems (PRB)
Add a set of rules for example:
Each time there is an incident log it in an INC ticket
Once you find several instances (tickets) of an incident that seem having a common root cause open a PRB ticket to manage it. All the related incident tickets should be Jira-linked to this ticket.
In my vision the PRB project should work as tool to structure problem management and also as a first level of Knowledge base. It is there that you should store the workaround information if it exists.
I won’t go further with the description to avoid annoying you with a too long post but I could easily add many other rules/considerations. I would like to know if someone else has already tried to use Jira for this intention.
Questions are welcome,
[Edited by Admin: Please do not place links in posts]
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed Sep 05, 2007 10:18 pm Post subject:
I think you're trying to over-complicate the implementation by how you're planning to use the tool.
First, let me say to you that you're correct. That tool was never designed with ITIL in mind and it will be extremely difficult to use it to implement an ITIL solution that can scale, as you grow. That being said, I've always like the tool and the concepts behind it. The creators of that tool share the "collaboration and centralization through virtualization is good" mindset that we, ourselves, adopt for our own implementations.
If I remember correctly, the big limitation is that the tool has very poor "cross-project" reporting, which is why I believe that you're trying to create two separate projects for Incidents & Problems. If my interpretation is correct, you're trying to have centralized places to register, track, manage, and see your Incidents & Problems.
However, if I remember correctly, Jira is set up to track and manage product issues within the individual product "project". The premise of the system is that everything developers will need to work on will be contained within the ecosystem of a "jira project". If you start to track things outside of those projects, you will make it hard to assign those items to the appropriate projects that will need to perform work on them. Keeping the Incidents in their own project seems to be less of an issue than the Problems, as the Problems almost always represent things that need work to be done by the developers and/or engineers (such as defect root cause analysis and correction). If you do use a separate project for Problems, it sounds like you will double-book your Problems when you go to create a new one, specifically within a product-specific project, that will allow the developers/engineers to work with that ticket and manage it through completion.
Remember, the developers are already managing "Problems" and "Incidents" today. They call them, both, "Issues" and enter "Issue" tickets in their project spaces. They then manage these Issue tickets through completion. In essence, what you're doing is formalizing the separation of Issues into two distinct categories called Incidents & Problems.
Example 1: A regression test fails and a developer adds an Issue ticket to address this. In ITIL, this is an Incident.
Example 2: A developer finds a bug or has one reported by a customer and enters a Bug ticket, to track and manage through completion. In ITIL, this is a Problem.
Realistically, in both examples above, there is a high probability that the developers are using one ticket schema structure. You may want to start by ensuring that tickets all have an extra attribute that allows you to simply categorize each one as an Incident or a Problem and go from there.
I hope this helps.
Frank Guerino, CEO
On-Demand ITIL Platform
Before going more into details let me point out the directions I follow in my work.
1) We are a little company and at this point we don’t have the means to put in place a veritable ITIL “revolution”.
2) The aim of establishing an independent service desk function with incident and problem management in my company. It is not only to boost quality of service (that honestly is already quite good) but more to make possible to have an outer vision of the quality of the service and eventually be able to measure it. So far only product managers have a detailed vision on what’s going on and each one with a limited scope (his own product).
In reason of point 1 I’ve chosen to implement some ITIL processes using Jira. I prefer to do something limited but that can work than start a project that is over our possibilities, two evident limits:
-It’s hard to make people use a new tool in general, imagine if you cannot assure (due to the limited means ) a good change management.
-Even considering an open solution like RT (so no licence costs) more flexible than Jira and I think more adapted to implement an ITIL approach, even accepting the related risk of change (use of a new tool), I still see serious issues of integration with Jira, the tool that development will continue to use to track the product advancement. So I still prefer to use Jira for Incident and Problem management.
In reason of point 2 I’ve thought to introduce an inner layer (a Jira project dedicated to problems) between incidents tickets and bug tickets. Example:
Support opens three tickets on similar incidents concerning the impossibility of downloading the monthly digest spreadsheet for the application MoneyMaker.
Support opens a problem ticket and links the three incidents to that problem.
The problem manager after a first analysis feels this is network issue and assign the problem ticket to the production servers manager.
The production manager reject this hypothesis “network work fine in upload and download, this is a bug mate!” and assign the ticket back to the problem manager that assign it to the MoneyMaker product manager.
The product manager says “yes, this is a bug” and opens a ticket in the Jira project MoneyMaker and assign it to a developer.
Developer fixes the bug and resolves his dev ticket, the fix is delivered to production and so the problem may be put to resolved, and so the underlying incidents may be closed.
I agree with you that this organisation introduce somehow a kind of “double booking issue” for problems but
-this make possible to have a tangible problem repository (all the problems are managed in the same logical environment: the Jira problem project)
-all the references across projects (incidents, problems and bugs) are managed within the same tool, so in an easy way. (No tool integration nightmares!)
-remaining within the same tool should make easy to sort stats and then metrics, by attacking directly the Jira DB
Having said that I still feel insecure about the risk of adding too much complexity to the existing un-formalised issue management processes
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum