New guy - Wales - Sharing tasks between projects

[David Meredith]

Hi everyone,

I just wanted to introduce myself to the UK people.

My name is David Meredith and I work at Associated British Ports as Systems Support Lead. Our industry is port operations and we have a number of different internal business units using their own JSM projects to support our business. We're utilising:

• Atlassian Access
• Jira Software
• Jira Service Management
• Confluence

Honestly, each day I find something in these products that enfuriates me beyond words but I am defiantly trying to get the most out of them for my business.

I'm really looking forward to meeting some UK ORG contacts to share good practice and understand how you've used Jira to support your businesses.

In particular, I find myself saying regularly 'we can't be the only business trying to achieve x'.

One question I have is, if you have multiple JSM projects, for example HR + IT. How do you effectively share tasks between them? So for example a new starters process will go through Recruitment, HR, Payroll, IT ... If I initiate that process with HR, how do I share tasks between teams effectively to make sure that the end to end process gets done while I track the main SLA in some sort of parent ticket?

Looking forward to meeting you all!

Dave

[Tom Lister]

Croeso

we use Jira automation to create tasks for the IT team based on status changes in the HR help desk.

e.g. onboarding approved creates an IT onboarding task to set up profiles and laptops

[David Meredith]

Thanks Tom, that was the approach I was thinking of taking.

Does this work alright between JSM projects? I'm conscious that the parent ticket would still need to see updates on a provisioning task for a laptop for example?

Users in the parent ticket project won't neccessarily have permissions to view updates in the child provisioning task in the other project?

[Tom Lister]

In our case we don’t mind HR seeing IT tickets but not vice versa. We set up anonymous system accounts to do any automation. 
The ticket is created with HR as reporter and they just watch the updates on the related tickets. Or check the portal.

Nothing especially complex. Just enough to start an IT thread where we can add detailed checklists for onboarding.

[Andy Hurley]

We have a similar requirement here where live problems and incidents are raised on single project via a 3rd party tool. The appropriate team (one of a dozen or so projects that are managed completely separately) then need to work on it but they can't just move the ticket into their project as that would break the linking to the 3rd party so what we are currently doing is modifying the projects board to ALSO pick up tickets from the live problems project if they are for them (identified by a field on the ticket). Originally they used to create their own linked tickets but that meant their updates did not give synced with the 3rd party.

This solution is also a bit clunky as teams have different workflows etc so we have to make all statuses available on the live problem tickets but it does seem to work.

I would love to hear of a better solution if anyone has one.

[Karen Lewis]

Morning Dave! Welcome to the world of JIRA. I haven't used JSM from setup, but here are some ideas from my experience using JIRA software projects. 

I had a very 'clunky' solution in a former employment, where we had two separate projects, one (#1) internal facing for the software team dev & QA, and one (#2) shared with our external client for user acceptance testing. The business analyst reviewed tickets on #2 and if a ticket generated work for the software team, a ticket was set up on board #1, and linked as 'relates to' or whatever link suited the particular case. This was an overhead in our triage process, which will probably infuriate you more, but it suited our need to keep external and internal visibility separate. 

Another way is to set up separate boards within the one project, or even projects within projects. So, for instance, you could have a separate board/project for each of the business workstreams, and link tickets between the boards. There is no block on linking tickets in that structure either.

You can use dashboards to track linked tickets across multiple projects too, so keep the separate projects, and present the tickets from each combined. I'm not sure whether is a widget already in existence to do this, or whether you'll need to build your own. 

I hope this gets you a little along the way. 

Karen 

[David Meredith]

Thanks Karen! That sounds similar to what I was intending on setting up. Somewhere for a parent ticket to live and then creating linked tickets in other projects for other tasks in that overall request process.

I'm interested in the visibility of those tickets for the reporter and how well it works from their perspective.