KPMG UK Engineering’s Move to Team-Managed JSM Projects
Let’s talk about how and why we moved, and most importantly… was it all worth it?
Table of Contents
- Introduction
- Our Former Setup
- Team-Managed to the Rescue?
- What did the move look like?
- Pain Points with Team-managed Projects
- Conclusion
Introduction
Jira Service Management (JSM) is Atlassian’s service desk product that sits on top of the Jira platform. JSM combines many service-management based features such as incident management, on-call support and chatbots into a single product offering. If you would like to read more about our decision to adopt JSM within Connected Technology at KPMG UK, you can check out our previous blog on this topic.
In this article, we focus on our decision to restructure our customer-facing JSM Help Centre, future-proofing our setup. To fully appreciate the changes we have made and the rational behind them, it is first important to understand the differences between company and team-managed projects in Jira. Atlassian have their own guide that covers these differences and we would recommend a brief check of their guide if any of the concepts we discuss below seem confusing.
So, let’s get into with a quick summary of our former setup!
Our Former Setup
Previously, we maintained one customer support portal known as the CE/PE Request Portal. CE/PE here stands for Cloud Enablement / Product Engineering, but you just need to know that the portal is used by a vast number of users spread across different tech practices. Portals in JSM link to Jira projects, meaning that when a portal request is raised, it appears to agents as a Jira issue in the connected project. For the CE/PE Request Portal, its connected project was company-managed.
What does Company-Managed actually mean?
In the simplest terms, company-managed means that a project can share its configuration (workflows, issue/permission schemes etc.) with other projects on the site. A knock-on effect of this is that these same configurations can only be updated by a Jira administrator, rather than project administrators.
It is necessary to restrict these changes to Jira administrators, as otherwise you might end up with a project administrator editing a workflow shared with another project, which may negatively impact the other project’s work. This logic also applies to the creation and editing of custom fields, which can be used in multiple projects.
It is important to note that some project configuration may still be updated by project administrators, such as project automation rules, or issue layouts.
OK, got it, back to our setup…
As mentioned, the CE/PE Request portal houses a number of different request types relating to services with users across many practices. Naturally, that means incoming requests need to be handled and resolved by more than one team of agents in the background. These teams each want to automate the management of these requests, which leads to them needing to update the workflows and custom fields linked to their request types. But, those agent teams are not Jira administrators!
Hence, we encounter our key blocker with the use of a company-managed project; our admin team became a bottleneck. Each time a team wanted to add some new automation, they required our input.
Necessitating our input is typically a good thing, as we update and maintain their configurations following our best practices as Jira administrators with the wider view of our site. However, in this instance, the speed that teams wanted to introduce new JSM-based automations to handle their requests was too much for our small team to handle.
Another issue to highlight is that JSM Portals only provide two layers of depth. You click into a Portal, then have a selection of Portal Groups. You cannot go a layer deeper than that. There are no groups within Portal Groups. This means that Portals housing requests for many services quickly become bloated without their inner sections having sufficient categorisation.
So, how did we envision improvements to our portal…?
What Needed Improving
Our vision of an ideal setup looked a little like this:
- Autonomy — Agent teams handling requests need full control when updating or creating new JSM requests. Importantly, this includes automated requests.
- Portal Separation — Users have portals that are clearly earmarked by service; they know exactly where to go for specific request types and inside those portals there are obvious categories.
- Regaining Focus — Our team can focus on other work without jumping between ad-hoc portal requests from agents.
Team-Managed to the Rescue?
Now is a great time to cover team-managed projects as a concept and how their functionality differs from company-managed projects.
What does Team-Managed actually mean?
The easiest way to explain team-managed projects in Jira is that they exist within their own bubble. Contrary to company-managed projects that share globally-managed configurations between projects, team-managed projects have their own individual configurations that are not shared. This means that project administrators are free to create and update custom fields or workflows within that project, without the same risk of wider impact.
That said, team-managed projects can still pull in global custom fields for use in their issues — though their project admins cannot edit those fields.
How could Team-Managed projects help us?
Using Team-Managed projects would allow our JSM project agents (who are also project administrators in our case) to update workflows and create new custom fields. This deals with the ‘Autonomy’ part of our aforementioned ideal setup criteria. All we would need to do is convert our JSM project from Company-Managed to Team-Managed… right?
Not so fast… Let’s talk about the three key considerations (hurdles) in our decision to switch:
- The new project(s) would all need to be created from scratch. There is no nice way to migrate between project types. This would involve copying all configuration items to the new projects.
- Teams need to be skilled up in managing configurations. Just because a team has the permission to do something in Jira, does not mean they know how to do it.
- Communicating the new portals and processes to users. As with any migration, communication to users would play a key role. Users need to know where to raise requests!
Weighing all that up, would the move really be worth it? For us, yes. In our circumstances, we decided that empowering teams to manage their own services and automations in JSM is worth the hassle, even if the idea is contrary to our preferred centrally (company) managed site setup.
What did the move look like?
Let’s take each of our key considerations above and one-by-one see how they played out practically for our portal migrations.
Recreating portals
Creating new team-managed projects only takes a few clicks. The real work comes with recreating all the intricacies of the pre-existing setup. Here’s a breakdown of the move in configuration terms; what needed moving and how easy was it:
- Request types. Cannot be copied between projects and so need recreating manually. For us, request type names have to exactly match those from the source project to prevent complications with automation rule triggers later on.
- Forms. Thankfully, forms can be copied to other JSM projects. All that was then left to do was to link those copied forms to the corresponding request types, which took a couple clicks. Nice!
- Workflows. These are handled totally differently in team-managed projects which has led to a slight learning curve. Workflows needed to be recreated from scratch and then shared between request types. The workflow editor itself is much nicer now than it used to be, which helped.
4. Automation Rules. These can be exported and then imported into the target project. One very important point here is that if you are using an Issue Fields Condition, you need to use “Issue Type” rather than “Request Type” with team-managed JSM projects. Confusingly, the concept of request types does not exist the same in these projects as it does in company-managed. This took a lot of extra clicks to switch over for each affected automation rule.
As we have already mentioned, global custom fields can still be used in team-managed projects, so there was no need to recreate these. There’s plenty I won’t cover here for migrating between portals, such as granting access to agents and customers.
Skilling up Agent teams
Despite the portal split taking place a few weeks ago, training agents to be self-sufficient is still a work in progress and will be for a while. The switch from agents asking our team to create new request types and automations, to instead creating those same aspects themselves continues to be a tough nut to crack!
What’s most important is having clear documentation which covers roles and responsibilities, along with some technical guidance for how to do things. However, hopping on calls to support where needed will always be unavoidable and can save confusion between agents.
Most of our incoming questions relate to automations, such as how Jira automation sends webhooks, how to include Data Connection data in those webhooks, or why automations just aren’t working…
Handling user communications
So, how do you manage relocating 1500+ customers to a new portal? Well the first thing you need is a list of your source portal’s customers. Unfortunately, Atlassian do not make this easy…
You can grab all your Help Centre customers from Atlassian’s UI, however this list will also include customers from unrelated projects. API calls will not include Customer emails due to GDPR changes, so no luck there. We settled for simply emailing all Jira licensed users on our site as there was a general assumption that they all used the portal. Not ideal, but worked for us.
Here’s what we then did once the portals had been recreated and we were ready to go live:
- Email all customers ahead of time with full details and links. Clear comms, more than anything, cover you against any confusions from customers later on. Include context for why the move is important, upcoming dates and key contact details.
- Add an obnoxious banner to the retired portal. The bigger the banner, the better. The banner should include links to the new portals, along with key contact details in case of any confusion.
- Set up an automation rule to reject tickets in the retired portal. We could not simply switch off the old portal, as some requests were still mid-resolution and this would also cause great confusion for users that have bookmarked links in the old portal (they would simply receive a default message saying the portal does not exist). So, each time a request is raised, a comment is added with links to the new portals and the ticket is moved to closed.
4. Add customers to the new project. We had to follow a workaround guide for this, as the “Customer” role in team-managed projects is hidden.
5. Design a brochure to help navigate the new portals. If you have the capacity, it’s a perfect time to design a short and sweet brochure to help users navigate the new portals.
6. Clearly indicate which team handles each request. Customers need clear indicators for how to contact the correct team handling each request. This can be added to request type instructions, or, you can add automated comments each time a request is raised.
Pain Points with Team-managed Projects
We are now committed to using team-managed projects for our JSM projects, so what have we learned along the way and where do they lack functionality? Here are our three main concerns:
- The Summary field cannot be hidden. This is incredibly annoying and is an issue specific to team-managed projects. Company-managed JSM projects allow you to hide and set Summary to a default value. Instead, we now must have users enter an irrelevant summary of each request.
- Grabbing custom field values is not easy. We regularly need to grab the IDs of custom fields created with a team-managed project, so that we can reference them in automation rules. There’s no easy way to find this, though inconvenient solutions are documented online.
- You are essentially abandoning best practices. This is by design and we have willingly signed up for this, but it remains a concern. Agent teams are now doing things their own way in their JSM projects. We are there if they need us, but we will not be paying full attention to their configuration changes because, simply, we cannot afford that time.
Conclusion
So let’s take a look back with some degree of hindsight, was the move worth it?
The honest answer: it is hard to tell right now. We hope that a month or so from now, agent teams will be fully self-sufficient and will not require our help with managing their request types. The move has taken a considerable chunk of our time and though we feel the change was necessary, only time will tell whether it pays off in the long term.
Thank you for reading and leave your comments below if you have been through a similar process, or are contemplating whether team-managed projects are the right move for your team.
