Why are ITSM best practices important? Isn’t each organization different? A lot of questions popped up when we started writing this. The whats, hows, et al. We’ve tried to stay true and answer every question that came our way regarding ITSM best practices.
So we will cover the best practices for the following ITSM modules
- Incident management best practices
- Problem management best practices
- Asset management best practices
- Change management best practices
- Release management best practices
But why are we going ahead and writing about ITSM best practices? Is ITSM still relevant?
There’s no secret to the fact that ITSM is evolving. There’s more emphasis than ever before on
- Aligning business practices with IT,
- Making service desks more employee friendly
But guess what? The day to day tasks of an IT service desk agent have gotten more difficult and complicated to keep up with the needs of today’s employees. While the tasks of IT folks have evolved, the underlying purpose of an IT department has not changed.
ITSM folks are increasingly in need of ensuring
- They meet the requirements of the business
- They make the employees happy
With this underlying principle, it’s pivotal for IT folks to stay on top of their game. So, that brings us to the question – How can IT folks do it?
If you’re one of the IT managers or agents who’s finding it difficult to wrap your head around this fact, don’t worry, we have you covered. We’ve analyzed over 100 articles, spoken to more than 15 experts with a combined experience of 300 years.
- A detailed deep dive into each practice
- Screenshots, GIFs, and videos to explain tactics in ITSM best practices
- An infographic/checklist that encompasses the ITSM best practice for every module.
Reading this will ensure you never have to reinvent the wheel.
Incident Management best practices.
For the first part of ITSM best practices, we will focus on incident management. Let’s face it – incident management has been the elephant in the room when it comes ITSM. We’re gonna take a crack at it from our conversations with customers and what has worked for them.
Identify and record
We all get a ton of incidents every day. Incidents can come from emails, phone, walk-ins, Chinese whispers, word of mouth or crashing through the door (if you’ve got an aggressive coworker :P). Irrespective of the source, you first need to log the incident into the service desk. Information that you log in should include
- A unique identification number for the incident
- Name of person who raised the incident (or the person who crashed through the roof)
- The date and time (with the time zone)
- What’s the incident about?
Categorize and prioritize
So, you’ve logged in the incidents. But is that all? We only wish things were that easy. As a kick-ass incident manager, you must be able to
- Have a logical, intuitive and easy way of assigning a category/subcategory to incidents
- Prioritize incidents based on categories.
So, why do you need to categorize and prioritize?
As simple as it may sound, prioritization gives you the ability to analyze and dissect your data from incidents to look for patterns and trends. This analysis directly feeds into proactive problem management – something that will help you prevent a plethora of incidents.
Here’s a GIF of how we
- Show priority and impact
- Categorize and sub-categorize incidents.
See, what we did there?
We categorize incidents as they come. Something that has helped us further reduce the incidents is the ability to filter them based on sub-categories as well.
Your ITSM tool should be able to do it intuitively!
Next up… prioritization.
Prioritization of incidents must be based on two things – Impact & Urgency. Yes, it’s that simple.
Consider the number of people of people who will be impacted by the incident, the financial, security and compliance implication. Prioritize incidents based on these factors.
Organisations set SLA (Service Level Agreement) based on priority levels. This way you’re setting the right expectations as to when your customers should expect a response to an incident.
Still confused about priority and urgency? Watch this video by our in-house ITSM evangelist Arvind Parthiban.
Don’t have the time or resource to build a priority matrix? Here’s a sample priority matrix built with Freshservice.
So what if you do both of these? Is that your magic wand to incident management best practice? I’m afraid not.
Let’s talk about the initial diagnosis.
I call the initial diagnosis as one of the crucial steps while framing best practices for incident management. This is a stage where you should
- Have hypotheses about what is going wrong. While troubleshooting issues, always start with the basics. Go to advanced troubleshooting only after you’ve exhausted the basics.
- You could either go about investigating the hypotheses or follow appropriate procedures/tools to correct them. Think of knowledge base, diagnostic manuals, and past experiences for tools or resources to help you out.
If the knowledge of the IT folks doesn’t help in resolving repeated issues, it’s time to escalate.
Escalation shouldn’t be a cuss word in today’s times. It’s merely helping your agents in secondary or tertiary levels solve issues with right information and context.
But wait, there’s some more…
Your effort doesn’t end with resolving an escalated ticket. So then we move on to what I call BEST of Best practices in incident management.
Investigate and Diagnose
This should happen throughout the lifecycle of incident management. If your L1 support folks solve the ticket without escalation – Boom! You’ve already skipped a few of the investigate and diagnose steps.
If not, you should investigate and diagnose the ticket as it goes through each stage of escalation. The investigation should include causes, the reason for escalation, possible scenarios this could occur in the future among others.
The diagnosis could be very easy if you’ve done the categorization and prioritization right (See how categorization trickles down). So as a best practice for Incident Management- aid your diagnosis based on root cases, priority and category of the incident.
Resolution and Recovery
The next step after diagnosis is when you will arrive at a required solution necessary to solve the incident. Recovery simply means the amount of time taken to restore operations fully. The best practice for resolution of incident management is to ensure all the scenarios are accounted for when the resolution is rolled out and ensure the service is up and running ASAP.
Here’s a small catch – Recovery should always be based on the urgency and priority of incident.
So, now we come to the most exciting part – incident closure.
After identifying the resolution and recovery times, the incident should ideally be passed back to the service desk. As a best practice and for incident management it’s recommended that
- Only the service desk employees close an incident.
- Check with the person who reported the incident before you close the incident
- Make sure the resolution is satisfactory.
It’s best if you send a CSAT survey after every incident resolution to check how well your service desk agents are performing.
Incident management best practices – A pictorial summary.
Here’s a quick overview of all the best practices of incident management
What we liked reading from around the web on incident management? These articles don’t talk about ITSM best practices, but just contrary and supporting views about what we’ve discussed here.
- Incident Management checklist– This is a short and crisp PDF on all the necessary checklist items you need to nail the incident management process. If you’re someone who’s looking to optimize you ITSM process w.r.t incident management process or just getting started, this kit will serve you a lot of value.
- 12 Tips for Getting Started with incident management– Part-1- This blog gives you actionable tips on getting started with incident management. This is written by one of our favorite ITSM authors Stuart Rance
- 12 Tips for getting started with incident management– Part-2- A continuation of the previous blog, this one further delves into 12 more tips to get started with incident management.
- 10 best practices to deal with major IT incidents– A blog by IT portal, this article gives a hawk eye view of tips to help you deal with major IT incidents.
- 10 security incident management best practices– This gives best practices around incident management, from a security POV, and focuses more on proactive incident management.
- Incident response- 6 best practices for the modern enterprise– A short and crisp blog by our partner PagerDuty, this helps you frame robust incident management.
- Why does incident management fail to keep up the promise?– A contrary blog on incident management which talks about why IT should focus on preventing incidents rather than resolving them.
Problem Management best practices
Alright, having covered the best practices of incident management then comes the second module of ITSM best practices – problem management.
Personally, talking and figuring out the best practices for problem management has been a challenge. Industry experts have called out the need not to have a problem management module or to have an alternate approach to problem management.
Not that we completely disagree with them. We have outlined a few exciting points of views from other authors. But, is problem management still relevant? Well, we will keep that for another blog.
For now, let’s focus on best practices from problem management.
So, what calls for problem management? How is it different from incident management in the real world? Let’s try and take a crack.
Incident Management vs Problem Management
To put it straight – incident management and problem management work in conjunction to resolve issues and have an effective service desk. Incident management focuses on speed and agility of solving issues ensuring the business stays up and running, what the experts call as Business Continuity. However, problem management focuses on digging into issues, analyzing the root cause(s) and providing a solution that’s long-term and sustainable.
Problem management’s primary job is to ensure that similar incidents are not repeated. Still confused?
Let’s take the example of the wi-fi router in your office.
The signal from the wifi router isn’t strong enough for your laptop, the IT team gets the router replaced and it’s business as usual. That’s a classic case of incident management ticket getting resolved faster.
Often though, these issues tend to occur repeatedly, affecting the productivity of employees. That’s when you get back to your service desk to do a root cause analysis about
- Possible reasons for the wifi outage,
- How can you make the routers more efficient, and
- Ensure these outages are kept to a minimum – That’s problem management.
You can read a more detailed take on the difference between incident management vs. problem management in this blog on itsm.tools.
However, it need not always be about reacting to a set of incidents. You can be proactive with your approach. More on it as we dig into the best practices.
So, here are some best practices for problem management.
Think beyond IT service desk
When it comes to problem management, it’s imperative to think beyond the scope of your service desk.
The reason? A problem affects a large chunk of your employees (depending on the scale) and their productivity.
Since a ‘problem’ has far more impact, it’s important for an IT person to asses what’s not seen and take a customer-first approach. Re-prioritize problems (& related incidents) based on business and operations impact and don’t view it just from IT service desk’s lens. Look for incidents with similar causes, and group them into similar buckets.
Here’s an example
And ensure you document everything from impact, symptoms to root causes, for an effective root cause analysis.
There are two sides to problem management
Yes – As I stated earlier, problem management need not always be reactive. In an ideal world, it should be proactive.
In the proactive problem management world, you don’t wait for the incident/problem to occur. Instead, you preempt the possible failures that might cause problems and try to fix them (Even before the end user comes to know of it).
I hope you don’t kill me for this, but a good aim to shoot for will be ZERO incidents with proactive problem management.
To be proactive with Problem Management you could:
Perform a thorough analysis of all your past incidents
A comprehensive review of all your past incidents, patterns on repeating incidents and their root cause will help you discern patterns and most likely problems that might occur. You could perform root cause analysis, Top N method to identify common causes and act proactively.
Here’s a sneak peek into one of our root cause analysis templates. As you can see, we have all the IMPORTANT details keyed in.
Technology related activities
This step doesn’t necessarily fall into the proactive problem management purview but requires collaboration with other teams and help of additional tools. A simple technique like a Syslog analysis will give you a good idea about possible pitfalls on the technology side of things and help you be more proactive with problem management.
Hardware and software lifecycle
Run frequent audits on software, hardware, and other devices to ensure they’re performing optimally. You should ideally develop a non-compliance report and assign them to relevant groups. One could automate this step by having Workflow Automator to assign tasks to appropriate groups and monitor progress.
The infrastructure assets should be optimized for performance continually. All the network devices like routers, switches, operating systems, firewalls perform similar functions and will have identical configurations. As a best practice, maintain these devices at the same configuration standard.
Moving on from proactive problem management, let’s look into other stuff that will help you ace problem management.
Knowledge is wealth; Knowledge is invaluable
Here’s a short video on how to nail the process of knowledge management for better problem management.
As part of problem management, your primary job is to figure out long-term solutions that will ensure your users are working efficiently without major outages. Hence, all your answers, workarounds, and past experiences must be documented as part of the knowledge base.
It helps achieve two things:
- Prevents you and your team from reinventing the wheel.
- Gives a ‘go-to’ place for you and your team to see a log of similar situations and act faster.
Problem Management shouldn’t be siloed
Problem management should not and cannot work when in silos (Same principles apply to ITSM and business :P). It’s crucial for you to avoid technology silos, and not see problem management as a way of passing the buck to other teams.
As a best practice, problem management should integrate with technologies you use for other ITIL processes. Data from incident management, event management, and other ITIL modules should interact with each other. Hence, it’s of utmost importance to ensure that your tool has all the modules talking and working with each other in a smooth manner.
So, following the best practices from problem management will ensure (or rather, the advantages of good problem management are):
- You have fewer situations where there’s a service disruption
- Fewer incidents
- Better service quality
- More operational efficiency
- Happy end users.
And here’s round-up of invaluable content around ITSM (Problem management specifically) that we feel you MUST read. Yes, you MUST.
- Proactive problem management – What ITIL didn’t teach you– A quick guide on why proactive problem management is the way to go in your service desk. It also gives some tips and hacks on how you can go about it.
- Incident and problem management- Two names for three things– A contrary view to why the definition of problem management by ITIL is broken.
- Problem management KPIs– A short, crisp blog on KPIs that could be useful to indicate how your problem management module is performing
- Is it time to rethink problem management?– A solid 800 odd word blog on why problem management has low adoption, and why there’s a need to rethink problem management as a module.
- Why ITIL gets incident vs. problem wrong– A detailed blog by Rob England on why the line between incident and problem management is blurred, and how it should be defined.
Asset management best practices
From most of my interactions at events, meetups and customer conversations there’s a common underlying theme – ITAM tends to be a project, not a continuous process. ITAM is done as a reactive way to fix a major incident and duly deprioritized after it’s resolved.
Contrarily, when I converse with folks who’re big time into IT Asset Management (or ITAM), they always point to exorbitant billing, failed audits, security threats, or expiry of a software/hardware device to bring the management’s attention to IT Asset Management.
The overarching takeaway? Not many think of best practices in IT asset management as something as strategic when they get off the ground with ITSM. But think of it, some investment in best practices for asset management- both software and hardware is something that is worth investing in, for it will help you save loads of time and money. So, here are some of the best practices in asset management.
Tracking isn’t bad after all
Asset management starts right at the time when the asset comes into your organization- Every possible detail about the asset (software & hardware) needs to be logged.
For instance, let’s take the example of a new MacBook Air that you’ve bought. Here’s a snapshot of all the details you need to enter
See what we did there? Information on the model, impact, location to which it is issued, to who is the asset issued, and who is the asset managed by.
This logging would help you
- Have a robust inventory of all your assets, making it easier for you to review, revisit in case of any discrepancy
- Calculate the depreciation cost of your assets (provided your purchasing information is right). This has a direct implication on how much your IT department saves QoQ.
- Also, having data around assets depreciation helps you make more informed decisions around when to decommission, critical assets to invest in, and assets that aren’t giving you an ROI.
- Remove/terminate contracts with ghost/non-performing assets in your organization.
The life cycle approach (as IT experts call it) is tried and tested, and it’s best to stick to it. Remember – IT asset management starts right at the time a new asset is requested by your organization and ends when the assets have been completely phased out.
If you’re doing it more than twice, automate
A lot of tasks in IT asset management can be automated. Tasks like patching, application deployment, reporting, running periodic checks are processes that can be automated. Here’s a peek into how automation of cyclic check would look like
Here, we’re defining what happens when a request for a new asset comes in, who the approval goes to, and the set of actions to be taken for each use case. Once your automation is set up, all you need to do is distribute assets, and conduct periodic checks (again via automation). So, if there’s something that you can automate in IT asset management (or ITSM in general), DO IT!
Define what’s critical for you
This is probably one tip that’s gonna save you a ton of time. You should classify assets based on what’s vital and what’s not. It could be a software or a hardware asset. Once the classification is done, it will be straightforward for you to determine which assets require more management than the others.
Knowing what you shouldn’t do is more important
Software license management has been on the rise. With software management, it’s important to keep a tab of what you’re entitled (and supposed) to deploy. A lot of times, IT managers tend to ‘over-deploy’ simply because they aren’t aware of what their job entitles them. As a best practice, keeping a tab on all the software deployments would ensure you’re on top of things when the vendors come calling.
Track the right metrics
A lot of us track things because it’s measurable and not because it’s necessary
A lot of us track things because it’s measurable and not because it’s necessary. But that’s not the right way. What you track should depend on what you want to achieve.
What do a lot of us do?
Manipulate what we know/want and correlate it to our problems and take decisions by that data.
Here’s a small matrix we created to help you track the right metrics for Asset management.
With that, here are some juicy articles that we enjoyed reading over a cup of coffee
- Best practices in hardware asset management – A short blog that outlines some best practices when it comes to managing your hardware assets. The blog also talks about the difference between measuring success and failure of your initiatives.
- 7 best practices for IT asset management – A blog that’s very similar to the best practices we’ve outlined here. You would really relate to this blog if you have a process set up for ITAM and are yet to see results.
- IT asset management blog – Your one-stop shop for resources, blogs, and news from the IT Asset Management world. Ran by our good friend Glen Thompson.
Change Management best practices
Like goodbye’s, changes are hard.
When was the last time an organization-wide change was accepted with open arms? After all, we all resist, stay firm and finally concede to change because we don’t have a choice.
Having a good change management template will help you manage changes quickly, economically and effectively. Your aim should be to automate the process of communicating changes with the right tool.
A key step in ensuring you follow best practices of change management is to ensure changes are controlled, thought out, recorded, iterated upon, analyzed and then approved.
So how do you achieve the best when it comes to change management in ITSM?
Here are a few thoughts on the same
Answer the ‘Why?’.
Most employees and end users are resistant to change because they don’t know the ‘why’. A good change management template should share the why, the when and the how (with relevant people). Getting everyone onboard for the change is the most challenging part of the change, and is the most important as well.
Here’s a snapshot of the change management form that we use to present to the management
Here’s how it’s communicated to the user
See the difference?
Information necessary to both the user group is communicated. And ONLY the essential information is disclosed.
Pro tip- You should notify users via email as well, for you should go where the users are. Don’t expect them to come and check your portal everyday 🙂
This is true not just for change management, but also for all the processes in ITSM where you are thriving for adoption.
So that takes us to the next step
Be aware of all the steps and take complete control
Change management will be considered successful only if the change is adopted quickly, without any hiccups. Achieving this will be impossible without taking full control and being aware of everything around you.
Right from planning, to testing, communicating, scheduling, implementing, documenting and evaluating- You need to be on top of the process.
Here’s the deal:
Let’s say you’ve introduced a new HRMS software (or a new ITSM tool) and rolled it out to all your employees. Without prior notice, that is. Everyone’s gonna be furious.
Things are going to be chaotic. Everyone is going to find a workaround, and the adoption of your new software is going to be low. Extremely low.
A lack of focus on a single issue can throw the change management process out of the window.
A good change management module will give a clear view of the whole process. For a greater adoption from the IT teams, the change management software needs to be intuitive, easy to use and communicate effectively.
Your change management module should have the capability to
- Communicate with the Change Advisory Board (CAB)
- With end users
- Report the effectiveness of the change
Here’s how a snapshot of all the changes should look like
A single pane view would enable you to take complete control of the process and ensure nothing slips through the cracks.
Robust reviewing is always good
Review, Re-Review and Review again!
The change management process, the people and the technology used should be audited at every possible step possible to ensure the right changes are put in place.
A good practice for change management would be to review the effect/impact of these changes and benchmark it against your internal metrics. If a similar change in the past has not been successful, why go ahead with it again?
But considering the operation efficiency, it must be a painful process for small teams to review each step of the process thoroughly. Here’s a little template, that will give an overview of how much reviewing is good, depending on the type of change.
Personalise change management
This is a classic case of one size doesn’t fit all.
A single change management template/ process will not fit all changes or changes for all departments.
Let’s take the example of DevOps.
DevOps as a principle focuses more on continuous integration and deployment, whereas change management’s role is to ensure that none of the changes slip through the cracks to affect business continuity.
With two different principles, how do you implement the change management? For the optimal mix of speed, agility and risk mitigation, your ITIL change management process should integrate/merge with DevOps (instead of ignoring it for change management altogether).
Similarly, non-IT teams could have their own ways of managing changes. The solution?
Have three ways/templates for managing changes- One for DevOps, one for IT and one for non-IT teams.
You might face a lot of issues like
Changes from non-IT departments or others could be unauthorized, there can be scheduling conflicts, your service desk could be unaware of the change, but that’s no reason for you not to integrate.
Personalising change management based on requirements eases a headache on IT and ensures your employees have a higher chance of embracing the change.
Account for the risky days
Changes shouldn’t put your company, employees or your board at risk. One should ensure that you’re not on the wrong side of regulations. This can be achieved by having
- A thorough understanding of regulatory compliances in the environment you operate.
- A robust process to ensure you don’t have any surprises.
Coming to a robust change process – It could be manual or automated. Going by the first impression, manual way of doing things might seem like a very viable and fool-proof option, but NOT advisable. Manual data entry could be fraught, filled with errors.
Contrast that to an automated process – Where there are no silos, the data is present at a single location, and everyone knows just the place to look into when it comes to the list of changes that have been made or going to be made. When there’s an audit, it’s straightforward to track and analyze the effect of your changes. So, go for automating the process of storing/ analyzing changes in your service desk.
Change management is the second most popular ITSM module after incident management. We’ve all have had our share of ‘Problems’ with Change Management (Ah! the pun), here a few best practices to help you breeze through.
- A beginners guide to change management– A comprehensive guide if you’re just getting started with change management modules.
- How to manage change like a rockstar – A preview blog by Vawn Murphy for her talk at SDI’18, this quickly gives a heads up on hygiene factors to follow to nail the change management process
- The why and what of change management – A quick overview write up on our favorite ITSM blog ITSM.tools; it gives you a quick heads up about the small nitty gritties about change management. If there’s one place where you need to get an overview of change management, this is it.
- The ITSM Transition blog– A blog by Greg Sanker, the blog(s) focuses more on achieving ‘excellence’ in ITSM, with some golden nuggets around change management.
Release Management best practices
So, one question we get asked often – Aren’t release and change management part of the same value stream? Aren’t they suppose to be the same? Watch this video know the key difference between them before we jump into the best practices of release management.
Following release management – might be tough and tedious. Most companies don’t follow all the best practices, but hey, you got to figure out what you got to figure out.
The challenge with release management is two fold
- There are too many stakeholders involved – development, testing and deployment teams.
- A one size fits all or a standard approach or a best practice doesn’t seem to have worked consistently. The reason? Different teams work independently, and unless the practices are top-down, people find little success.
So with this premise, let’s try and figure out release management practices that have worked for a bunch of our customers.
For the ease of understanding, let’s split this into two – one for software development and the second about other hygiene factors to keep in mind for release management.
First for software developments
Here’s a simple consumable table for release management.
But hey, depicting them on a table looks far easier. Where do you apply these practices, what’s the order in which you apply them?
Here’s how you do it
Now comes the question – What do you do at each stage?
Here’s a quick guide.
Most organizations don’t have a release policy. Something to keep in mind while designing a release policy is
- Ensure that it aligns with your strategic IT and business goals.
- Define scope, principles, and rules of engagement before or during the early stages of development.
- Involve key stakeholders, and ensure everyone is on board with the release policy.
Based on the release planning agreed on in our first step, you should carve out a release plan. Ideally, your release plan should contain
- Governance aspect
- Process designs for implementation of releases for various development teams
- The process should be flexible, slightly generic that can be tailored to suit individual business units as per their requirements.
A crucial step, this step must ensure that the code is built in its entirety, tested internally for build quality and is suitable for delivery into target environments.
Review of quality
Closely related to the previous step, your QA teams get involved here. Here the primary focus should be on just two aspects
- Quality (duh)! But what is quality? Ideally one should ensure that the code meets the release requirements
- Ensure the release is business compliant and aligns with the overall goal of what it’s supposed to achieve.
Release acceptance and a Roll out plan
Once the release is tested (and devoid of bugs), then the code should be pushed to deployment. The new code is rolled out to all the existing customers/employees who will access the new capabilities.
Wow! There you go! The release is finally done. But is it time to celebrate yet? Unfortunately not.
In fact, your task as a Release Manager gets even more critical now with the following set of activities.
Communication and training
A step that’s not given as much importance as others, but communication and training are very critical parts of release management.
Why, may you ask?
Because that’s the only way, you can communicate and help your users adapt to the new feature/release. Here are a few innovative ways to ensure your customers are aware of new releases.
Implement, test and retest releases
The last and the final two stages of release management. After testing, it’s a best practice to ensure that you verify a release each time it’s deployed in production environment. Keep retesting from time to time to ensure that the release is delivering expected results in the live setting.
Now that the development part of release management is done let’s look at the set of hygiene factors and other best practices to keep in mind while implementing a release.
- It’s crucial to ensure you implement these steps in a systematic, defined, and logical order across all the business units.
- It’s recommended that you set up a Change Management Board, to oversee all these changes.
- It’s recommended that you have a monolithic release management practice that will integrate with all the other ITIL processes required for release.
- Always ask for feedback from the customers and end users about the release. A release is successful if your end users feel that it solved their problem or did not interrupt their workflow.
Here are a few golden nuggets around release management – The last and final module of our ITSM best practices.
- Top 10 tips for better Release Management – This write up focuses on ten tips to better and optimize your current release management practices.
- Release Management practices for every IT team – This article focuses on difficult but necessary stuff that you need to do, to ensure you’re on top of your releases.
So, that wraps up our ITSM best practices. Think we’ve missed something? Have additional resources? Or do want to write guest blogs on stuff related to ITSM? Reach out to us via the comment section.
I am looking forward to all the love and brickbats! 🙂