More and more organizations, both private and public, want to put their users at the center of their concerns. As such, user service platforms of all kinds are becoming key points of the Information System, and the preferred way for users to get in touch with the organization. As part of my work as a consultant for SmartView, I helped set up JSM (Jira Service Management) for various support teams.
In talking to the various players involved, I quickly realized that each project was a complex and vast undertaking:
- The organization of the various teams involved is rarely clear, shared with and by all;
- The needs and constraints of teams are often quite specific, and we're all familiar with the "We're ITSM, Agile and all that, but we don't do everything the same, because we're different" approach;
- Teams have sometimes acquired (more or less bad) habits that they are not always ready to break;
- A tool is already in place, and although it's no longer satisfactory (and everyone agrees), users find it extremely hard to part with their favorite little features;
- The subject doesn't just involve setting up a Jira project, but will extend to the definition and implementation of much broader concepts, such as service catalogs, asset repositories, etc.
Over the last few years, I've been able to carry out a major project of this type, which began three years ago and is still going strong today.
These years of realization, questioning and adaptation, combined with other similar projects, have enabled us to draw a number of lessons, best practices and, above all, a solution adapted to different contexts.
Photo credit
And it's this process of reflection, the obstacles encountered and the solutions put in place that I'm going to share with you through a series of articles.
What you'll find in this series of articles :
- Concrete, pragmatic feedback on a real-life use case involving the implementation of Jira Service Management ;
- Ideas for implementing a user support process in Jira ;
- Tips to use, and questions to ask, in the case of a similar project.
In this first article, I'm going to introduce you to :
- The background to this three-year project;
- The first difficulties we had to face and which we could have avoided ;
- A global view of the implemented solution.
A change originally driven by the tool
My customer's context is fairly classic. The Information Systems Department (ISD), along with the business departments, is responsible for, among other things :
- Deliver and maintain a large number of applications covering various business areas;
- Providing material and equipment to users;
- Offer business expertise;
- Provide business and technical assistance.
Various teams are involved in these missions:
- Application development and maintenance teams, organized by solution and business area;
- Infrastructure teams, organized by technical area;
- Three support teams (business and/or technical), organized by theme and geographical area.
It all started with the business support team, whose frustrations with the current tool were growing. Until, one fine day, the decision was made: "Let's change the tool!
Wishing to take advantage of this opportunity to improve and streamline exchanges and interactions between teams, the choice naturally fell on Jira, already in use within the organization.
The initial project was therefore a change of tool without questioning the organization or the process, and above all without taking into account the other support teams.
And yet... deeper issues quickly emerged:
- Teams regularly complained about the lack of visibility of the progress of their subjects sent to the development teams;
- A gap had opened up between the different support teams, who were unable to share a common vision of their support activity;
- Some of these procedures were still very traditional, and didn't really guarantee a consistent, high-quality response to the user;
- Some processes were cumbersome and complex, which slowed down the processing of requests;
- The organization of the support teams was not optimal (a large number of different players, each working in a very specific field with its own specificities).
Tip 1 - Don't neglect your organization and processes
The tool is a facilitator of your day-to-day work, at the service of your organization, not the other way round. When you change tools, it's a good idea to take the opportunity to lift your head from the handlebars and ask yourself some questions. It's a good time to take a fresh look at your internal processes, identify areas for improvement and see things from a different angle. But also take into account all stakeholders, even if the project seems to concern only one team.
You're bound to find improvements to make to your organization that will have an impact on your project. In my opinion, this step is essential to ensure the success of your project, and to avoid falling back into certain pitfalls.
A three-phase project
And so the project got underway for the first team. In itself, starting small isn't a problem - quite the contrary. But in this case, there was no global, joint reflection upstream. The deployment of this project was therefore carried out by focusing exclusively on the needs and practices of the business support team.
And a year later... history repeated itself: it was the technical support team who wanted to change their tool, without consulting business support or the members of the Jira governance.
A little anecdote: at the time, the technical support team even raised the idea of using another instance of Jira, a proposal related to the aforementioned gap observed between the teams. Idea abandoned.
Unfortunately, it took several months to overcome the consequences of this choice:
- Completely specific parameterization, not respecting the standards and nomenclatures set up by governance;
- Philosophy opposed to that of the business support team;
- Poor choice" due to lack of knowledge of Jira, penalizing the technical support team in their day-to-day work.
Fortunately, a few months later, when the last support team had the same project, we were able to step in from the start, armed with the experience of deploying Jira for the first two teams, and avoid repeating the same mistakes.
Tip 2 - Communication and collaboration
You've already set up your first assistance project: rely on the members of the project to find out about the best practices implemented, and the things that worked or didn't work so well. For example, organize a regular meeting with a team leader to share best practices, points of view and project progress.
Try to adopt a common vision between your support teams: they normally share at least one objective: to deliver a quality, efficient service to users in need of help.
And don't forget that famous user: if your Jira projects operate too differently from one another, the user could become lost or frustrated. For him, you are a single entity.
Finally, even if Jira allows complete and specific customization of each project, having logic and consistency in the definition of fields, reports, workflows, etc. is necessary to simplify and reduce maintenance times.
Your Jira will thank you.
A common base that can be customized and extended
It wasn't always easy, as we went through phases of "doing and undoing" while we found "the right formula" 🪄 satisfactory to my customer.
Today, I think that going through this process was not a total waste of time. The teams needed time to get to grips with the tool, little by little, so that they could then agree to change their way of working and move towards a common organization. And we also needed to take a step back to identify what lay behind each team's organization, and devise a global solution.
The idea of a common base that could be customized and, above all, extended according to specific needs, was therefore built up as the teams became more aware of the situation, and as suggestions for improvement were made on a regular basis.
We understood that certain specificities would not be modifiable, but identical functions appeared more and more clearly:
- Dividing teams into assistance cells;
- A catalog of support services to qualify and categorize requests;
- Escalation to level 2 and 3 support teams;
- Transfer to another team ;
- The ability to easily direct a ticket directly to the right cell;
- A strong link with other repositories (application catalog, HR data, Configuration Management Database (CMDB), etc.).
In light of the above, we decided to work on three different Jira projects, i.e. three user portals. One for each team.
In this way, each team can have :
- Your own workflow, adapted to your organization;
- The fields it needs to process requests efficiently, depending on the services offered;
- Its communication and visibility choices for end-users.
Tip 3 - Find the right Jira project breakdown
Having several projects and therefore several user portals in Jira is not a problem at all. Remember that the single point of entry for the user is the "Service Center", an overlay on top of all the portals. The Service Center offers a global view of all portals in the Jira instance, a transverse search bar and access to all user requests.
In my opinion, in order to find the right granularity when dividing into projects, you need to ask yourself the following questions:
- Are my support teams independent in terms of services and/or organization?
- Are certain services aimed at a narrow user base?
Do certain services require special attention in terms of confidentiality?
As far as workflows are concerned, we have chosen to simplify them to make ticket processing more fluid.
To develop them, we started with the processes. In our case, we could see that the three support teams were already very mature on this subject. Their processes were clear, and so were their expectations for modeling them in the form of workflows in the tool: they immediately knew which steps needed to be transcribed, and which were not.
We were then able to use this simplified vision to create the workflows, concentrating on what was essential.
Tip 4 - Set up a simplified version of your process as a workflow
One reflex I often see is to model the Jira workflow on the process. This can lead to long-winded status names (e.g. "Waiting for dev team evolution"), and intermediate steps that are often redundant, duplicative or useless.
It's not easy, but try to simplify your workflow intelligently: you'll enable your teams to fluidify exchanges with all the players involved, and gain in efficiency and quality in ticket processing.
Here are a few ways to do this:
- Identify the steps that follow on from each other and require the same person (i.e. the person responsible for carrying out the action expected at the step in question): you can probably combine these steps into a single one in Jira ;
- Identify the key stages in the process: these are the stages where very specific actions need to be carried out (e.g. notification of certain people, launch of an automation, etc.): these stages should be clearly identified in the workflow;
- Involve the agents who will be handling the tickets: they are in the best position to tell you which steps are probably too many, or which ones are missing, so that they can do their job in the best possible conditions. One too many clicks on dozens of tickets can lead to frustration and loss of efficiency.
In brief
- Keep in mind that the tool is at the service of the organization and its processes, and not the other way around, and don't neglect the impact they will have on your project;
- Promote communication and collaboration between all project stakeholders;
- Ask yourself the right questions to identify the number of JSM projects you will need, taking into account the advantages and constraints involved;
- Identify the key steps in your process that will then form the basis of your workflow, and keep it simple and efficient.
Of course, as mentioned above, it took some trial and error to achieve these results. But doing and undoing in Jira is not that complicated: for the majority of settings, the cost of going back or adding elements is relatively low (a few minutes to a few hours). But that's only if the previous tips have been followed to the letter: in this case, the adjustments will almost certainly be minor (new status, project merge, field label change...).
Bonus tip - Nothing is set in stone
One last piece of advice, which seems to me to be the most important: nothing is set in stone! A choice that may be perfect today may not be so tomorrow... and that's okay. Above all, you have to allow yourself to change things, experiment and adjust according to feedback from users, and changes in your teams and organization. This may seem obvious, but I often see teams who are afraid of getting stuck with a parameterization, and hesitate to commit to each validation step. But often, a change in Jira is very quick and easy to implement.
What next?
Over the next few articles, I'll be taking a more detailed look at the implementation of certain key steps.
And until then, don't forget to cuddle your Jira: he's worth it! 💖
Cover illustration Journey Vectors by Vecteezy
