ITSM (or IT Service Management) defines and standardizes, in a proven, efficient and customer oriented way, how to structure IS/IT Services. These principles help organizations to efficiently manage their services at scale, with a model to design, plan, deliver, operate and control IT Services. We can say ITSM is the art of running successful services with the appropriate mix of people, processes, and technology to provide value to customers.
But for ITSM to be implemented and used successfully, it involves a lot of communication.
Why ITSM involves communication
According to ITIL which is the best practice framework for ITSM, IT needs to communicate clearly both internally and externally. IT Services are usually an interface between external "customers" (who may be business managers partners, or real customers), and internal teams. This may involve quite a lot of people, with different points of view on a given product or service (sales and IT ops usually do not see an IT service the same way, and do not use the same language). These people also do not need (or even want) to be informed of every step of the IT request processing (or maybe they want to follow up, if the issue is a critical incident affecting production servers, customers, ...). This means that for ITSM to be successful, it requires every aspect of the service clearly defined, in a way every actor understand. It requires also clear processes, understood and applied by everyone, time limits for requests processing depending on their severity, and so on.
Defining the perimeter of the communication
We just saw that communication is critical for ITSM processes. But before setting the procedure of communication, you'll need to define the perimeter of the communication. And ITSM provides a simple management tool for that, called the W5H (short version for "Who, What, Where, When, Why and How"). It helps define the following elements :
- Who: refers to the entity with whom you are communicating (customers, employees, CEO's....)
- What: refers to the topic you want to communicate about (an incident, a change, a service request, a new strategy...)
- Where: refers generally to the location (of the who or the what) so it could be a group of people in a country (that you could have created in a mailing list) or the location of an incident for example
- When: refers to the time onto which the what could have happened or it could be the time which is choosen to communicate to the different stakeholders about an information
- Why: refers to the reason why you want to communicate (to inform, to motivate, to clarify, to report....)
- How: refers to the channel you use to communicate with the who (email, phone, letters....)
This simple tool shows clearly how ITSM communication is prepared. But in order to break down a little bit more the understanding around this topic, let's take a situation.
Breaking the ice
Imagine an awkward party where two groups, who do not always get along, are hanging out. One group includes the IT professionals. The other group includes the end users who depend on IT for services. End users could be employees of the company, partners, or customers. The silence is painful. Someone asks about the weather. No one is having that much fun. Then ITSM arrives and fixes all the awkwardness. Done right, it achieves the following benefits:
Benefits for IT:
- Better understanding of what the business needs and why (i.e. “business alignment”)
- Repeatable and scalable processes
- Defined roles and responsibilities
- Increased productivity
- Satisfied end users with realistic expectations
- Shorter gaps between detecting incidents and solving them
- Prevention of IT issues before they happen
- Ability to identify and address repeat problems
- Analytics to measure and improve IT’s performance
Benefits for the Business:
- IT can react quickly to change and innovation in the market
- Better IT availability and performance means employees get more done
- IT issues are less common, less impactful, and less costly
- Employees know what services are available and how to use them
- IT provides better service at a lower cost
- Business complies with regulatory requirements no one wants to think about
When ITSM runs smoothly, that once-awkward party becomes one of those epic evenings that ought to be memorialized with stone tablets (or impulsive tattoos). It’s that good.
You can use these lists of benefits to build your case for investing in ITSM.
You could have many other situations where ITSM will help easily such as:
- How to help support teams which use a different tool that does not integrate well into your communication procedure?
- How to communicate with the targeted audience without mistakes (customers, employees, top management)? Assuming that the language must not be the same as the target differs and even the process.
Do not forget that intra-communication within the IT department can be just as important as mass communications to the Business and Users. Also, keep in mind that different parts of the Business, such as general staff or Senior Management may, at times, have very different communications needs.
In this blog, we are willing to illustrate how to deal with an incident in ITSM using our add-on called Ovyka Advanced Notifications for JIRA. At the bottom of this page, you have the link in order to get this add-on, assuming you are a JIRA Server / Data center instance user (starting at 6.4.3 version).
How Ovyka Advanced Notifications for JIRA could help you handle your incidents issues?
CASE STUDY: Dealing with an incident on a platform
Imagine you have to perform an unscheduled maintenance operation on a service. This can be a source of trouble both internally and externally since your instance will be down during this operation. In order to reassure your targets (Who), you'll have to communicate in order to deal with this incident. This will alleviate pressure on the external and internal support teams, as external and/or internal customers will already be aware that you have detected an incident and are working on it.
So the first step will be to inform about the beginning of this operation. Ovyka Advanced Notifications for JIRA (OAN) will help you by warning the different targets you want to reach so that they do not need to reach out to your helpdesks to signal the problem, and already know what services are impacted and if a workaround is known. Ovyka Advanced Notifications for JIRA can even send mails to people with no access to JIRA, and the templated notification will have all the necessary information so they do not need to see the ticket.
With OAN, you'll be able to notify populations when you start dealing with an incident. The screenshot above illustrates our issue notification start model preview. The configuration of this notification could include your company logo, the message you want to transmit to your targets, the description of the incident, service(s) status, the impacted region(s), the different services and components, and ultimately the start time and the end time before this incident is resolved. All these fields are taken from the incident ticket in JIRA, and placed within the notification template via placeholders.
Also note that with OAN :
- You can define mailing lists (for internal and external goals). The best way to do that is by context (by service you provide, and by region/country if applicable...), following what is the most appropriate to your situation
- Your functional approach for internal support can be done on real time JIRA dashboards which show all current incidents (make sure all relevant teams use these on their JIRA dashboards as needed)
This is a generic preview. But you can create your own customized template and observe the render before sending it to your different targeted audiences. The template for this example can be found below:
In the first step you've made intents to inform on the upcoming incident that will disrupt the service.
When you'd have started dealing with the incident, the process is ongoing and then the procedure has the status "In Progress".
- Do we need to communicate on the ongoing process? Of course you need to!
- Why do we communicate when we'd already given on the previous step the start and end dates? Informing first and reporting in second in order to reassure your targets that the team is working on resolution ; or you could even communicate that the incident has been resolved earlier than the planned end date. This way of communicating is transparent and efficient because they are kept up to date on the status of the incident.
- You should make sure to give regular updates on ongoing incidents, depending on their impacts, and if you have news to share, for example a workaround so the customer can avoid the problem temporarily while waiting for a resolution.
The screenshot above illustrates the template for "In progress" status of an issue notification preview that could be sent to your different targets.
This status would be updated for all the "In progress" statuses into your process workflow and that's the reason why your differents targets need to be informed on the evolution of the ongoing process.
This is a generic template that could be customized for your need in OAN. Compared to the first notification, fields Description and the message sent to your targeted audiences have changed. The template for this example can be found below:
The final step is to inform your different targets of the resolution of the incident. This part of the communication has to be made when tests have been performed to check the incident has been resolved.
You need to perform tests to make sure the service has been restored, and communicate on the resolution of the incident. Customers expect a post mortem after an impacting incident, in order to make sure that the source / root cause has been identified ; So in this template, we'll add the necessary rich text field in the Incident and in the notification. This can even contain a link to a more detailed page or JIRA issue.
The screenshot above illustrates the "resolved" issue notification render. This could be customized such as the previous renders in the template of OAN created for this communication's procedure.
Comparison between this screenshot and the previous one shows that fields like Description, Service(s) status, and the message sent to your different targets had been updated. The end time field could have also been updated if the process ended earlier. We also remove the workaround as the incident has been resolved, but you could add custom notes if needed. The template for this example can be found below:
You can get Ovyka Advanced Notifications for JIRA on Atlassian marketplace
and look at the full documentation on documentation of the plugin here
- Other service desk agents in the company, that can be impacted by these production incidents, should always monitor them through their own JIRA Dashboard. They can eventually subscribe to JQL filters to be notified early.
- Agents dealing with the incident can use knowledge bases and swarming (via Atlassian HipChat for example), this will help investigate the root cause quickly, and it can also help warn users of a known workaround.
- Swarming can be helped by "ChatOps", see this Atlassian blog for more information https://www.atlassian.com/blog/software-teams/what-is-chatops-adoption-guide
- We have not covered the internal organization of teams and key roles to deal with Incidents, you should simply note that the incident manager, problem manager, change manager, and support manager are key parts of that process from detection to resolution. More information can be found https://advisera.com/20000academy/knowledgebase/major-incident-management-going-gets-tough/