So, you decided to move your current ITSM solution to Atlassian’s JSM (Jira Service Management). Now you think okay where do I go from here? In this blog I will give you some of the mistakes to avoid and their warning signs.

Having been part of many migrations from other tools – be they as simple as sending email to complex expensive solutions such as ServiceNow and Ivanti – there are several things you must be careful to avoid. The following mistakes will certainly lead you into trouble.

1.       Deciding to go completely in-house without Atlassian SME

Atlassian products when first starting with them are packed with easy-to-deploy components such as project templates and pre-set custom fields. However, the complexities behind these can lead to an unmanageable solution. This unmanageable solution then, without expensive and time-consuming architecture, will only get worse.

As an example, I was working with a customer where they grabbed the on-prem version of Atlassian Jira and, as per Atlassian’s original sales model, tried it for free. Once they saw the power and adjustability of the product, they decided to use it as both their primary software bug tracking tool as well as their ITSM solution. They did not have any in-house expertise in Jira or JSM, so they tasked the current admins of their previous solutions to implement and manage the Atlassian solution. Here are some of the major mistakes they made:

Made just about everyone a Jira Admin. This reminds me of the saying too many cooks in the kitchen. With Jira things can be interconnected. So one administrator who changes something for his/her project can affect the process for another administrator, who is then forced to do another change which affects other things etc. etc. This will ultimately result in a jumbled mess with little understanding of why things are there in the first place.

Changed the default custom field and default schemes to match their current tool nomenclature. If you are wanting a particular name for a custom field or a scheme to have some functionality, it is best to create a new CF or scheme to enact that. Atlassian is constantly improving both their no-prem data center and cloud SaaS products. When they do, they are improving default functionality. If you changed that, your changes could be lost or could have adverse effects with the Atlassian improvements.

Installed a completely new instance when new product lines were requested to be incorporated into the tool. At first, as noted with the top point of everyone being an admin, they used all the default schemes. This resulted in a completely new install of a new instance rather than just employing the new needed changes.

Grabbed any plugin/app they saw fit. The Atlassian application eco-system is a giant part of what makes the Atlassian product top notch and should be incorporated into your solution. However, this should be done with care. There are things to check about the app you are considering adding in such as:

• How many installs does it have? If it has less than 100 installs there is a good chance that either this app is new and unproven
• How well known is the app vendor? Even if the app has little installs, if it is from one of the premiere partners then you can feel more assured that you will get support and that the company will be around to continue to provide updates
• What tags does the application have? The are tags such as “Staff Picked,” “Cloud Fortified,” and “Cloud Security Participant”
• Reviews and ratings. There is a star rating for each app which can be from 1 to 4 stars with 4 stars being a perfect score.

2.      Trying to make JSM look or act like your old tool

The next big mistake many enterprises make is that they speak and think in matters of their current tool. This is only logical as that is what the has been used for since the initiation of the tool. This can lead to big problems though.  Atlassian, like the other tools, has its own terminology and processes.

Terminology. The terminology across projects can mean different things. One big example of this is that Atlassian refers to a “project” as a collection of related issues, where frequently other tools call “project” a type of ticket or issue. Another example is that all tickets in Atlassian are referred to as issues. Many people think of issues as incident or problems, where in Atlassian an issue is any form of ticket, be it a service request, incident, problem, or change request. To get past these terminology differences, so that everyone can speak the same language, it is recommended that the company engage in training. If you seek an Atlassian partner to guide you (something we highly advise) they should start the engagement with certified Atlassian training. This will not only get everyone speaking the same language, but also gives a good introductory understanding of how the tool works.

Processes. Using the Atlassian way of doing things is also very important. Just because your old tool performed some operation, and it had since been part of your current process, does not necessarily mean this exact process needs to be implemented with the Atlassian solution. This can be as simple as a process where a field is used for various statuses instead of using workflows, or as complex as your overall strategy for ITSM support. For example, if you are currently doing phone-call-based support, the Atlassian JSM tool is not designed for that. The Atlassian JSM tool specialized in using web-based forms, portals, and emails to intact support requests. Through research it has been found that these self-service-based methods lead to the optimal, most cost efficient manner of support. So, use this as an opportunity to migrate to a better overall ITSM support solution.

The Five Whys. A method I recommend of finding out the true nature of what is needed to avoid making JSM do things like your old tool is a method called “The Five Whys.” This method states you should ask “why” you need a particular thing. Then continue to ask “why” through five iterations until you get to the root cause of what is truly needed.

3.       Not having a predefined project categorization

It is important to look at the big picture and categorize your projects into various buckets. This will lead to a more straight forward method of administration. So, if your enterprise has groups that are Kanban, others that are Scrum, and a few others that are process or waterfall driven then you may have a template for each use case. This template needs to have a governance model around it, described below, so that changes have the proper thought, planning, and approval around them.

4.       Not having a predefined governance model

When implementing your environment’s governance, the governance model should determine all levels of administration, such as:

• Org Admin
• Jira/Confluence Admin
• Project/Space Admin
• Power User
• End user
• Agent
• Contributor
• Customer

In addition to having a predefined role that everyone should be part of (Note: be particularly cautious about the number of org and Jira admins you have), you should have a defined method for changes. For example, I have designed a method where the change requests are categorized.

• Changes that are organizational in nature and do not affect projects, such as user management
• Changes that do not affect things outside of the project, such as components and releases
• Changes that affect things outside the project, but would be beneficial to all projects in the category
• Changes that affect things outside the project, and would not be useful for other projects in the category

Each of the above categories had a different approval process behind it to ensure that proper procedures were applied for each particular change use case.

What to do?

Many Atlassian admins reading this blog are all too familiar with the consequences of doing the above behaviors. To avoid this the best thing to do if your enterprise does not already have certified Atlassian experts is to go to the Atlassian professional service community to seek assistance in launching your new tool. Atlassian has built an ecosystem of partners around their software solutions for items such as:

• Professional Services including assistance with migrations, implementations, and best practices (Forty8Fifty Labs is one such top vendor)
• Managed Services for administration of day-to-day activities with the Atlassian tool suite
• Applications / Plugins for additional capabilities that expand the power and functionality of the base tool, such as Adaptavist and Appfire
• Training for Atlassian certified classes and custom training on how to use and administer the Atlassian products

If you are not going to go with an Atlassian partner for both Professional and Managed Services, and you do not have in-house expertise, it is highly recommended to hire that talent in the beginning. If you hire a partner for Professional Services, and then plan to manage it in-house, it helps to have your Atlassian administrator along the way from the beginning of the solution.

If you are ready to move your ITSM Solution to Atlassian’s Jira Service Management, don’t go it alone. Forty8Fifty Labs is your Atlassian expert. Read more about our Atlassian services here, then contact us for a pre-migration assessment.