We use JIRA for incident and problem management. We look forward to add change management in this group. Did any of you had to think about JIRA projects structure in this situation?
As of now, we have a project called "Incident management" and a separate one called "Problem management". We then create links between problems and incidents that are related. That being said, we want to avoid duplication of the information but should we still create a third project for change management? Maybe we should simply re-arrange the "Problem management" JIRA project so we also manage change request in the same container and find a way to tag problems and/or change request that will be part of a subsequent release...
Any feedback on this?
Absolutely.
The one I currently help look after is a bit of an evolved beast. Originally for a small Operations team, we put everything in the Ops project. As it expanded, and problem management started happening, we moved that out to a new project for that, and we're in the middle of moving "change and release" out to it's own project as well, so that Ops becomes a list of incidents and support requests. This is driven mostly by the size of Ops, but splitting them up gives us a bit more flexibility in the projects (the minor problems with keeping it all in one place are "mountains of data" and the assignee list)
We use links in much the way you do, although we've got a couple of extra reports which detail links.
The diffences are simple within the project though - we use different issue types to represent the different, well, types of task - changes, incidents, tasks, etc.
Thanks Nic for your feedback. Are there any plugins you're using specifically helping monitoring the implementation of ITIL best practices? On my end, I am currently testing JIRA Clone Plus which should facilitate the creation of a problem (originated from an incident in a different project) and change requests (which are linked to problems in a different project).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can't go wrong with the Jira Suite Utilities, and the Jira Toolkit, but those are things I'd recommend for any installation.
We don't tend to clone the incidents into problem management items - it's a perfectly valid thing to do (especially if you're going to use a plugin that will enable you to drop the stuff you don't want to inherit from the incident), but our problem managers wanted simple clean empty items written up to suit them. I think it's because most incidents get reported several times - symptoms rather than actual cause. They insist on linking back to the incidents that the problem caused, which is handy.
We do use the "issue links matrix" plugin, plus another report that lists links to other projects (internal development, actually aimed at something totally different, but really helps). I don't think that's been updated for v5 yet though.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Nic (and anyone else),
if I may ask please:
1) Does this mean it is recommended best practice that incidents, service requests and problems are each given an individual Jira project?
2) I see that there is this Jira Problem Management workflow:
It is interesting to note that this workflow:
* Has no reviews at the weblink above
* Is listed on that weblink as "UNSUPPORTED"
* However the 'Support' tab states, "Basic support resources are available for this app."
* There are 2 version both released a week apart in 2016 Q3
* Hence if we start to use Jira as problem management tool:
a) Is that Jira problem management workflow in the weblink a stable product?
b) What level of support if any is available for that Jira problem management workflow?
c) Is that Jira problem management workflow currently a recommended product given this announcement on 2020 April 1:
Any help is appreciated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I do not want to ignore this, as it is a very good question, but I don't want to answer it here because this is an 8 year old question and a lot of stuff has changed.
Could you ask this as a new question please? And phrase it without referring back to the stuff from 2012 above?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Nic for your reply,
I've done as you suggest and tried to improve the clarity / wording in doing so.
Thanks again for having responded.
Regards,
Steve G
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.