Best practice recommendations on using a project(s) for different ITIL practices

[Steve G]

* I currently work for a small entity using the Jira server edition 4.5.1

* Within Jira we have a single project deployed called ITHELPDESK

* ITHELPDESK acts as a single queue for users reporting:

a) Incidents

b) Requests

The nature of the requests varies from activities such as IAM requests, equipment fulfilment requests , requests for code enhancements to in-house developed programmers and even non-technical stuff (e.g. info on costs or IT systems).

We are interested in optimising Jira to facilitate additional activities, e.g. Problem Management and Change Management. Is it possible please can help with best practice recommendations as follows:

1) Should we use one project for all ITIL practices or should we deploy multiple projects?

2) If we should deploy mutliple projects, what is the recommended best practice?

3) I see that there is this Jira Problem Management workflow:

https://marketplace.atlassian.com/apps/1216179/problem-management-for-jira-service-desk?hosting=server&tab=overview

It is interesting to note that this workflow:

* Has no reviews at the weblink above

* Is listed on that weblink as "UNSUPPORTED"

* However the 'Support' tab states, "Basic support resources are available for this app."

* There are 2 version both released a week apart in 2016

* Is that Jira Problem Management workflow in the weblink a stable product?

4) What level of support if any is available for that Jira Problem Management workflow?

5) Is that Jira problem management workflow currently a recommended product given this announcement on 2020 April 1:

https://community.atlassian.com/t5/Jira-Service-Desk-articles/ANNOUNCING-Early-access-ITSM-features-in-Jira-Service-Desk/ba-p/1332385

6) Are there any additional recommended utilities / add ons that we should deploy? e.g. I've seen in a 2012 thread mention of  Jira Suite Utilities, and Jira Toolkit.

7) Are there any recommendations on how we manage the content currently coming as service requests? e.g. A request for a code enhancement seems very different in many ways such as turn around times to someone requesting access to a system that can be provided with a few clicks of a mouse.

Any help on any of this is much appreciated.

Regards,

Steve G

[Ravi Sagar _Sparxsys_]

Hi @Steve G 

Let me try to answer.

1. Depends. One is simpler manage especially when you have just one team of agents serving one customer base.
2. Multiple projects will have different portals. It makes sense to have this setup when you want to have separate configurations for each projects. For example project A for customer A with specific SLAs and separate processes (Incident, Service Request, Change, Problem etc).
3. You can always create your own workflow. This is just to get you started quickly but if you think it is missing something as per your need then you can always create your own workflow.
4. Same as above.
5. The link talks about some improvements in Jira Service Desk but you can still do workflow customisations.
6. Depends on your requirements. You can start bu evaluating some templates in Jira Service Desk. Also evaluate cloud and on prem solution because the level of customisations you can do on server is a a lot more than cloud but cloud can get you started quickly with no hassle to maintain the infrastructure. Since you tagged jira-server I guess you are asking about on-prem. 
7. You can have a separate request type for feature requests with not very strict SLAs. It will also help in reporting.

Jira Service Desk has all the customisations capabilities of Jira, especially the workflow part that was your main question I guess. You can create a workflow that matches your actual processes.

• Evaluate Jira with different templates
• Customise the configurations to match your needs
• If your requirements can't be achieve by customisations then you might need an app. The app you mentioned will bring lot of powerful features to enhance the workflow like conditions and validators

I hope it helps.

Ravi 

[Steve G]

Hi Ravi,

Thanks for your obviously constructive reply. To put some context on where I work:

* It is a poverty alleviation charity organisation with a user base using approx 100 desktop PCs and approx 50 laptops

* Everyone working there (including me), bar a handful of exceptions does so pro bono

* Hence re SLAs, we aren't on the hook for service credits / penalties if an SLA gets missed. SLAs are useful to help us track trends on how we are doing internally in IT Support to keep the organisation running. From the short time I've been there since Jan, the impression I am forming though is that (unsurprisingly), the biggest factor in SLA attainment is the number of volunteers we have available to deliver IT Support

* In 2+ decades working in IT for different organisations, there's obviously always been challenges re resource availability (people usually cost money after all)

* Here though shortage of budget and people is at a completely different level

* Hence to try to utilise the limited resource we have effectively, minimising customisation can work well for us. That can especially be so within Jira. I say that since in response to the sensible comment you made re different SLAs for different customers, we don't have to configure anything to satisfy a diverse client portfolio; we have in essence have one client as such which is our internal users

* In other words, when you mention above having one support team managing one customer base, that is indeed where I work

Hence any other wisdom you or anyone else, I am very interested to read it.

Thanks again for having replied.

Regards,

Steve G