Posted by Stephen Mann
on March 30, 2016 in ITIL
As Joe the IT Guy
said in his recent HDI blog
on selecting a new IT service management (ITSM) tool – “Selecting any new technology is a serious matter.”
In particular, there’s little fun to be had with the request for proposal (RFP) process, for all the involved parties. And, having been involved with RFPs on both sides of the seller-buyer divide, I can tell you that RFPs are never fun, but even more worryingly, they can also be dangerous.
You might be thinking “Dangerous? Really?” So consider one of my favorite, and most oft-used, ITSM tool selection statements – “If you ask the wrong questions then you’ll get the wrong answer.”
In my opinion, we continue to see a never-ending series of “wrong answers,” i.e. less than successful ITSM tool implementations, that has industry analysts stating that ITSM tools are, on average, replaced every “n” years (where n is usually between 3-5 years depending on the analyst firm).
The ITSM Tool Blame Game
Many will blame this ITSM tool replacement cycle on the technology implementation process or the fact that key people and process issues weren’t addressed when moving from the old tool to the new one. These people are not wrong. However, more blame needs to attributed to the tool itself – not that the new tool is imperfect but the fact that the tool might not have been the best option for the procuring organization. The wrong questions were asked and the company received the wrong answer.
Joe’s blog touches on this, with Joe stating: “Be clear about which ITSM tool requirements are ‘must haves’ and those that are merely ‘nice to haves’.”
But there can be many other bad decisions made between the creation of business requirements and the eventual ITSM tool selection; with the RFP process a platform for many of them.
Getting Your RFP Right
I’ve written about this before, in a blog called “50 Shards Of ITIL – The Bane And Pain Of ITSM Tool Selection
” (and yes this was before everyone and their dog was writing “Fifty Shades of Grey” blogs), where I state that companies need to break the existing cycle (of RFPs leading to the wrong ITSM tool being selected) by:
Plus, also considering how a dollar saved in tool licensing or subscription might cost you ten dollars in its operation or negative business impact over its lifetime – consider the bigger TCO picture.”
- “Thinking about what you really need from an ITSM tool.
- Stepping back to think about what you need to accomplish with it – and this is from a business outcomes, not an IT operations, perspective.
- Limiting yourself to what you will realistically use both now and in the future.
- Pushing the envelope in terms of what would really help deliver benefits to your business rather than trying to pander to the god of ITSM trends.
- Considering how the people actually using the tool will be helped or hindered by complexity as well as the UI.
Of course there are many other sources of opinion and advice on RFPs available on the Internet but it’s good to see that industry legend Roy Atkinson
is starring in an upcoming HDI webinar
on the topic. And Roy being Roy, he chose to seek insight, and scar tissue, from the many IT professionals that make up the Facebook Back2ITSM
community, posing the question: “What is the most common mistake you see organizations make when making an RFP for products or services?”
And the survey said
10 ITSM Tool Selection RFP Tips
I’ve flipped some of the common RFP mistakes crowdsourced by Roy, from the cited individuals, into ten ITSM tool selection RFP tips. There are other mistakes offered in Roy’s Facebook thread but these ten are a great place to start:
1. Focus on the right things.
Common mistake = “(RFPS are) too long, too much detail of things that should be left to the supplier, and too much focus on how the results are achieved rather than what the results should be.” (Stuart Rance
2. Don’t be led astray by the available technology.
Common mistake = “Unclear requirements, listing a feature set from a product rather than the outcomes they require…” (Daniel Card
3. Commit to specific business outcomes.
Common mistake = “Not focusing on the outcome of what they want it to do, lack of or inadequate design of their business process for which the product or service is meant to support and therefore poor requirement understanding.” (Simone Jo Moore
4. Start out, and stay, impartial.
Common mistake = “Being a vendor fan boy, and not stating this in the RFP but refusing to consider any option that does not include technology from vendor [INSERT NAME HERE].” (Daniel Card)
5. Don’t get lost in the weeds.
Common mistake = “Too much detail and focus on commodity functions, at the expense of defining what's really important, i.e. to find a suitable partner to work with.” (Barclay Rae
6. Take an outside-in, i.e. customer-focused, approach.
Common mistake = “Looking at it from an inside-out perspective as opposed to an outside-in approach, with too much focus on what IT needs instead of the business.” (Elaine Hutton)
7. Focus on your needs, not others’ needs.
Common mistake = “Most RFPs I see are based on feature/functions that come from templates created by Gartner and PinkVERIFY. Sometimes the same question is asked multiple times with slightly different wording, but has the same answer. The items may or may not have any bearing on how the customer wants to use the technology.” (Brian Hollandsworth
8. Balance today’s and tomorrow’s requirements.
Common mistake = “Building the RFP around past requirements rather than the future, though close behind is building it around future requirements while ignoring the current technical and cultural debt.” (James Finister
9. Ask vendors for a solution, not specific functionality.
Common mistake = “Describing the solution rather than the objectives and outcomes, and letting the expertise of the supplier show (or not) with the solution they suggest.” (Matthew Burrows
10. Question some of the vendor’s answers to your questions.
Common mistake = “Taking the vendor’s responses at face value. Vendors know they are jumping through a hoop to get to the next ‘filter.’ The problem is that the honest vendors get eliminated and the less than honest ones make it through. And often you don't find out until much further down the road.” (Ken Wendle
So there you have it – ten crowdsourced tips for getting a better result from your ITSM tool RFP process. Is there anything you would add or disagree with?
And don’t forget to tune into Roy talking all things RFP on the 19th April 2016.
Posted by Stuart Rance
on March 22, 2016 in ITIL
As an IT service management (ITSM) consultant, customers sometimes start by asking me to carry out a maturity assessment
. They usually tell me that they want to know how they compare to other similar organizations, and how they rate against an industry approved scale.
There’s nothing wrong with that, is there?
When I was less experienced I assumed that my customers understood what they were asking for, and knew why they wanted it, and my job was simply to carry out the assessment that had been requested. I even developed tools to help me deliver consistent maturity assessments based on the ITIL service management process maturity framework, which can be found in Appendix H of ITIL Service Design, 2011 edition
. But I know better now. I have learned to ask more searching questions, so that I understand what my customers’ real goals are, and then provide a properly focused assessment that will help to solve their problems.
Assessments Can Be Valuable
So, what’s wrong with maturity assessments? And is there something more valuable that you can and should do instead? To answer these questions we need to start by thinking about why an assessment might be needed in the first place. What is it for, and what value does it create?
Many customers ask for assessments because they are planning improvements
. It’s just good sense. If you’re planning to make improvements, then you need to understand what you are currently doing, for a number of reasons:
- To identify, and help prioritize, the things that need to be fixed
- To create a baseline so you can monitor progress over time
- To define success criteria so you can measure and report the impact of your improvements
An assessment carried out at the beginning
of your improvement journey can help with all three of these.
But does it need to be a maturity
assessment, per se? In case you are unfamiliar, a maturity assessment provides a score based on comparing what you do with a pre-defined set of management best practices. It typically provides a score on a scale from 1 (least mature) to 5 (most mature). The best known maturity assessment model is CMMI
(Capability Maturity Model Integration).
So suppose I tell you that your current maturity level is 2. That’s pretty limited even in terms of providing a baseline, and it definitely doesn’t help identify and prioritize the things you need to fix. Even in terms of success criteria, it’s not very useful. Would increasing your maturity to level 3 be a good thing? Why? What value would that deliver to your customers?
Here are some of the things that can be a much more useful focus for assessment than maturity:
- Customer satisfaction: How happy are your customers with the services you deliver? What are the trends? What are the issues that they feel most strongly about? What do they currently like about your services? If you’re intending to make improvements, then you’d better make sure your changes have a positive impact on how your customers feel – and you’d better make sure you preserve the things that customers like.
- Service outcomes: How well do your IT services help your customers achieve their business goals? It’s not enough to focus on your service output (what the service delivers). You need to focus your efforts on thinking about how your customers use the service and how this creates value for them (what the customers achieve). Improvements that result in better service outcomes are the ones that really make a difference.
- SLA Achievements: Most IT organizations have service level agreements (SLAs) that document the things they have agreed with their customers. It’s important to measure how well you are delivering these and to monitor trends over time. Such measurements can be a good indicator of how effective your improvements are – but remember that customer satisfaction and service outcomes are what really matter. It is almost always a bad idea to prioritize SLA achievements over these.
- IT staff competence: Everybody says that good IT services depend on people, process, products, and partners – but we sometimes neglect the people element. Do your employees have the knowledge and ability to carry out their roles and deliver agreed services? What plans are in place to ensure that you have the skills and competence you’re going to need in the future? This isn’t just about technical skills, but about all the different capabilities you need in your staff.
Once you have reviewed these aspects of your organization, you may want to consider reviewing the effectiveness and efficiency of your ITSM processes. A process assessment
can help to identify things that need to be improved – and even more importantly, it can help to identify things that are good so you can encourage people to do more of them. But don’t get too focused on internal goals and metrics; it’s how well you’re meeting your customers’ needs that counts. If your improvement activities stay focused on that, then you can be sure you’ll never lose sight of what’s important.
If you still want to carry out a maturity assessment then you should read this blog by SysAid CEO Sarah Lahav
, for another viewpoint.
Posted by Nicole Katz
on March 16, 2016 in Service Desk
Working in IT can be difficult at the best of times, with operational and organizational change often a particularly difficult “nut to crack.” We can, of course, use proven methodologies and techniques, such as those by Lewin
for organizational change or PRINCE2
for project management and development, but sometimes there is a very-human “spanner thrown in the works” – that of “undermining behavior.” And of course this does not only happen in times of change, and it does not only happen in IT, but when it does happen, it is wise to understand how to spot it and then how to deal with it.
This blog relates to a personal experience with undermining behavior and offers advice for dealing with it. IT is ultimately about people working together effectively and any such barriers to success need to be prevented wherever possible.
Undermining Behavior is Not Always Easy to Spot
A new IT procurement process had been designed in a collaborative and inclusive manner, tested with multiple focus groups, and people trained across all the IT teams. Yet, for some reason, one IT team could not reach the desired metrics and outcomes of the new process.
We retrained that IT team. But there was no improvement. We talked with the IT team’s leader regarding the importance of the new procurement process. We were assured that the IT team understood the importance of the new process. We even received a commitment that the IT team’s leader would actively provide feedback on where his team was having difficulty with the new process. And, true to his word, he did provide specific occurrences showing where and how the new procurement process caused undue burden on his team.
It just didn’t make sense. Why did the new procurement process work for all other IT teams but seemed to fail only in this team? The data supported what the team leader was telling us – the new procurement process was unworkable for his team.
Sadly Firefighters Can Make the Best Arsonists
Thankfully though, the mystery was solved through a chance meeting with a team member from the affected team. The team member told me that the team leader did not like the new procurement process. Because the new process took the team leader out of the role of “IT hero.”
The team leader would no longer get to “save the day” for the customer, as the new procurement process made the data and outcomes more transparent. And so the team leader instructed his team to ask additional questions and to gather extra data that did not have a defined procedure for processing – thus making the new process untenable, time-wise, for the procurement task at hand. The team members would then ask what step to take with the additional data to which the team leader would reply “Don’t worry about it, I’ll handle it.” The team leader was undermining the new process to retain his position as an IT hero. The undermining of the new process for “personal gain” had caused myself and colleagues wasted time and effort, and had put the new cost-saving process in jeopardy for his own selfish reasons.
Hopefully, a similar experience has not happened to you. But if it has, or if you think it may, here are some tips to help spot and deal with such undermining behaviors.
What is “Undermining Behavior”?
A common definition for the term “undermine” is “to erode the base or foundation
” or “to weaken or damage (someone or something), especially gradually or insidiously.
” So to undermine is to weaken the position, goals, or success of something or someone – with “undermining behavior” in the workplace being the acts of another that are intended to either derail you and your intentions, or to promote the other person’s agenda at the expense of yours. It’s often done in an underhanded, secretive, or manipulative way with the aim of preventing you from achieving your objectives.
There are some common signs that you, your IT team, or your work are being undermined:
- You feel that you have to defend your position. When you engage with someone undermining you, you may feel that you have to defend your statements, thoughts, and concepts. You may feel like you have to prove yourself, but oddly you don’t know why.
- You feel “oversold.” The person undermining you might be very nurturing. They may tell you how much they care. They routinely explain how supportive they are and how they are helping you succeed. You feel comfort in their words but wonder why they are continually bringing the topic up for discussion
- You get “backhanded” compliments. A backhanded compliment is one that makes you feel good when you hear it, but then it gets worse the longer you think about it. For example, “You did well to recover that IT service after your mistake” – which on the face of it is recognizing your sterling efforts, but was it really said to point out that the adverse IT, and potentially business, situation was caused by your mistake?
- You are presented with desirable alternatives. The person undermining you offers alternatives that seem to better position you to reach your goals or objectives. However they are merely providing temptation to change to something that will ultimately favor their plan over yours.
What to Do if You Feel that You Are Being Undermined
There are a number of approaches you can take when you are, or think you are, being undermined:
So there you have it, what do you do when you feel that you are being undermined at work?
- Validate your sensitivity. If you are highly sensitive to what others say and do, then you could potentially perceive undermining when it is not present. So if you think undermining is occurring, discretely ask other members of your IT team if these “signs” are also occurring from their perspective. People who actively undermine others rarely contain their effort to one individual.
- Determine why they are undermining. The person doing the undermining might have a number of reasons for the behavior. They might be jealous, wanting the power or glory they perceive you to have. They might be competitive, doing whatever is necessary to succeed. They might truly be concerned that your plan is not in the best interest of your career or good for the company. Regardless of the reason, understanding their reason, or reasons, will help you plan how to deal with the issue, especially when the underminer is a close IT colleague.
- Explain your goals and why they are important. There is always the possibility that the person undermining may not be aware of the behavior. You should take the time to explain what you are doing, why you are doing it, and the behavior(s) you are seeing displayed. Keeping open and transparent communications gives you the opportunity to address any real issues and should also help the person undermining to understand why their impartial participation is necessary and important. Plus you should be able to address any misconceptions and to achieve an amicable working agreement for going forward.
- Control the information. If it is clear that the person cannot/will not change their behavior, simply cut off the flow of information to them. Stop inviting them to meetings where possible, and keep excellent documentation on interactions with the person including the behaviors you see/experience. Escalation to a supervisor should be the option of last resort, but having a well-documented story is necessary for this step.
- Don’t let your frustration show. While this is much easier said than done, keeping your frustrations hidden actually undermines the activities of the person. This may also lessen their resolve to display behaviors that undermine. Sadly, showing frustration can be a fuel source for many underminers that keeps them behaving in detrimental ways.
Posted by Greg Sanker
on March 9, 2016 in ITIL
Recently I presented a webinar
on getting started with service catalog. It's a topic that comes up often because getting started can be harder than it looks – especially without the support of a full IT service management (ITSM) program. If you know you need a service catalog but aren’t sure where to get started, the webinar offers a practical approach to get you up and going with a basic service catalog.
Some of the common challenges that organizations face when trying to build the service catalog are:
- Staff may think: ”Our users know what we do”
- IT services evolve too rapidly
- Changes are made with little formal change management
- Siloed organization: poor/informal communication between teams - app dev, infrastructure, and support
- “We are technology (not service) providers”
- Lack of service owners
- Cultural resistance
- Lack of organizational support
- Lack of time and attention to build it
- Thinking that 'service catalog' is a document – “We already have one...somewhere...”
If any of these sound familiar, I encourage you to watch the webinar
and download the whitepaper
Your Questions and My Answers
Below are my answers to some questions asked during the webinar.
"If you need to create a request catalog within a very short timeframe, what is the least amount of information you would recommend to publish in a live catalog, before being able to circle back and add/fill in more information?"
Kind of a 'minimum viable product’ approach. I like the question, partly because it's realistic. Of course, the balance you’re getting at is that it will take some time to gather the information I described in the webinar, delaying publishing a catalog. This is why I strongly recommend starting with a very basic service description. I like the saying "if you can't explain it to a six year old, you don't understand it well enough" (or something like that). The bottom line is that it should be relatively simple to write a paragraph or two describing the service. Getting bits and pieces of that description from as many people who know parts is the strategy I highly recommend. In so doing, you both get a complete picture, but you also get the buy-in of those who contributed to the effort.
So, to answer the question directly: a one or two paragraph description is the minimum amount of information on which to base your first service catalog.
"Can we have an example of a good service catalog?"
I wrote a whitepaper to go along with the webinar that has a pretty decent sample in it. You can download it here
. Hopefully it will get you going in the right direction.
"Can I use <several tool vendors mentioned> for ITSM just like other vendors available on the market?"
There are lots of effective tools for service catalog. Honestly, though, the greater challenge, by far, will be the cultural aspects addressed in the webinar. There's no magic solution to make that part easy, which is why I encourage you to focus on the people and the process long before looking at tools. This is my recommendation even if you already have a tool. Keep it simple and focus your efforts on the people and the process. Once you've done the hard part – as I addressed in the webinar – implementing it in a tool is a snap.
"Typically, what does each item in a service catalog link to? Help Desk requests? General documentation? Just curious to see or hear about examples."
This gets to a point that I only lightly touched on during the webinar – the difference between a service catalog and a service request catalog. In short, a service catalog is a listing of available services. Clicking on a service generally brings up additional details about the service, and likely includes a "how to request service" section.
A service request catalog is automated, so clicking on the service takes you directly to a request form of some type – making it very simple to find, select, and request a service. The obvious analogy is the online shopping cart. Online retailers have mastered the art of making it easy to find what you're looking for (and often stumble upon some things you didn't even know you needed!), and making it super easy to get in your cart.
"How do you handle third-party and hosted systems?"
I think the question has to do with implementing a service catalog on a hosted ITSM tool, which can vary quite a bit between the various vendors. I’m far from an expert in the various tools out there, but there are two key things you want to keep in mind:
- Make sure it’s easy for users to find the services they need
- Easy integration with the rest of your ITSM solution
These are key regardless of the tool or hosting arrangement.
"What is the best way to determine the frequency of the service catalog update for a particular company?"
The challenge is doing it often enough to keep it current, but not too frequently that people start feeling like it’s taking up a lot of their time. It’s something you kind of have to size up according to the culture of your organization.
Yearly is the least frequent I’d recommend. Ideally, I like having a quarterly review – maybe even tied in with a quarterly service review, or customer meetings.
"Would you use a service catalog as a starting point to agree on SLA's? Should they be included in the catalog?”
It depends how well established SLAs are in the organization. For organizations who are just establishing what their services are – SLAs probably either don’t exist, or are just being introduced. My concern is introducing two concepts at once – the service catalog and SLAs.
On the other hand, if your organization has had SLAs in place for some time, and both IT and the business understand them, then they should be included (to help users understand what they can expect of the service).
"What if our customers are both non-IT and IT users who would be using the Service Catalog? How do we gear the Catalog for both?"
I like the concept of a multi-viewed catalog – a customer view and an IT view. It’s a concept buried in the ITIL books, and it can be really helpful. The customer view should be focused on the details important to end users, and the IT view should highlight the technology components and how they’re integrated to deliver the service.
"Do you recommend a category and a sub-category of service catalog?”
During the webinar, I talked quite a bit about making it easy for users to find what they’re looking for. I’m a fan of broad categories – like “computing services” and “phone and voice services” with no further sub-categories. One of the elements of good user interface design is limiting the number of clicks required to find what the user is looking for. Drilling down to multiple sub-categories, which may seem logical (especially to us techies), can make it harder for users to find what they’re looking for.
Also – keep in mind that we IT people think differently than our customers. What makes perfect sense to us may completely confuse our users.
It’s also worth mentioning that it’s a good idea for users to be able to find services in various ways, like alphabetical listing and keyword searching.
"For your internal view of your service catalog, should you link your more detailed service catalog items to standard operating procedures or should SOP's be separate?"
In concept, I like having everything nicely linked and easy to find. But in practice, this is where a service catalog effort can really struggle – trying to do too much too soon, and losing support. I’d much rather see success with a very basic service catalog with strong cultural support for it, and then continually improving it – with the input and involvement of stakeholders.
"How can we determine the best level of granularity/detail to include in the service catalog?"
A good question that actually gets to the heart of my webinar. To answer the question, you have to get the experts in your organization involved. I talked quite a bit about ‘tribal knowledge’ – the idea that the details of your services are known in part by many different subject matter experts in the organization. The goal is to leverage that knowledge and create descriptions that the ‘tribe’ agrees to
in the end.
Keep in mind that it’s far, far better to be successful with a very basic service catalog and improve it over time than to start too big and fall short.
"How can we involve the end users in performing the service catalog?"
Here’s a question that I love – how to get your customers involved. I really like it because that’s where it has to start – with the customer perspective, and what better way than to get them involved. But how?
Most organizations have what I call “IT-friendly” users out in the business. Those people who other users go to for help and questions before they call IT. If you don’t know who they are, ask your service desk team. They do. Form a users advisory group and ask for their help in shaping the service catalog. (Many major software vendors have been dong this successfully with beta programs, power users forums, and advanced releases.)
If you do a customer survey, ask if they would be willing to serve on a focus panel, and form a group to review the service catalog.
If you have relationship management, do service reviews, or hold other customer meetings; put the service catalog on the agenda and ask for feedback.
"If I was starting from nothing should we start small and grow out services; was thinking of building internal IT services first and then learn and build out. Does this seem a reasonable approach?"
Couldn’t have said it better myself. Yes; that’s exactly what I’d recommend. Remember that a big part of the challenge is getting the culture of your organization to adopt the service catalog into daily operation. By starting small and gaining momentum, you’re greatly increasing the odds of successful adoption.
I also like that you highlight learning as you go
. This is really important even if you’re very familiar with service catalog – you want the people in your organization to learn about service catalog, and get engaged in improving it as you go along.
"Some services have nothing to do with technology (e.g. consulting).... "
That’s absolutely right. And if there are non-technology services you offer – include them in the service catalog.
You’ll want to be sure they’re defined as services (not activities).
- Be recognized by users as a solution
- Support a business process
- Include all the technology components
Thanks everyone who attended the webinar, and thanks for all the great questions. If you haven’t had a chance, you can still watch the recording
Good luck with your service catalog!
Posted by Reuben Solomon
on March 2, 2016 in Service Desk
Working on an IT service desk can be a thankless task at times. There’s a reason why it’s generally accepted that there is often a finite shelf life for people in the service desk agent role. If your IT service desk is of the “log it and flog it” variety, where the ticket is logged and transferred to a specific resolution group if it isn't a super-easy fix, it can feel like you are working in a never ending loop
Feeling enslaved to your telephone and computer can be dreadful. It can be a serious drain on morale, with a direct impact on how motivated you are to do your job. Then there are the irate end users – unhappy either that their IT isn’t as it should be or because they aren’t being treated with the importance that they think they deserve.
Factor these in with the heavy workloads, multitasking expectations, and potentially long days and it can be hard to stay focused. And tiredness and a general feeling of boredom do not make for the most effective service desk analysts.
So what can you do to get your service desk mojo back? And how do you sell the change to your boss?
1 – Rediscover What You Love About Your Service Desk Job
Chances are that you started on the service desk because you wanted to help people. So spending time within the business, with your colleagues and customers, can help. Hopefully you will see issues and problems being experienced that may well be going unreported. Or you will see opportunities for technology-use improvement. Spending time in this way will also give you further insight into how the business views the service desk, and hopefully remind you of the importance of your service desk role in keeping people and business operations working.
How to sell it to your boss:
Concentrate on the benefits to the service desk. Insight into the struggles of your end users will help to shape the services that your team provides.
2 – Keep Learning, Maybe “Shadow” Someone Higher Up the IT Hierarchy
You may have already decided that working on a service desk long term is not for you. You may have an idea of the direction that you would like your career to take. Or you may not. Either way, “shadowing” someone else in the organization – that’s working with another employee in a different job who might have something to teach– will give you experience of what their job entails. It may cement how you feel about the new role or scare you off completely. At the very least it will give you insight into what these other roles or teams deal with on a daily basis.
How to sell it to your boss:
Many service desks experience a degree of conflict with other IT teams. Working within these teams can help service desk agents to appreciate the other side of the argument. Experiencing the challenges of these teams helps with empathy and maybe could even lead to a change in inter-team working practices.
3 – Change of Scenery, Maybe Apply for a Secondment
Shadowing another role is fantastic but do you know what's potentially even better for your service desk blues? Actually doing the other role. Getting to perform an alternative role on a temporary basis –what my British colleagues call a secondment – will give you a fantastic experience and a change from the old routine (and the associated pressures). It’s an excellent opportunity for you to see if this is something you could see yourself doing longer term.
How to sell it to your boss:
Can you see a spot where there is pressure building within another IT team – usually evidenced by work backlogs and delays? Could you help to reduce it by stepping in for a while? An externally-sourced temporary staff member might not have been considered due to the time and energy it would take to train someone in the nuances of your business. But you already have this knowledge and can “hit the ground running.” It may also be easier to recruit a replacement service desk analyst to temporarily back-fill you than for a more specialized position.
4 – Take on a “Project” Role
Sometimes a “bit of a change” is as good as a complete change. Taking on something new for a finite amount of time, i.e. a hands-on project that is longer and more involved than a secondment, may give you the break from the service desk that you need. Flexing your brain, and skills you don’t normally get to use, on something new even for a short while can help to stave off boredom and reignite your passion for your role once you return to it.
You may find that the project role suits you or that the project area is something that you excel at. Succeeding at a project, either individually or as part of a larger team, is also a great way to get yourself noticed if you are trying to climb the career ladder. Project management methodology, whether you are formally trained in it or are just obliged to follow it on others’ instructions, can also be brought back into the service desk environment to help with day-to-day operations and improvement opportunities.
How to sell it to your boss:
Working on a project will help you to gain insight and knowledge in other areas – this could be either in business operations or a new technology. If the project is on a new application or business service you can also propose that you become the go-to person on the service desk after it goes live. An extra benefit to the service desk is having someone who can forewarn them of upcoming changes. As someone who has never worked on a service desk might miss the importance of involving it during the project. I’m sure that most of the service desk agents and managers who read this will have horror stories to tell about when a delivered project caused a massive spike in service desk tickets.
5 – Make a Plan of Where You Want to be Career-Wise and How to Get There
Is your career lacking direction? Could this be the reason why you are lacking motivation? Now is a great time to sit and think about where you want your career to go.
Don't have any definite ideas? Then start with what you don't want to do and move forward from there. You can always use the previous tips to experience different things until you find something you think that you will love.
Already know where you want your career to go? Well then, it’s time to think about training and courses that can help to support you in your journey. Again the previous tips can also help.
How to sell it to your boss:
Is the training also of benefit to your service desk role and the service desk as a whole? If so, then you should have minimal issues persuading your manager to support you (and to hopefully fund it). If they say that there is no budget, then see if you can find out when there will be budget. Go armed with information about the course you want to go on. If possible, take several different versions with different prices. Got the kind of manager that will always pick the cheapest option? Make a pros and cons list for each of them. Ultimately, make it as easy as possible for your manager to say yes, and to make their decision based on value rather than cost.
6 – Tell Your Boss About Your “Situation”
While you are ultimately responsible for your on-the-job motivation and performance, and career path, our manager has a responsibility too – not only to get the most out of you work-wise but also to ensure that staff are developed to provide maximum value to the organization. So have a chat with your boss at your next one-on-one meeting or performance review. You never know, they might have been in a similar position at some point in their career. Even if they haven’t, a good boss should be able to help through assessing possible internal changes and/or helping to find you temporary opportunities outside of the service desk.
How to sell it to your boss:
You shouldn’t have to if your boss is worth working for.
Over to You…
It’s inevitable that you’ll encounter periods of low energy at some point in your career. So remember that you have the power to overcome your slump. Hopefully these six tips can help you to renew your motivation and to become a happier service desk analyst (with a career plan) again.
My six tips are just a handful of possible options. What are your tips for getting out of a motivation slump?
Posted by Joe The IT Guy
on February 25, 2016 in ITSM
As always, the annual Pink Elephant IT service management (ITSM) conference (and Las Vegas itself) was a blast. Some of what happened in Vegas of course has to stay in Vegas, but much of the session content deserves to be shared with a wider audience. You’ve heard of “Joe Public,” well you can now think of me as Joe Public Service.
It’s not easy when you’re an intergalactic ITSM superstar but, with the help of a blonde wig, sunglasses, and a few pseudonyms, I was able to sneak into a number of Pink16 sessions without the attendees being distracted from the presenter by my sheer awesomeness. Sadly, it happens a lot if I don’t go in a little like Daniel Radcliffe at Comic-Con
My Pink16 Key Learnings
Learning number one, unfortunately, is that people still know that it’s me if I try the Spider-man suit approach. It didn’t help at Pink16 that The IT Skeptic
didn’t follow my lead with a superhero pants-outside-the-tights costume. So I won’t try that again.
I did get some good ITSM learning though. If you read my good friend Dena Wieder-Freiden
’s pre-Pink16 blog
, you’ll notice that I took her advice on which sessions to attend. Plus, I snuck into fellow New Yorker Alan Berkson
’s session on enterprise service management.
So here is my session-by-session breakdown…
One of the great things about Rob’s presentation was that it joined, or pulled, a number of things that we tend to talk about in isolation together. Just as the Renaissance period between the Middle Ages and modern history was filled with new ideas, a new culture, new ways of thinking, and a new beginning, Rob’s concept of “The IT Renaissance” covered:
- New ideas
- A new IT culture
- A new way of doing IT
- A new beginning
Hopefully Rob won’t mind me borrowing four of his Pink16 slides (© Two Hills Ltd.) to articulate his points (and to save on my typing):
“Don’t Rain On My ITSM Parade – Transitional Change Management When Moving to the Cloud” with Earl Begley
You can’t beat good quality practitioner presentations at ITSM industry events. It was great to hear Earl talking to why the University of Kentucky made the move to the cloud – it might be similar to what cloud vendor marketing collateral says, but it’s great to hear it from the horse’s mouth:
- The inability of the infrastructure team to scale configurations to meet peak loads for critical academic events
- Shrinking operational budgets, meaning longer gaps in hardware refresh and limited opportunity to change architecture
- Increasing labor time spent on maintenance functions versus new project/creative solution work
- Risks around natural disasters, security, and resource management
And no, I’m not saying you’re a horse Earl.
In his offered lessons learned, Earl used two great images* in particular to talk about how:
Practice is different to theory
User experience will always trump design
I’ll definitely be stealing them for my future presentations.
“Why Governance of Enterprise IT (GEIT) Is Not a 4 Letter Word!” with Robert E. Stroud
Firstly, you have to watch Rob Stroud and his four-letter words!
One of the key things that I took away from Rob’s presentation is the ISACA
, or at least Rob’s, multi-faceted definition of IT governance:
- “IT Governance is the responsibility of executives and the board of directors, and consists of the leadership, organizational structures and processes that ensure that enterprise IT sustains the organization's strategies and objectives.”
- Integrate and institutionalize good practices
- Take full advantage of information
- Satisfy quality, fiduciary, and security requirements
- Optimize resources
- Balance risk versus return
And that it’s all too easy to have a narrower view of what IT governance is, probably determined by the limitations of our knowledge of different governance capabilities. I’d bet that if we asked eleven people to define IT governance that we’d get at least ten different definitions.
Also that governance and management are different, in that:
- Governance ensures that stakeholder needs, conditions, and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritization and decision making; monitoring performance, compliance, and progress against agreed direction and objectives.
- Management plans, builds, runs, and monitors activities in alignment with the direction set by the governance body to achieve the enterprise objectives.
Finally, Rob showed a great visual representation of how COBIT
fits in with ITIL and other IT frameworks and standards:
“Helping Managers Enhance Skills & Services With ITIL Practitioner” with Kaimar Karu
Kaimar started by covering the skills gaps in modern-day ITSM:
- Challenges with communication
- Challenges with metrics and measurement
- Challenges with organizational change management
His slide on “understanding how good metrics help” was of great importance to all those of us just “going through the motions” with their ITSM metrics – you know what I mean, the endless cycle of collect-report-collect-report with little done outside of this. Instead, ITSM metrics should:
- Support validating decisions and assumptions
- Set a clear direction for activities and improvements
- Justify what we do and why we do it
- Provide the means of healthy intervention for failing services
- Utilize balanced, meaningful KPIs
- Link the vision, mission, objectives, goals, CSFs, and KPIs
But where was the free craft beer you promised me Kaimar?
“Enterprise Service Management: It’s Time To Share ITSM Best Practices Outside Of IT” with Alan Berkson
Of course anything said by a native New Yorker sounds great and has a good chance of being ITSM gold dust… or at least that’s what I tell my boss
It was great to be reminded that IT didn’t invent service management. Plus, that IT isn’t the only corporate service provider that can benefit from service management or, for that matter, ITSM. Also that enterprise service management (or whatever you prefer to call it) is nothing new – with ITSM technology used by other business functions for at least the last decade.
I especially took away Alan’s suggestions for improving an organization’s chances of enterprise service management success:
- Don’t treat enterprise service management as an IT project
- Allow for the differences between different business functions
- Don’t try to help other corporate service providers before helping yourself
- Don’t assume that enterprise service management will sell itself – justify it in business terms
- Think long and hard about how to deliver the enterprise service management project – starting small, focusing on a single business function or capability
Who’d have thought Alan went to school with Dena? It IS a small world after all
So some great ITSM learning from Pink16, although I’m sure Dena will put it down to her great session selections. If you were there, what nuggets did you come away with?
*Earl’s image sources:
Posted by Stuart Rance
on February 24, 2016 in Service Desk
Great IT services create value for customers, with a focus on customer experience
and customer satisfaction
. Organizations that deliver IT services must manage a balance of people, processes, and technology. When it comes to people you need to consider the skills and behavior of IT staff, but it is even more important to focus on the most important people, your customers. This is not a new message, but it bears repeating because far too often the main focus of the people delivering IT services continues to be on the technology and the processes.
A Team with No Customers!
I was teaching an IT service management (ITSM) training course recently, and some of the students worked in a group that managed infrastructure. They delivered storage, servers, and networking to application teams, who used these as building blocks to create IT services for the business. I asked some of these students who their customers were, and they said that they didn’t have any customers. Really?!
This reminded me of another organization where I worked some years ago, where there was a team who configured and deployed monitoring software to thousands of servers. People on the operations bridge told me that the monitoring software generated thousands of red alerts every day, and they picked out the really critical ones, ignoring the others. This was obviously a very risky way to detect events so I asked the team responsible for the monitoring software who their customer was. “We don’t have customers,” I was told, “we just configure and install the software.” This team had all the skills needed to configure the software correctly, but they had completely failed to consider the needs of their customers – because they didn’t’ think they had customers!
My students eventually recognized that they did have customers – the application teams who built services using the infrastructure that they provided. This was a definite improvement, but it didn’t go nearly far enough.
If teams within an organization see each other as customers, then they tend to focus on internal issues, and lose sight of the real customers, the ones that actually fund everything they do. The key thing to remember is that the external customers of the business provide the money that enables all of the business activities to take place. Activities that help to create value for the paying customers are worthwhile; and anything that doesn’t, is wasted effort.
As I worked with the students from the infrastructure team we established that they provide services to the application team, who in turn provide services to a business unit, who create value for the paying customer. Although it is very difficult for the infrastructure team to consider the needs, and experiences, of the paying customer at the end of this chain, it is essential that they keep this paying customer in mind when they are working if they are to provide that paying customer with great service.
Like every other part of the organization, the infrastructure teams need to focus on customer value creation, customer experience, and customer satisfaction.
- Customer value creation. I once had a really wise manager who said to me “At least once a day, you should stop whatever you’re doing and ask yourself ‘If the paying customers knew their money was being used to fund what you are doing right now, how would they feel?’. If you aren’t 100% sure that they would be happy then you should stop doing it.” I have followed this advice ever since, and it has been of huge value to me. Everybody in the entire value chain should be focused on creation of value for the paying customer.
- Customer experience. Every interaction with the customer contributes to their overall experience. If you are designing a process, or a web form, or any other potential interaction with a customer, then you should base your design on an understanding of their needs. Ideally you should include customers into the design of everything that might potentially impact them. In the case of the infrastructure team, they should definitely consider the needs of their internal customers, the application team, but they should also think about how anything they do might impact the experience of the business units and of the real paying customers.
- Customer satisfaction. Everyone contributes to customer satisfaction. Sometimes by positive acts that delight customers, and other times by failing to notice the impact of actions on the customer. Customer satisfaction comes from their entire “customer journey” – every interaction with the customer makes a contribution. We need to set their expectations correctly and then reliably deliver what they are expecting in a way that creates positive experiences. If you aren’t dealing directly with paying customers that doesn’t mean that you have no impact on their satisfaction, it just means that you have to work really hard to understand your impact.
The key thing to understand from all this is that all the different parts of an organization need to collaborate to ensure they delight their customers. If all the teams in the organization treat each other as suppliers and customers then they may manage to cooperate, but this just isn’t enough. Everyone must collaborate to achieve a common goal of delighting the paying customers. That way the business will grow and everyone will succeed.
Posted by Joe The IT Guy
on February 16, 2016 in ITIL
In part 1
of this blog, I focused on what to look, and ask, for when assessing a change. Here, in part 2, I go further, and beyond the impact assessment, to look at minimizing the potential for adverse IT and business impact from poorly planned or executed changes.
You could argue that the title of my blog is now inappropriate but, in my opinion, it’s good to talk about change impact and the potential risks rather than change management per se. You could argue that this blog also dips its toes into release management too. But, if you have time to argue about blog titles, you probably need to find a more engaging job.
Don’t Skimp on Change and Release Planning
Sadly, it’s not just a case of hitting a big red button and cackling “fly my pretties, fly.” A good plan clearly sets out who does what, where, and at what time. Sounds simple but I’ve lost count of the amount of time I’ve had to spend rounding up engineers that were distracted mid-change or just weren’t aware of what they should be doing… “Oh right, that was today wasn’t it?”
Sometimes it’s like herding cats. So make sure that you’ve got any handover periods highlighted and primary and secondary contact details for everyone involved. Mobile signals can drop and Exchange servers can glitch, so make sure the people involved are contactable at key times.
Post-Implementation Testing Can Make a Big Difference
How do we know the change was successful? “Okay people, we’ve deployed the change and nothing looks hideously wrong. Back away quietly and don’t make any sudden movements.” Does it sound vaguely familiar?
It’s important to run a few tests. To have a few simple tasks to ensure that not only has the change been deployed but that all relevant services are up – with everything as it should be. “Trust but verify” is the name of the game here.
You don’t have to “rock the world” but simple things like making sure that all the shared drives/folders are available on a WinTel server, or that system traffic is running correctly over your network, are simple things that can make the world of difference to your customers and end users, and to ongoing business operations.
Don’t Forget the Back-Out Plan
With the best will in the world, even if you’ve done everything right before the change, something unexpected could still pop up. Hardware failures, power spikes, and code glitches all can, and do, happen – so you need to have a robust plan in case something goes wrong during the implementation window.
So consider how you’ll deal with something unforeseen. Can you roll back, fix on fail, or do something else? There’s no right answer here, just make sure that if something does go wrong, then you have a plan to restore service – with the appropriate timings built into the change window. Also ensure that the team of people implementing your change are empowered to make decisions and if there are points during the change window that we know pose particular risks, schedule a quick call with involved parties to discuss them.
Other Environments Matter Too
Which environment are we applying the change to? Don’t give me that look. I know that we’re overrun with changes to our production environments, but other environments such as pre-production or DR (disaster recovery) are important too.
Why should you be worried about DR environments? A friend of mine onceworked for a large investment bank in the city. And during a code change to one of the bank’s most business-critical systems – the market data feed to the trade floors – things were taking a little longer than expected. So, ignoring what was written in the change plan, the decision was made to only update the production environment. It was always the plan for the implementation team to go back to update the DR environment but, as tends to happen in the busy land of IT, they got distracted by other operational priorities and it was never done.
Fast-forward six weeks and a crisis hit the trading floor. The call is made to invoke DR but they couldn’t because the market data services were out of sync. Cue a hugely stressful two hours where the whole IT organization desperately scrambled to find a fix. The business impact here was estimated at over US$8 million – not a mistake that any IT professional wants to be held responsible for. Well, not if they want to stay employed.
By asking the right questions (and using templates or change models to make raising changes less painful), not only do you mitigate adverse business risk, if something does go wrong, but you can support incident management activity in fixing things as quickly as possible. You can also support problem management in identifying or confirming the root cause before raising the appropriate actions to ensure the similar future changes don’t fail. You’re never going to be able to achieve “bulletproof” change management but using the list in the first blog
, and covering the points made in this one, it will help to ensure that you are at least consistent – which will go a long way to reducing risk and the potential for any disruptions in business operations.
What are your top tips for change impact assessment?
Posted by Joe The IT Guy
on February 9, 2016 in ITIL
One of the things that worries me most about where the IT industry is headed is how we sometimes get so caught up in “the new stuff” that we forget to make sure that we have all the basics covered. A good example is change management, which can be easily overlooked while we’re looking at, and then researching, the newest and shiniest trends, and technologies, in the world of IT and IT service management (ITSM).
Unfortunately IT change doesn’t happen in isolation. In fact, these days it’s common for IT change to be business change – and it can impact the whole organization around it, and all the people touched by it. Consequently, changes that are inadequately assessed, managed, and reviewed can have a significantly harmful impact on both IT and business operations. In my opinion, not taking change seriously is akin to playing business-continuity Russian roulette.
Of course change will always involve a certain level of risk, but taking the time to properly assess the impact of a change can make things significantly less risky for everyone involved. Ultimately, it doesn’t matter how brilliant your service desk is, or how talented your tech support people are, if you get changes right the first time, you’ll break less things, generate less incidents, and have happier end users. It’s a win, win, win situation!
What to Look for When Assessing a Change
I’ve seen some pretty poor excuses for change requests in my time. Some have been so bad that they’ve resulted in me going to the requesters to find out what I’ve done to make them hate me. Remember though that some of your colleagues will request changes very infrequently and so, to save them time and energy, and yourself from head-butting the wall, it’s worth having a check list of everything you need to adequately consider a request for change:
Well, that’s it for Part 1. I’ll return with Part 2 to cover implementation planning, post-implementation testing, back-out plans, and more. In the meantime I’d love to hear any change assessment advice you can share.
- Change title. Is the title clear and does it make sense? It’s not rocket science but when you’re working through lots of changes, possibly with your change advisory board (CAB), you might need to instantly be able to tell what something is and what it’s trying to achieve.
- Change description. Is the description easy to understand and is it written in clear business language, or at least in something that you can easily translate to the rest of the organization when seeking customer approval? The last thing you want is to have to come away and ask more questions of the requester. You want the business to have faith in you knowing what you’re doing and, if you can’t explain what you’re trying to achieve to them, you might as well just tell them that you don’t have a clue.
- Change reason. Why do we need to do this change? It sounds obvious, but once I had a change request appear in my queue where the server support analyst wanted to move a business-critical server, which hosted the transactional part of the corporate website, from a secure data center to under his desk because, and I quote, “My legs are getting tired walking to and from the server room.” I hope you’ll agree that this wasn’t an acceptable reason for a change. So to be better at change assessment, we don’t just want to know why we want to do a change, we also need to know how it will benefit the business.
- The systems/services/groups/users affected by the change. In order to let your stakeholders know that they won’t be able to access something, or if there is a risk-involving change proposed, you need to know whose IT and business services and operations will be affected by a change request. Ideally, this information will be driven by your CMDB, as this should give you the most up-to-date and trustworthy information. If you’re unable to use your CMDB for this task, it’s still vitally important to have this impact information available to identify and inform interested parties. You can do this manually using a spreadsheet or you might be able to pull it from your service catalog. The important thing is that you do it.
- Risk assessment. What happens if it all goes wrong? In my experience, too many people choose “medium risk” when requesting a change because they either don’t know, or don’t care, what the risk actually is. There really is no excuse for this and I suggest using a change management risk matrix in your organization, like the one on page 17 in this change management process guide, so that change requesters can select a tangible, meaningful level of risk that’s appropriate for the work being carried out. This also gives the change assessor(s) added peace of mind that the risk category hasn’t been chosen at random.
Posted by Dennis Drogseth
on February 4, 2016 in ITSM
In preparing for this blog I interviewed
a global support manager at an international agribusiness corporation where SysAid was enabling increased end-user responsiveness, improved asset and change management, and enhanced OpEx efficiencies overall. As it turned out, this very strong narrative aligned very well with EMA research data on how IT service management (ITSM) operational efficiencies are impacting IT OpEx effectiveness overall.
Looking at this bigger picture, the role of ITSM teams is growing, not shrinking in importance. ITSM is increasingly providing a source of governance and efficiency in supporting all of IT in incident and problem management, release management (including agile and DevOps), change management, and asset management. In many cases ITSM teams are also leading the charge in supporting mobile requirements both for IT service consumers and IT professionals for improved efficiencies. So given all these trends, which I’ll examine in a little more depth in this blog, I think it’s safe to say that ITSM operational efficiencies reside at the very center of improving IT efficiencies overall.
Before going any further, I should mention that the data points I’m referring to in this blog are taken from three different research projects: one on digital and IT transformation
; one on ITSM futures
, and one on next-generation asset management.
Let’s start with the growing role of ITSM teams in supporting IT more broadly. Workflow and scheduling are part of the reason why ITSM integrations reach out to support operations and other IT groups. This is especially true as workflows evolve into runbook requirements for operations and release management processes for application developers. For instance, our data also shows that improved operations-to-service desk integrations for incident and problem management is a number one ITSM strategic priority going forward. These integrations may feature workflow, shared analytics, leveraging configuration management database insights into service interdependencies, and combining trouble ticket data and user interaction with operational data on service performance—just as a few examples.
Improved operations integration with ITSM configuration management capabilities for change and configuration management comes in at second place. But perhaps the most surprising piece of news is that 80% of ITSM teams in our research either already had support for DevOps or planned to—through workflow or scheduling or even through provisioning via CMDBs and configuration management tools. In all of the areas mentioned here, ITSM efficiencies directly impact the efficiency of IT overall.
Another key area for ITSM is integrated support for asset management. Hardware and software asset management often become sinkholes of inefficiency in IT organizations. Here are just two key data points:
- IT organizations spend an average of ten hours a week reconciling data accuracy issues for asset inventory.
- IT organizations spend an average of more than 30 hours preparing for audits for compliance-related reasons (and 8% spent more than 100 hours).
Talk about OpEx efficiencies—this area is clearly a sweet spot for improvement that good ITSM /ITAM investments can help to rectify!
Now let’s talk about mobile. Mobile is changing the game for IT, and once again ITSM efficiencies stand in the forefront of making mobile access an effective reality. 78% of our ITSM respondents indicated that mobile support for IT service consumers either meaningfully, or dramatically, improved outcomes in terms of both IT efficiencies and end-user productivity. In another question, mobile showed strongly in both enabling improved responsiveness to IT service consumers and increasing IT efficiencies overall while reducing OpEx costs.
By now hopefully you can see the connection—whether through integrated workflow, project management, incident, problem or change management, ITAM and mobile support—ITSM operational efficiencies really do equal IT efficiencies overall. But how important are IT and ITSM efficiencies in the larger scheme of things? Insight on IT and ITSM efficiencies was the number one analytic priority for digital and IT transformation in our research. And when it came to business metrics, IT OpEx efficiencies were at the very top.
To explore one case study of an effective ITSM team who are providing the backbone to global business growth, please take a look at my Q&A here. This case looks at some of the key factors that enable greater IT efficiencies, including the adoption of a scalable ITSM solution that is simple to use and easy to deploy.