Are you going to the annual Service Desk and IT Support Show (SITS16) in London? It’s a free-to-attend IT service management (ITSM) and service desk event where not only do you get to see just about every ITSM tool vendor on the planet, and there’s a few, there’s also a wealth of great ITSM and service desk seminar content available to attendees. It’s not too late to register for the event, if you can get to London for the 8th or 9th of June.
I’m very pleased to be attending SITS again this year, it’s a great ITSM event, but the reality of attending has hit me – with so much quality seminar content to choose from, which sessions do you see and which do you sadly have insufficient time to make? At SysAid we call this “Sophie Danby’s choice,” that’s having to forgo quality presenters and topics due to the competing seminar streams. Unfortunately, it’s a common issue across the global ITSM event circuit that we never seem to be able to avoid.
So Who and What Should You Plan to See at SITS16?
If you are a regular visitor to the SysAid and Joe the IT Guyblogs, then you’ll know that I’m not going to spend my 1000 precious blogging words trying to brainwash you into visiting the SysAid stand at SITS (but you are of course more than welcome to come by to say hello, and our swag this year is seriously top-notch!). Instead, I’ll be talking about the seminar presenters and content that stand out for me.
If you know the ITSM industry, and the commonly-seen speakers, well then this blog might just be common sense for you. But, if you are looking for impartial help in selecting sessions at SITS, then please let me offer up a few, okay eight, suggestions based on my previous experiences at industry events.
1. Digital Transformation: How Will It Impact Service Desks?
Time: Wednesday, June 8, 9:30-10:10
Speaker: Andrew White
Andy White is an ITSM industry thoroughbred, so any opportunity to hear him speak needs a good excuse in order to miss it. In this session, Andy will present research findings from 50 CIOs about how their digital transformation journey is progressing and what this meant for IT operations. Andy will specifically talk about the conflicts and disagreement surrounding the CIOs’ strategies, the importance of digitizing core IT operations, not just front-end apps, and what digital transformation ultimately means for the IT service desk.
2. The New YOU – What an ITSM Professional Will Look Like in 2020
Time: Wednesday, June 8, 10:30-11:10
Speaker: Matthew Hooper
What do the next five years hold for ITSM professionals? Matt Hooper, a globally-renowned ITSM thinker and speaker, will tell you what he thinks in just 40 minutes (he might even let you ask questions). So attend Matt’s session to understand how DevOps, Shadow IT, cloud, and other disruptive movements are changing the IT landscape, such that corporate IT in 2020 will bear little resemblance to IT as we currently know it. Matt will also cover the critical skills gap developing and the opportunities this offers to ITSM professionals.
3. What’s Trending in the World of Service Desks?
Time: Wednesday, June 8, 12:30-1:10
Speaker: Ollie O’Donoghue
Ollie is the Service Desk Institute’s (SDI) resident industry analyst, who regularly undertakes the SDI’s member research and writes many of its white papers. In this session, Ollie will talk to the service desk and ITSM trends that SDI members are currently experiencing/expecting, based on the latest SDI research, and what service desk and ITSM professionals should be doing about them.
4. Life on the Service Desk in 2016 (and How to Improve It)
Time: Wednesday, June 8, 2:30-3:10
Speakers: Simon Johnson and Stephen Mann
At the end of 2015, the SDI conducted member-based research into the service desk “state of the nation”. In this session, Simon and Stephen will present the SDI survey results, outline the main causes of service desk concern and friction, and offer up practical ways to tackle the most-common obstacles and issues. This includes the key pain points for service desk analysts, their top frustrations with ITSM tools and vendors, and the top service desk priorities for 2016.
5. Intelligent Disobedience: The Future of Service Management?
Time: Wednesday, June 8, 3:30-4:10
Speaker: Ivor Macfarlane
Firstly, my apologies to my good friend Stuart Rance whose SIT16 session conflicts with Ivor’s – hopefully he knows that his session will be “standing room only” no matter what I blog about.
Here Ivor, an ITSM industry luminary, will talk about the need for “intelligent disobedience” on the service desk. How, as self-service and automation soak up the routine calls, the issues hitting the service desk are increasingly about exceptional conditions – meaning that service desk staff need more innovation and improvisation to deliver solutions and end-user satisfaction. Importantly, Ivor will explain that getting intelligent and committed staff isn’t the biggest challenge – that instead it’s getting managers to create an empowered environment in which service desk staff can flourish.
6. Time to Rethink Your ITSM
Time: Thursday, June 9, 10:30-11:10
Speaker: Patrick Bolger
It’s Patrick Bolger!
If I were braver I’d leave my session description as purely that. I’m not though, so let me tell you that, in this session, Patrick will outline the lessons that corporate IT and support can learn from modern consumer technologies. In particular, how these can be leveraged to provide the service experience that our customers really want, while reducing the demands on busy ITSM teams.
7. The Pros and Cons of Public and Private Cloud
Time: Thursday, June 9, 12:30-1:10
Speaker: Sarah Lahav
Hopefully you aren’t going to think less of me for including my boss’s session in this list :-).
In this session, Sarah will talk about how, even though cloud is now a well-accepted way to host and provision IT services, businesses still struggle with the decision between using public and private cloud. She will compare the pros and cons of each approach, referencing the five key cloud characteristics as laid down by National Institute of Standards and Technology, and using real-world examples to ease the decision making process.
8. Is Change Management Success as Simple as ABC?
Time: Thursday, June 9, 2:30-3:10
Speaker: Paul Wilkinson
If you have never seen Paul Wilkinson present, then you are in for a real treat at SITS16, as he is very animated and funny too!
Paul will tell us how and why 70% of organizations don’t get the hoped-for value from organizational change management, with more than 50% ironically failing because of resistance to change. With ABC (Attitude, Behaviour, Culture) being the number one success or fail factor for ITSM organizational change management, Paul will be offering practical advice for removing the points of resistance that commonly stop businesses from progressing.
So that’s eight SITS16 sessions I recommend. Enjoy the SITS seminars, vendor demos, peer networking, and swag opportunities. Hopefully we will also get to see you at our stand; feel free to pre-schedule a meeting. I promise not to try to sell you anything (unless of course you want me to).
Posted by Joe The IT Guy
on May 10, 2016 in Cloud
In Part 1
of this blog series, I covered what cloud native applications and microservices are – and left you dangling as to what containers are. I also mentioned “bees” but that’s irrelevant. Here, in Part 2, I explain:
- Hybrid and composite clouds
- Software-defined everything
What Are Containers?
The history of containers is almost as long as the history of virtual machines, although people seem to think containers are new. Nope - containers have been around for decades and, in a cloud context, they’ve been used by Google for nearly ten years already. The reason everyone is talking about them now is because they’ve been made easier to use by a company called Docker
. That reminds me, I need a new pair of chinos.
Containers can be thought of as light-weight, operating system-dependent virtual machines. They don’t have the isolation qualities of real virtual machines but they don’t have all the heaviness of virtual machines either, such as the longish boot times and the self-contained operating system.
Containers have mostly been available on Linux and they use operating system features to isolate resources for an application. So an application running inside a container thinks the world is as big as the container and has no idea that it’s “riding on the back of one of four elephants (physical servers), which are on the back of a large turtle (data center) swimming through space.” It’s all sounds very Yellow Submarine
Containers are loved by developers, since Docker solutions went mainstream, because they are easy to configure and lightning fast to use. When you’re a developer having to use multiple systems (test, staging, and production) and running multiple tests each day, then containers compare to virtual machines like a Ferrari Formula 1 car compares to a family estate – yes I’m showing my Italian roots here. Containers aren’t without their downsides though. Microservices aren’t easy to do and they are not always the right answer. In fact, Martin Fowler
recommends starting with a monolithic approach and refactoring an application if it emerges that a microservices approach might be better.
Also, at a technical level, it’s important to note that containers aren’t virtual machines. This means they don’t have the isolation features of virtual machines and so they are less secure. A virtual machine is like a house on a shared estate; a container is like a rented room in a shared house on a shared estate. Containers are stateless, which means that they are built brand new each time. When you turn them on, their configuration decides how the container is built, which includes connecting to services (which might be stateful). There are no persistent disks and the networking is “interesting” in that you can have hundreds or thousands of ephemeral containers popping up and down on your network.
What Are Hybrid and Composite Clouds?
In 2011 NIST defined the cloud using three perspectives:
- The service model (IaaS, PaaS, SaaS, and there are now more)
- The deployment model (public, private, hybrid, and there are now more)
- The five essential characteristics of cloud
The deployment model has generated much industry debate, with the general acceptance now being that this is actually a spectrum of possible models, ranging from “I only do on-premise private cloud” on one-side, all the way across to “I’m all-in on public cloud” on the other. Many people are, in reality, somewhere along the spectrum and still moving – using a combination of the two but generally moving in one direction or the other.
Hybrid, or composite, cloud has been a dominant theme by purveyors of private clouds (think both traditional non-cloud hardware and software vendors). Although recently, some public clouds (think new cloud service providers such as AWS and Microsoft Azure) have embraced the notion of hybrid cloud, but mostly from the perspective of them reaching into your data center to pull your applications and data into their public cloud.
Be warned though, hybrid cloud is the most difficult thing. Ever. It looks great on PowerPoint slides, Visio diagrams, and whiteboards but the reality is much blurrier, and implementation is very varied. Hybrid cloud can be expensive, complex, and difficult. And Gartner recently reported that 95% of private clouds are failing, with 31% blaming the failure to change in the operational model.
If you read vendor marketing you could be forgiven for thinking that you could buy a hybrid cloud with your credit card. You can’t – it’s a “solution” not a product, and it’s a complex solution at that. There’s no universally-agreed idea in the industry of what a hybrid cloud is, and if you look at the online cloud architectures from all the top vendors, you’ll find none of them agree on what a hybrid cloud architecture is. This is because they’ve molded the hybrid cloud solution to fit their product portfolio, rather than the other way around.
Finally, there are definitely situations that make sense to connect on-premise to public clouds if you want to leverage things like cloud storage for backup and archive. You can even connect the other way, from public cloud to on-premise to point cloud-based big data analytics at your on-premise datasets. And to do this, you really don’t have to have complicated hybrid cloud management software.
What Is Software-Defined Everything?
When Marc Andreessen said “Software is eating the world” he was talking about companies like Uber, Airbnb, and others that are using software with cloud, mobile, social, and analytics to disrupt traditional business models. This concept has been picked up by the traditional IT vendors who have moved from calling their products “cloud-ready” to now prefixing their existing products with “software-defined.”
You’ll see this in most IT sectors and in most cases, software-defined means the management or “control plane” has been decoupled from the “data plane” (think storage disk or network port). For example:
- Software-defined storage: Data is still stored on physical media such as flash, disk, and tape, so software-defined refers to the control plane, which was software-defined before but now it might have an API or, more likely, be more distributed or more converged depending on your perspective.
- Software-defined network: The network is still made up of ports and cables. But whereas previously the software was proprietary and ran on an application specific integrated chip (ASIC), the control plane now runs somewhere else, could be open source, probably runs on cheap servers instead of expensive routers, and uses an API.
- Software-defined datacenter: There are now software data centers inside physical datacenters. Think of a virtual datacenter that creates software virtual machines, networks, and storage (on top of real stuff, of course), probably via an API.
The real meaning of software-defined is when it applies to businesses and their processes and operations. And this is what Marc originally meant. It means that a business process, from order to cash, is written in software and uses APIs and cloud services. These companies that software-define their businesses are the ones that are really disrupting and winning markets.
So there you have it, five examples of cloud terminology hopefully demystified by yours truly. Is there anything else I should cover?
Posted by Joe The IT Guy
on May 3, 2016 in Cloud
The cloud is now ten years old, if you view Amazon Web Services (AWS) as kicking off the cloud industry with its inaugural EC2, S3, and SQS services
back in 2006. It’s an industry, and IT offering, which has been through the proverbial hype-cycle to become a mainstream IT solution that’s now used and accepted by enterprises of all sizes, and in all industries, around the world.
However, the general public’s understanding of cloud doesn’t tally with the maturity of the cloud. A recent US survey
revealed that half of Americans think that cloud computing is affected by the weather (and this was before Google data centers were hit by lightning
). In Australia, a quarter of active cloud users didn’t know they were using the cloud
. This is okay though as one of the benefits of cloud is hiding the complexity of the IT.
It’s not just the general public that struggles with cloud. New cloud providers and new cloud services have turned the cloud terminology dial up to eleven
(did you like my Spinal Tap reference?) to make the cloud look like an even more complex place – even for hardened IT professionals like me (Editor: who are you kidding, Joe?). To help, or at least to confirm people’s understanding, this two-part blog demystifies some of the latest cloud terms:
- Cloud native applications
- Hybrid and composite clouds
- Software-defined everything
What Are Cloud Native Applications?
Applications are a combination of programming languages, software architectures, supporting services, and let’s not forget the actual code and data. And there’s a best-practice approach to creating applications in the cloud, which is called “cloud native.” This best practice has reached a level of adoption and standing that it now has its own foundation called the Cloud Native Foundation
It brings to mind an old saying:
“If it looks like a duck, swims like a duck, and quacks like a duck, then it’s probably is a duck.”
So just as a duck has its nature, this best-practice thinking states that a cloud native application’s nature:
- Has a microservices architecture.
- Is made of containers.
- Runs on a cloud platform.
- Is reliable software on unreliable infrastructure.
- Is scalable on-demand.
- Is measurable.
The polar opposite of cloud native applications are 1980’s, monolithic mainframe applications or your 1990’s client-server applications. These could be migrated to the cloud as-is, but the chances of them working are unknown, whereas the missed opportunity of being able to exploit cloud features is known.
What Are Microservices?
Microservices is the name given to a specific software architecture style that is well-explained, and in detail, by Martin Fowler and James Lewis
. They describe microservices as an alternative to monolithic software architecture that is favored by cloud application developers because microservices work well with “the grain” of the cloud.
If monolithic software architecture applications can be imagined as one large, possibly enormous, program, then microservice-architecture software can be imagined as a swarm of single-purpose software components that work together. If this doesn’t help, and all you can now think of is bees, then Wikipedia
describes microservices as:
“…a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.”
Microservices are particularly suited to cloud native applications, and to cloud in general, because of the following:
- A swarm of components can make reliable software on top of unreliable cloud infrastructure.
- Single purpose components can be upgraded and replaced to enable practices such as continuous delivery, which has been proven to improve application quality and value.
- Components can be scaled in response to demand, independent of each other.
- Cloud platforms such as CloudFoundry are designed to make microservices easy by taking on the heavy-lifting of deploying and managing components and services.
- Components can emit metering data to provide rich, system-wide analytics.
Microservices are increasingly being implemented not by virtual machines but instead by containers, which I’ll come back to in Part 2
Well that’s it for Part 1, otherwise this blog would be 1800+ words long. In Part 2, I’ll return to cover: containers, hybrid and composite clouds, and software-defined everything.
Posted by Stuart Rance
on April 27, 2016 in ITIL
We all like to believe we are doing a good job. We all take pride in our achievements. But sometimes those of us who work in IT focus on the wrong things, particularly when the successful completion of technical tasks can be so satisfying that it takes on a life of its own. Clearly, we must be technically proficient. But it may be less obvious that technical proficiency is simply NOT enough. Unless we focus on creating value for our customers, whatever we do simply won’t be good enough.
Why Does It Matter?
One organization that I worked with had an IT configuration manager who was a real expert in his field. He deployed data collection tools to gather all the information that might be needed, and he carried out regular audits to make absolutely sure that the configuration data was complete and accurate. He was very proud of the quality and quantity of information that he maintained. When I asked him who used this information, and what they used it for, he confessed that he really didn’t know. He had never thought to identify who his customers were, or what information they actually needed to do their jobs. I talked to some of the other IT people in the organization and discovered that nobody used this configuration data at all, for anything. The time consuming and painstaking configuration management work had absolutely no value, to anyone!
In an oddly similar manner, relying on superficially straightforward and cost effective measures may prove misguided. One company had an air-conditioning unit that failed during the night. The computer room overheated, but because there was insufficient monitoring nobody noticed. Eventually the servers and storage got so hot that they failed, causing a lot of expensive damage. After all the equipment had been repaired the organization decided to prevent a repeat occurrence. They decided that the monitoring needed was too expensive, particularly as they could simply instruct the building’s overnight security guard to check the air-conditioning unit every hour throughout the night and sign in a book to show that this had been done. During a visit, I noticed that the unit had a red light displayed and I asked what this signified. The facilities manager explained that a resilient component had failed, that the replacement was on order, and the component would be replaced in a few days. That night I asked the security guard what he had done about the red light. “Nothing” was his reply. “Why not?” I asked him, and he replied “Nobody told me to check the lights.” The guard had diligently checked that the air-conditioning unit was still in the computer room once an hour, an activity that delivered no value.
How Can You Improve?
I’m sure we all think that these stories are extreme. This couldn’t possibly happen to us. But they do illustrate a really important point. We must make sure that the work we do contributes to a value chain. When we think about what we do, we should all ask ourselves “Who is my customer?”
and “What value am I creating for them?” If you can’t answer both of these questions then maybe it’s time to go and find out.
Even if you do know who your customer is, and what value they are getting from your work, there is a further step you can take. Find out how the things you do contribute value to the overall organization, and to the people who pay them. If you work in private industry then you should probably be creating financial value for your customers; if you work in the public sector, then the value you create may be a contribution to some social good.
I once had a very wise manager who said to me, “I want you to stop what you’re doing, at least once every day, and ask yourself ‘If the paying customers knew that their money was funding me to do this, what would they think?’ If you are not 100% confident that they would be happy, then stop doing that, and find something more useful to do.” Following this advice enabled me to focus my efforts on the things that create value for my customers, and was probably the biggest factor in helping me to become a service management expert. Moving from a technical focus to a value focus is difficult, but the payback can be enormous in terms of customer satisfaction, as well as your own career progression. I have been following this advice for more than 30 years now, and I heartily commend it to you as a way of ensuring you focus on creating real value for the people who fund your organization.
Posted by Roy Eldar
on April 19, 2016 in Service Desk
If you ask what a service desk is you might get any of these responses:
- IT operations or IT service management (ITSM) team: “The team we give the responsibility of dealing with IT issues.” And the more cynical among them might add “… but little in terms of knowledge or tools.”
- Business users: “The people who can help us with our IT issues … some of the time.”
- Development: “A worthless and unskilled part of IT.”
Okay the last one might be over-the-top cynical but the service desk can struggle to be valued outside of IT operations.
The Role of the Service Desk in DevOps
Thankfully, DevOps can help to change and improve this perspective by using the service desk as the pivot point between Dev, Ops, the business, and suppliers. DevOps is the cultural effort of getting Ops to see into the world of development and project teams, while also providing a mechanism for Dev and the project management office (PMO) to better understand the impact of change on production environments and, more importantly, on the customers.
So the service desk can be the lynchpin for how communication, collaboration, and the enhanced use of automation can enable technology to better support business processes and operations.
Think about what the business wants from IT:
- Better features or products, on a more timely basis
- Deployed in a secure, reliable, and cost effective manner
- Supported 24x7
So it is a lot more than just the delivery of new or improved technology.
Positioning the Service Desk in DevOps – the “First Way”
Referring to the book “The Phoenix Project,” by Gene Kim et al, the authors talk of DevOps enablement through three principles or ways
The First Way
ensures the flow
of technology (people, suppliers, processes, software, and infrastructure) to the business. In my opinion, many DevOps efforts fail because the concentration is on a flow from “idea” to “provided,” but successful DevOps needs to include a longer flow that includes support and review, in order to enhance future use.
The last thing corporate IT organizations want is a dissatisfied stakeholder or customer who looks elsewhere for technology services. But if companies do not consider the entire value stream, then a suitable analogy would be “The operation was a success, but it is a shame that the patient died.” So the service desk can help IT and the business to be prepared for whatever rate of change is going to occur.
The service desk knows what works and what doesn’t, the sort of issues most end users have, and how best to satisfy a customer. Their input early in the design phase can reduce or remove constraints related to non-development issues, such as having the right equipment available to use the new software, addressing licensing, or helping to train users. The flow is now from “idea” to “valued use” of a new feature, product, or service that retains and attracts customers.
Positioning the Service Desk in DevOps – the “Second Way”
The Phoenix Project’s Second Way
and this is where the service desk can excel – as most of the work performed by the service desk results in feedback:
- Gathering information on technology performance and use
- Knowing how customers or end users react to changes
- Contributing to 2nd or 3rd level support requirements
- Capturing customer or end-user requirements or wishes
- Understanding how technology is used on a daily basis
- Acting as the “single point of contact” for training or the creation and maintenance of knowledge artifacts, which can lead to better self-service
- Collating customer complaints
- Using the service desks’ tools and experience to record and track issues across the development to deployment lifecycle
- Facilitating escalations internally or to suppliers
All of this and more can help IT react to issues and, more importantly, to proactively assess whether a new feature or product is worth the effort and cost.
Positioning the Service Desk in DevOps – the “Third Way”
The Third Way
is continuous improvement
, which means that we learn from our efforts and try something new. This step is not a report with actions that no one ever addresses, but is performed daily by all members of IT. Imagine if from the beginning of the “idea” to “go-live” lifecycle, the service desk:
- Captured all issues
- Began to learn how to resolve them
- Ensured that integration, end user, or production-ready tests confirmed that the issue was resolved, or at least that self-healing scripts worked
- Noted when issues came back and escalated correctly
- Assisted with the automation of processes
- Trained users
Letting the service desk learn, create, and improve their capabilities will let the people, who are first to serve, be fully able to perform that function and, where necessary, gather feedback for improvement of the product.
Ultimately, the service desk is not just the “face of IT” – it is also its eyes, ears, and mouth. Everyone in the organization, even IT, uses it to help solve issues or request equipment or software. The service desk therefore knows the “truth” about IT – the good and the bad, from features and products to customers and suppliers – and can add value by sharing this information early in the design lifecycle.
So DevOps and the service desk should be a perfect fit. How is your organization’s DevOps activities involving and exploiting service desk capabilities?
Posted by Sarah Lahav
on April 12, 2016 in Service Desk
Today’s tech-savvy customers are taking their consumer-world IT issues into their own hands, with customers now looking online for answers in preference to calling or emailing the supplier to help them to fix the issue. Welcome to the era of the self-service-empowered customer!
And self-service adoption continues to grow. Forrester Research
has stated that self-service usage has increased from 67% in 2012 to 76% in 2014; and, according to a 2011 Gartner prediction
, by 2020 the customer will manage 85% of the relationship with an enterprise without interacting with a human. It was a bold prediction and we might not fully make it but we probably won’t be too far off as consumer-world self-service continues to gain traction.
But how is employee self-service being encouraged within organizations, especially IT self-service?
Supporting Employee Self-Service
With the rise of the empowered self-service customer outside the organization, logic and common sense says that these customers will expect similar self-service capabilities when they are at work, i.e. as employees or end users.
So how can you build a self-service ecosystem that keeps your end users satisfied?
1. Construct a Knowledge Hub
Get, and keep, your end users using self-service by building a “hub” or knowledge base to house your knowledge – with knowledge articles that allow end users to answer their own IT-related questions.
End users are keener than ever to solve their own issues rather than relying on customer service in their personal lives, so IT organizations can leverage this consumer-world success to give end users “what they want” while potentially saving support costs, increasing support efficiency, and hopefully offering a better customer experience.
This knowledge base will be the Google for end-user IT support issues – deflecting tickets away from the service desk and alleviating support agents from simple, yet time-consuming, tasks such as password reset, such that they can concentrate on higher priority IT issues and requests.
However, it’s crucial that the knowledge base is optimized for a great customer experience. Ensure your knowledge base is user-friendly, accessible, and intuitive to your end users. It should be accessible from most devices, especially mobile. Keep in mind that in the modern workplace end users will move rooms and even locations during the working day and week, and change their preferred contact channel depending on where they are and what they’re doing.
You can find out more about how to get knowledge management right in your organization via this webinar and white paper
by Aprill Allen
2. Keep It Simple
Locating and digesting support information should be easy for end users.
Have you ever tried to shop in a new supermarket where you really need a map to navigate through it? Nothing is where you think it should be. It’s annoying to say the least, when all you want to do is to find and then buy some milk.
Your knowledge content should be simple to navigate. Try mapping out a basic end-user (customer) journey to help you with this process. After initially accessing your knowledge base, the end user will search for their issue, view the resources, read the article or articles, and then resolve their issue.
At any one of these “touch points” you could lose the end user, who will at best call the service desk or at worst will just carry on trying to work around their IT issue . The article they need must never be more than a few clicks away. Ensure that you don’t over complicate the journey as, according to the Harvard Business Review
, after 2-3 consumer-world self-service attempt failures, customers will not try again. There’s no reason why this should be any different for employee self-service, so get a team member to test it out. If they can’t find what they’re searching for quickly, your end users certainty won’t.
As for the knowledge articles, they should be easy to read. Sweep out the “clutter” to ensure that the content is clear and precise, guiding the end user through their issue, step-by-step. Also avoid jargon and overly technical terms – you might understand what the articles mean but end users might not.
3. Continually Refurbish and Renovate
A knowledge base requires ongoing maintenance and development to continue to attract and retain end-user patronage.
It’s important to collect end-user feedback to understand how you can continue to improve your self-service support and to better meet their needs. And the collection isn’t enough – make sure that you act on the feedback.
Allow end users to rate and review the knowledge articles you provide. A simple rating button should be capable of flagging up content that might need simplifying or reworking. The kind of question you should be asking is: “Was this answer / article / information helpful?”
Also, ensure that a review process is in place to check that all content is still current and relevant. Document all the resources held in your knowledge base and periodically evaluate the content to see if any solutions or FAQ answers needs updating. End users won’t appreciate wasting time on outdated information – it’s a surefire way to lose their trust in, and patronage of, the self-service platform.
Don’t be scared of self-service. Remember that end users are familiar with “help yourself” systems in their personal lives. After all, self-service has infiltrated every part of our daily lives, from cash machines to supermarket checkouts, from online appointment booking to airport self-check-in kiosks, and pay-at-the-pump gas stations. The important thing is to get it right by making it easier than using other IT support access and communication channels.
You can find out more about how to succeed with self-service via this webinar and whitepaper
by Stuart Rance
and Stephen Mann
Posted by Dena Wieder-Freiden
on April 5, 2016 in ITSM
is done and dusted, and it’s already time for the second of the year’s IT service management (ITSM) industry’s “grand slam” events – HDI
. Alas, I’ll be missing out on this one too, but it doesn’t stop me from dreaming about who I’d like to hear speak if I were there.
My far-more-famous colleague Joe the IT Guy
will be at HDI 2016, and no doubt he will be using my session suggestions for his post-HDI blog – some guys definitely have all the luck
HDI is a Special ITSM Event
I really like the HDI event, as in line with its previous name – the Help Desk Institute – there’s often a lot of practical content that service desk staff, in particular, can use as soon as they are back in the office.
There’s also a heavy emphasis on customer service
, not just IT support. Thus, some of the HDI content can be ahead of the curve when it comes to the changing dynamics of corporate IT support and the growing expectations of end users (although HDI would deliberately call them customers!)
You’ll see what I mean from my suggestions below, it’s pretty much about all hands-on stuff…
So What Do I Recommend?
Maybe this should be more like “So who do I recommend?” as I’m a firm believer that while it’s good to attend the sessions of people that you know nothing about – in that you might learn something new – it’s also good to have “dependable” sessions where you know the presenter will deliver.
So when you sit down to create your HDI agenda, I strongly recommend that you consider the following sessions and presenters…
Session 107: If Metrics Are the Answer, What Are the Questions? With Roy Atkinson, HDI
Wednesday, April 13, Time:
: Metrics & Measurements
It’s Roy Atkinson, THE Roy Atkinson, need I say more? Well, I suppose I’d better, just in case you have no idea who Roy is.
Metrics are a constant source of heartache and frustration for many IT professionals, service desks, and IT organizations as a whole. In my opinion, there often seems to be a disconnect between the adoption of so-called best practice metrics and the business goals that they should ideally be distilled from.
So spend an hour with Roy to understand how service desk metrics need to be modernized, to be transformed into measurements that are more reflective of business goals and objectives.
If you can’t make this session, or even if you can, look out for two other Roy sessions:
- Session 402: Customer Service Excellence: Consistency Is the New Black
- Session 705: Desktop Support: Increased Demand, Changing Role
And if you are lucky, Roy will do a little singing too!
Session 206: Cultivating a Culture of Quality with Rae Ann Bruno, Business Solutions Training Inc.
Wednesday, April 13, Time:
: Support Center Optimization
As with Roy, in my opinion Rae Ann should be one of the first people on your HDI dance card. I’m led to believe that Rae Ann is always a high scorer in the HDI session feedback stakes and I can believe it – after all, I had the pleasure of seeing it for myself when I attended a few of her sessions at FUSION15
Rae Ann often talks to the people-side of IT support and customer service. Here, she will address one of the most common service desk people issues – that too often, quality monitoring and coaching is put on the back burner due to a lack of time, employee resistance, or other reasons.
Rae Ann will explain how it takes a balance of quantitative and qualitative metrics, and a quality program that continually evolves, to deliver: improved service, engaged employees, and happier customers.
You can also catch Rae Ann for her second session – Session 405: Creating a Proactive Desktop Model: Breaking Out of the Reactive Grind.
Session 404: Is the Traditional IT Department on Its Way Out? With David Cannon, Forrester
Thursday, April 14, Time:
: Service Management Excellence
What is there left to say about David Cannon? He’s a veteran of the ITSM industry (having worked at both HP and BMC, but Sophie Danby
tells me not to hold that against him, is a revered ITIL author, and is now in a strategic role at industry analyst firm Forrester.
David will look at how the changing IT and business landscapes are transforming corporate IT organizations, answering questions such as:
- If the traditional IT department is on its way out, what could possibly replace it?
- If the traditional IT department does disappear, how can we prepare for what’s next?
No doubt, David will be predicting what could happen in the next ten years and identifying what IT professionals can do to help prepare for these eventualities. And as David now works for Forrester, I imagine he will come armed with a lot of insightful research and statistics.
Session 603: Effective Tomorrow, the Service Desk Will No Longer Take Calls with Doug Tedder, Tedder Consulting LLC
Thursday, April 14, Time:
: Executive View
Doug is a SysAid favorite, in fact he is many people’s favorite, so how could I not pick the font of all ITSM knowledge that is the amazing Mr. Tedder.
In his session, Doug will take a deep dive into understanding the true value of a good service desk, and explain some of the positive outcomes that could happen if your organization decides that the service desk will no longer accept calls. This might not be as far-fetched as you think. Doug will talk to the potential resulting opportunities, the value of the service desk beyond being the single point of contact, and what should be done now to enable this future service desk.
Session 802: Two Key Differences When Managing the IT Customer Experience with Ian Clayton, Service Management 101
Friday, April 15, Time:
: The Customer Experience
Another SysAid favorite, and the grand master of all things customer experience and “outside-in.” In fact, I can’t think of anyone else that I’d rather listen to talk about customer experience in the context of IT service delivery and support.
The easiest way to sell Ian’s session is to steal his HDI blurb – it sells itself:
“A service business is only as strong as the relationship it forges with its customers. At the heart of any service relationship is customer satisfaction, which, if achieved, can lead to loyalty and advocacy. As IT is being required to change its operating model and internal culture to better suit the needs of a contemporary enterprise, lessons can be learned from the secrets of the retail customer support model.”
And here’s a cheeky plug for Ian’s latest blog on continual service improvement (CSI)
Finally, Joe the IT Guy and more of my SysAid colleagues will be in the Expo Hall, so please stop by to say hello and grab some quality swag. Feel free to pre-schedule a meeting
at your convenience. They definitely won’t try to sell you anything unless you want them to – they just love to talk ITSM.
If you would like to follow HDI 2016, in real-time on Twitter, then the hashtag is #HDIConf, not #HDI16 or #HDI2016. I know I’ll be following it.
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.