Question on how to best setup JIRA for RAID log

New to Jira but can see the possibilities - just not clear the best way to approach this so would welcome some advice.

I work on large ERP implementation projects and would like to use JIRA to manage a centralised RAID (Risk/Assumptions/Issues/Decisions) log on a per project basis.

It looks like i have the option to setup a single project for each implementation with a single three letter acronym for the project i.e. TLA and have different issue types in that project for Risks, Issues, Assumptions and Decisions. Thats neat from a management perspective as the whole project is in a single project.

Alternativel,y, I could setup a separate project for each project/log which means i would use the key to identify the project and type of issue e.g. if TLA was the three letter acronym for the project, i could set up four projects i.e. TLARSK-nnn, TLAASS-nnn, TLAISS-nnn and TLADEC-nnn.

The advantage of the four project version is that i get a sequence number starting at one for each of the logs rather than a sequence that is shared between the different types of JIRA issue types.

To complicate a little more, I looked at the RMSIS addon which manages requirements (another thing i could handle in Jira) and i noted this creates the key prefixed by TLA-Rnnn and it allows linking of requirements with the different issue types in JIRA e.g. you can link a requirement to an issue or a risk.

This would be nice but it seems it only allows linking of issues in the same project. For my RAID log, i would also want to be able to link decisions to issues or Issues with an assumption that was made.

So the questions are - can i link issue types across projects. If not, then is there a way to have separate numbering sequences for different issue types in the same project ?

2 answers

1 accepted

We implemented RAID with the simplest/fastest way possible as we have a small (<30) team in implementation and they work multiple projects at once, so limiting overhead and maintaining consistency across projects is valuable to us.

Our setup is one RAID project, with the screens/fields based on the spreadsheets that we were using at the time.

The most important fields have been:

* RAID: A select list of Risk, Action, Issue, Decision

* Customer Name: Select list of customers in implementation

* Statement of Work: Cascading select of customer/sow so they can file away things for Phase 1, Part 1 or whatever nomenclature they like per customer.

These fields allow the PM to have easy access to the info that they care about and for the relevant still open items to be transitioned to maintenance after go live.

There are other fields for product section, license feature, impact, customer owner and so on but they are icing.

Selected as best answer as with current setup, to reduce overhead, having one generic issue type is probably the best default option within Jira but with the downside that the numbering will be confusing as TLA001 might be a Risk, Issue, Decision or Assumption - however the real answer would be to allow having different numbering and a different prefix for each issue type within a project to have one real world project for each Jira project e.g. TLARSK001 is a risk for the TLA project, TLADEC001 is a decision for the TLA project t etc..

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.