In 1993 while developing Help! for Lotus Notes, many companies were hiring us to help them track their physical moves of people and IT resources from place to place. I added a database to our application called Move/Add/Change (MAC) to help keep track of these mini projects. Little did I realize that a few years later ITIL would emerge and Change Management would become one of the key features of iSupport. I am not sure if we were the first to offer a dedicated Change Management function but if we were not first, we were definitely in front of the curve.
I thought it would be good to start a series of blog posts called “In My Experience” and solicit information from different perspectives in my company. Our experts for these posts will be:
Ryan Terrell – VP of Sales and Official Holiday Party Photographer – 15 years with iSupport
Darren Grigg – Product Manager and Expert of Leaving at Exactly 3pm – 14 years with iSupport
Lisa Kienle – Goddess of Pre-Sales Engineering – 17 years with iSupport
Lisa Kimery – Documentation Queen – 14 years with iSupport
John Stimson – VP of Everything Technical That Daren Does Not Want To Do – 12 years with iSupport
Today Change Management continues to be a cornerstone of almost every help desk, so I asked each of my experts what they think is important for people to understand about Change Management from the perspective of their position with iSupport. I hope you enjoy their answers…
Ryan
When I started in this industry back in 1998, people didn’t ask if we had Change Management. Most of the time clients would approach us asking if we could help achieve a set of tasks. Often in the context of a multi-pronged project where something needed to be done by a specific time, it needed to be approved by someone and ultimately accounted for.
As the interest in standards like ITIL started to climb I would find myself in conversations as to how my MAC (Move/Add/Change) feature could accommodate it. Often times people would start citing how Change Management was ‘officially’ defined by the standards developed by the British government agency CCTA (later to become the OGC). I found myself fighting it at first, thinking “who are they to say I can’t call it ‘MAC’?” I would push back with one tactic or another, but ultimately as ITIL was reaching a peak I simply embraced it as the path of least resistance. As an organization we finally adopted the term and went on with the business of solving problems.
It’s funny to look back at it now that ITIL seems to be seen less as the end-all that it was years ago and more of a really valuable guide. I’m still helping people meet deadlines and account for projects, approvals, and tasks, but under a different banner: Change Management. From my perspective as a sales guy I’ve come to find that what’s important is understanding a problem and communicating how I can effectively help solve it. I’ve come to rely less on manuals and acronyms and more on goals and solutions. I guess the more things move, add, and change, the more they seem to stay the same.
Darren
As Daren recognized back in 1993, move/add/change projects are not incidents. The Incident Management system in iSupport has long included the ability to create ticket hierarchies so that the subtasks needed to resolve issues related to existing services can be managed, but this shouldn’t be used as a way to manage multi-task change projects. There are many reasons for this, but I’ll key on reporting today. When dealing with incidents the goal of the service desk is to resolve issues and restore services as quickly as possible, and operational and service level agreements are usually in place to ensure this is done.
The overriding goals with Change Management are much different. They include making sure any moves, adds, or changes are well planned, reviewed for consistency with company policy, and scheduled for times when the impact on existing services and users will be minimized. Considering this difference in goals, you would expect that the average time an incident is open would be far less than that of a change project. Many other metrics to ensure effective and efficient incident management, such as first contact resolution and escalation percentage/count, would be much more difficult to obtain if move/add/change tasks were mixed in with incident tickets. The converse is true as well – managers don’t want to have to filter through incident tickets to find the change projects that they need to review for approval or those that are soon or past due. As I mentioned, there are several reasons why it is beneficial to separate incidents and changes, but the ability to more easily obtain reports focused on the metrics that correlate to the goals of each discipline is one of the most important.
Lisa Kienle
Over the years of working with customers, Change Management has played a big part in their organizations. I have found that when helping others configure their change processes, the biggest error is over-complicating the process. Can you make it complicated? Yes, but you don’t need to. By talking through the desired process, it can be streamlined to the following: Create, Approve, Execute, and Review/Close. Starting with those four steps, you can then build out more if needed. For example, does a certain change require multiple approvals? Can those approvals be based on categories? Is this process a standard, pre-approved change?
The key is to start small – take one of the simpler change processes and work it through the four steps. I have found that this gets the flow going, and next thing I know I can’t get a word in edgewise because the team is rolling in the ways that Change Management can help them.
Lisa Kimery
Change Management – this topic is right up my alley because my job is all about tracking and documenting changes. To me, no surprise, it’s all about communication. In addition to writing down the changes in a project, it’s important to take a step back and analyze who will be affected by the changes and make sure all of those involved know the specifics and the effects of the changes on the existing product framework. Not communicating can have a ripple effect, and there are many communication channels available these days so you can just use what works for your company environment. In addition to standard features such as templates to ensure efficiency and consistency, we now have several communication channel features in iSupport. We use these features internally and our team dynamic has never been better because we all have enough information to do our job well.
John
Change can be a very useful tool – when used. In Support, we’ll generally see the two extremes – the customer who barely takes the time to look into Change Management and thinks it’s not for them or feels overwhelmed and never touches the functionality again, or the customer who is trying to implement all at once across their entire organization a very complex change process which attempts to make coffee in the morning. Sadly the results generally end up the same, going nowhere.
Much like the original idea of Move/Add/Change, keep it simple. It’s best just to start where you stand and ask a few basic questions: What do you need? Who needs it? When do they need it by? Just get a process going! From there you can expand it and ask other questions: Does anyone need to approve it? Do other folks need to get involved for a critical path item? Do I need additional facilities, hardware, software, equipment or personnel?
Don’t expect perfection at first, learn from the inevitable mistakes, and embrace the fact that change by its very nature is changing.
For more information on our offerings please visit https://www.isupport.com/products.
Copyright iSupport Software 2013
