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?
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).
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG