Let's figure this out!

[Collin Willis]

Hi Folks,

I have a mission to get JSM up a running and fully adopted in my firm over the next couple of months.

I've been watching the gatting started videos and reading through droves of Atlassian documentation, but I'm still very unclear of the best way to go to get this thing off the ground.

Most of the videos show some steps to accomplish something but there's no info on how you get to the point at which the video starts! Or you follow the steps and their screen does something completely different to yours!

Any and all help welcome :-)

[Mateusz Janus]

Hey Collin,

first question. What do you want to do? You want to "install" JSM on your cloud license or you already have it and want to customise for your own purposes?

[Collin Willis]

The latter. 

[Denise]

Great initiative, I did that in my firm and planned it one thing at a time.  If I learnt something the hard way depending on how many users are in your firm go for the big package that has all to start instead of going to that after.   It all depends on how many users.   I started with 300 users and now we are at almost 2000.   Ask Atlassian for support from the start.  If you have any questions please do not hesitate to contact me. Denise :)  

[Collin Willis]

Fabulous tips, exactly what I was hoping to see from a community.

I'm looking forward to being a valued member of this community one day.

I've attempted to set something up with Atlassian to start with, but their support system is down and I'm getting no response to my emails!

[Lorenzo Phillips]

Let’s start with which platform you’re on—Server, Cloud or Data Center?

Then let’s figure out what your initial goals/requirements are. It’s better to start simple and build on it. For example, start with what you “must have”. This are requirements that will catch the intended audience’s attention or help sell them on it. Then add your “should haves” and so on. 

Finally, where are you getting stuck? You will have lots of support from this community and your peers to Atlassian support. Just let us know what you need and we’ll help you get there. 

Your success is our success. :)

[Collin Willis]

Cloud

[Lorenzo Phillips]

@Collin Willis 

Ok, so how I have my team handle these situations is to create a project dedicated to this effort. If possible, I would setup a generic Atlassian Support project. You can decided which template you'd like to use but in most cases, we use either Scrum or Kanban--depends on how you'd like to track you work. Sometimes, we like to use Sprints to show which work is coming up. Other times, this is overkill and we simply use Kanban. Use your judgement on what will work best for you as there is no right or wrong answer here. :)

Anyway, doing this allows you to track your work, the decisions that are made and who helped make the decisions--if it is not solely you (ex. user feedback).

We then use the built-in structure for work. So we'd have an Epic called Build JSM project (or something like that). We'd add Stories for each area (ex. Workflow, Screens, SLAs, etc.).

Organizing in this manner will save you a lot of headache down the road. And it allows real-time visibility into your efforts. You can give access to your board(s) or build dashboards so you and your stakeholders have real-time status reporting.

Then I would start generating tickets for everything you think you'll need to compete the project and organize/prioritize things. And you can use it to track any Atlassian Apps you may need to fill any gaps in your end goal.

Now as far as the project itself. Like others have mentioned, I would create a test JSM project with a key you would not use for "real" projects. Choose a template that closely resembles what you need. Walk it through some use cases and start customizing as you need.

For my team, when working with JSM projects, we like to start with the more complex templates and then turn off what we don't need. It is easier to turn it off than to pick a simpler project template and manually add functionality. A perfect example of this is a template that has built-in approvals vs one that doesn't. Even if we're told initially that there won't be any approvals, we have learned that eventually approvals come into the picture so we use the template and simply turn off approvals until it is needed.

Finally, you should understand that there will be times when you have to still do Jira-based work along with the JSM-based work. A big mistake people make is expecting to do everything in JSM. Then we they test their work, they think JSM isn't working right.

Don't worry or stress yourself out over anything along the way. We're all here to help you accomplish your goals and shine brightly at your company. ;)

[Collin Willis]

Hi Lorenzo,

I've managed to set up a sandbox site and a new project for figuring this out. I've created an Issue type for a specific request to learn how to do it. Let's say for this example it a request for a new public folder in o365. I've used the summary field to ask the user for a desired path to the public folder, but I would like to add a field for the requestor to list the people that should have access to the new public folder. But for the life of me, I can't see how I would add a custom field that accepts a list of selected users. Any chance you could detail how this might be done?

Thanks

Collin

[Sarah Elmer]

Welcome to the World of Atlassian. Their documentation is useless unless you are a long time veteran of their products, and even then, can be challenging. This has always been one of my major complaints for the last 11 years.

[Collin Willis]

So good to hear someone say that. I was beginning to think I was just too dumb to get it! :-)

[Nic Brough -Adaptavist-]

This is one of the reasons I never suggest using videos as anything other than small snippets of training - so many of them are out of date so quickly, they usually end up simply confounding people, and most video authors don't have time to update them as fast as they would need to.

To get started with Jira systems though, it's not that scary if you're willing to play.  Get your paws dirty and just try it out.

Have a brief think about what you want from a (single) Service Desk, and then go to admin -> projects -> create new project (use a key that you're happy to throw away later, so you can get it wrong and delete the whole thing later). 

The templates will walk you through the basics, but if you get stuck or are uncertain, there's plenty of stuff on-screen that you can type into Community search (or search engines) and get help with.  Or just straight out ask here.

[Collin Willis]

Right, so there's the answer to the question I didn't ask but was in my head. Do I tinker with the projects that are already there or fire up a fresh one to play with? Answer: Fire up a fresh Project to play with!

[Lewis Cook]

Atlassian have recently opened up the sandbox process (I've yet to use it personally) however would avoid you ending up with several "test" projects in your live instance.

I'm not sure how easy it is to transfer configuration from the sandbox though!

[Carmen Nadeau]

The information regarding the sandboxes is available here. At the moment there is no native way to transfer a configuration from the sandbox to the prod. This is in their roadmap. We will be using Project Configurator 

You can find the info here. Atlassian update regularly this page

https://support.atlassian.com/organization-administration/docs/manage-product-sandboxes/

[Kathi Paquet]

I would recommend utilizing one of the JSM templates and when configuring there is a 'coach' functionality that walks you through the configuration steps so you don't forget anything.  I am doing a JSM install on Cloud and some of the functionality is not being implemented for the ITSM is not that mature yet (ie Alerts, Assets, Problems, etc)

[Kathi Paquet]

Also, I created a JIRA Project for my implementation tasks to work with the client so they could see progress along with work items I needed them to provide.  For example, I had a task for "Define Request Types" and provided the examples that automatically are created in the project and we further defined new ones or removed the ones not needed.  If there is a current process in place, this helps you define the new process and workflows.  I would recommend using this to keep you on track for configuration such as the. SLAs, Knowledge base, custom email notifications, automation rules, etc.

As  Lorenzo Phillips statued, this helps identify the must have, should have, etc.  For we have identified what is needed for the MVP and have a backlog for future enhancements as the team is utilizing the Service Desk.

[Collin Willis]

OK, So I've fired up a fresh project, the first thing I want to do is remove Request types I don't need.

So can I be sure if I delete a Request Type in my new "Learning Project" that nothing in the "Support Project" that's currently in use in production will be affected?

So for example, when you create a project using the ITSM Template the following Request Types are created:

Fix an account problem
Get a guest wifi account
Get IT help
New mobile device
Onboard new employees
Request a new account
Request admin access
Request new hardware
Request new software
Set up VPN to the office

and of course the 'Emailed Request'.

Let's say I have no use for the 'Get a guest wifi account' Request type, if I click on the 3 Dots and select delete, will it still be available in any other project that may well be using it? I guess what I'm really asking is are all the components of the Learning project copies? I ask because I was tampering before with adding some field in a UAT project and the field started showing up in our Sprint Planning on the production tickets and boards.

[Collin Willis]

For interested on-lookers, I bit the bullet and deleted the Request Type "Get a guest wifi account" and it did not affect any other project. Phew...

Onwards... Now to attempt creating an Issue Type, Issue Type Scheme, Custom fields,  Screens, Screen Schemes & workflows for a new Request type.

So, which would you folks recommend I start with? Seems everything I try, needs something associated with it that I haven't created yet! So what's the first required component?

[Sarah Elmer]

I always start with a consultation with the user to first set up the workflow(s), Issue Types, Issue Type Schemes to work with the workflow(s), then screens utilizing custom fields, assigned to screen schemes that relate to the Issue Types. There will always be some "back-tracking" until the user(s) are satisfied.

[Collin Willis]

OK, folks, I've just found out, JIRA offers a SandBox site!! Why was I not told about this sooner?!

So now I'm going to delete the new project I created and start again in a Sandbox.

[Carmen Nadeau]

When the requirements are known, this is the order I do to create all elements associated to the new project.

1. I always started with the creation of the issue type first and the issue type scheme after that.
2. Then I created the customfieds and associated those to the issue types.
3. After that is  the screens and screens scheme. I always prefer to add the custom fields in a screen at the same time , instead of during the creation of the customfields. 
4. I continue with the workflows and the workflows scheme.
5. I associated all the schemes to the project
6. The notification scheme, the autorisations schemes and the security scheme are always done after those because they often changes

[Ken Siskind]

For JSM, I would start with the customer point of view.  Before even creating any projects I usually figure out what are we trying to automate.  Are there existing manual requests that you can look at first to help categorize them?  We had a lot of requests in Slack then we turned into a JSM portal.  By reviewing the slack requests we could understand what people are asking for and then figure out what questions we need to ask in a portal.  Then decide if you need approvals for any of the work.  This will help you decide what type of workflow you need.  Remember you can always iterate on it and don't have to get it all working perfectly right away.    

[Collin Willis]

Thanks, that's great advice, unfortunately, my challenge isn't so much what I want JSM to do for me, I've got that down. It's how to make it do it.

[Taranjeet Singh]

Wow! That's a great discussion and a lot of good suggestions from the community!

@Collin Willis I would suggest to start with a new JSM project created using a default project template that suits your needs (Company-managed (previously Classic) or Team-Managed (previously Next-gen),  an IT Service Desk or a Basic Service Desk, etc.). Then, start by just keeping only the required elements (and deleting the rest) for each config aspect of a JSM project: Request Types, Queues, Reports, and SLAs. Then, test to make sure these required elements work and then move to building upon it with additional requirements.