RAIDs in JIRA

[Gaynor Morris]

I am working on a project to move us from Waterfall to Agile ways of working, including moving off Project Online and using JIRA/Confluence for all our Project Management controls such as RAID registers and project status reporting. I’m new to JIRA, but it looks like they are proposing having different ‘Issue types’ in order to build RAID Registers. I’m trying to get my head around how this will work in terms of seperate numbering schemes and numbering sequentially and if you can build any kind of workflow you want e.g. for Risks; measurement, mitigation etc. Does anyone manage their RAIDs effectively in JIRA this way? Can anyone recommend any good resources that demonstrate how this is done effectively? I see there is a dedicated plug-in for Risk Management (SoftComply), but they do not seem to want to use this. I’ve also seen some great ways to customise Issue Types in something called Big Picture (is this something worth pursuing or can the same customisation be done without it if we have a JIRA tech wizard I can ask?) What is the most common way people manage RAIDs in JIRA? Anyone know? There’s also talk of using Confluence - my understanding of how this will work - is that we can run JQLs on the different Issue types and select the export format to be able to have a live registers in Confluence too if we want? I’m representing the PMO and our requirements are getting ignored. I’m wanting to understand the capabilities of the tools (JIRA/Confluence) to understand how best we can utilise these for our project controls (mainly RAIDs) and if I need to push for plug in’s. I also believe that you can only show interdependencies using the linking function, but we currently use registers to capture external dependencies and dependencies across different programmes within the Portfolio. Do we create another Issue type for dependencies? Arrh help :-)

[Walter Buggenhout · Accepted solution]

Hi @Gaynor Morris and welcome to the Community!

There's a lot going on there, clearly. You are asking a lot of sensible and very understandable questions. And a very short answer would be that you can go a very long way in building what you need with Jira out of the box. But that won't help you get it implemented, I'm afraid.

In the core, issue types in Jira are essentially types of work items. They can be anything, from a simple task or a bug to a sales opportunity, a contract negotiation, a marketing event, to basically anything that would require you / your team(s) to take certain actions. And so yes, they can also represent risks, assumptions or issues.

With every issue type, Jira lets you associate a workflow (i.e. the steps your type of work goes through to get from creation to completion), screens (where you define the attributes you would like to have in place to define the detail of the item) and dependencies (issue links) between them. They help you model how you want to manage both individual items as well as a set of related items in line with whatever process you have in place.

The fact that the Atlassian marketplace has bespoke solutions in place to manage compliance (like SoftComply does, e.g.), is because Jira is a very open, flexible tool that does not necessarily implement a framework just like that. Adding specific, tailored solutions on top can be a great investment, if the solution matches with the needs of your company. Simply put, purchasing a subscription for a product that implements a solution / framework for you can turn out to be much more effective and a lot cheaper than trying to build it yourself.

From where you seem to be at this point and with the key decisions you might need to make, I would strongly recommend you to reach out to an Atlassian Solution Partner near you to help you make the right decisions (and maybe help you set up your tools in alignment with your needs). Working for such a partner myself, I can assure you that it is almost alway very much worth the investment.

Hope this helps!

[Gaynor Morris]

Thank you SO MUCH Walter. I didn’t expect to hear back from anyone, so I really appreciate you not only responding, and in such depth, but for also making me feel like my questions aren’t stupid. I wish I was involved with our Atlassian Solution Partner, but I have a feeling I will have to go through our IT guys first, so I decided today that the best thing I can do is to capture our requirements and ask them to show me how they intend to provide like for like in a different tool etc and take it from there. The info you have provided is still going to be very helpful when having the conversations, so thank you again!