Print Page | Report Abuse | Sign In | Join
The ITSM View
Blog Home All Blogs
This blog, written by itSMF UK leaders and guest contributors, offers service management thought leadership and discussion of industry trends. Please feel free to comment on these posts (you will need to be logged into the website as a member). We look forward to hearing from you.

 

Search all posts for:   

 

Top tags: ITSM  ITSM16  PSMF  Q&A  Service Catalogue  SIAM  business change  Career  DevOps  Podcast  problem management  Release Management  Service Transition  SITS16  Are we the wrong people in IT  Automation  BCS  CGI  Digital Transformation  Event  EXIN  IOE  IOT  ISACA  IT4IT  ITIL  ITSM15  Managing Complexity  Metrics  Organisational change 

Have You Even Realised That You May Already Be “Doing DevOps”?

Posted By Barclay Rae, 28 June 2017

I was talking with a developer at an event the other day, who was cursing the “cult of DevOps”. Quite rightly pointing out that many of the practices that are touted as “new” and “cool” were in fact things he was doing 15 years ago.

Or at least trying to do.

I agreed with him that much of what is spoken about is not new. And together we also agreed that there was in fact a perfect storm of “new” or improved technologies and practices that had come together, providing “new” opportunities, and of course new and increased business demands. That expectations have changed as much, or indeed more, than the technology itself. Certainly, automation seems to be following as much as leading the new way of working – for enterprise organisations at least.

So we were basically in tune on the technology and opportunity side of things in the IT world. Where it all fell down was when I broached the tricky subject of how services still needed to be run and supported. Clearly his experience in this area was not positive and the whole concept of “RUN” was a nightmare perpetrated by jobsworth “run-book morons” who could only follow instructions (badly), without insight, knowledge, or any level of “common sense” creativity.

I noted that we did have some of these people in Operations, but that I’ve spent the last 25 years or so trying to avoid and remove this problem, often with some success, only to be foiled by some intransigence and lack of co-operation from technical and development teams.

Ah. That didn’t go down well at all…

Anyway, by steering the conversation a little we managed to concur in the end by blaming it all on poor management, lack of leadership, and negligible governance. Which of course ultimately is a fair point – we need leadership and positive guidance on bringing teams and people together, if we’re ever going to get away from the operations/development divide.

 Which brings us to DevOps

I dislike the term “DevOps” – it’s internally focussed and doesn’t really mean much to business people. “BizDevOps” has a better focus and is more correct as an approach, however, again it’s clunky and a bit introspective. Some of the focus in the current “movement” can get a bit bogged down by trying to pull everything together when it’s not actually needed.

What’s wrong with Dev and Ops being different things?

Development (R+D) and Operations are actually perfectly reasonable and well understood terms in wider (non-IT) business. We shouldn’t worry too much about trying to completely merge them. Train engineers and drivers do different things – part of the same industry. We don’t need to invent ‘Drive-eneers’..!?  

 We all do Dev and Ops to some extent

And of course the value and objective of the DevOps “approach” is to foster collaboration and more close working; to avoid unnecessary waste and delay that is purely caused by people and process; and to improve productivity and speed through a focus on common aims and metrics, with the explicit goal of achieving business success and outcomes.

The fact is that we can do these things collaboratively but we can also do them in our own teams – in fact many of us in service management have been doing a lot of this stuff for years. We just need to call it out more and recognise that we may already be “doing DevOps”. I.e. if we’re trying to be more efficient, removing unnecessary time delays or blockages that can be by-passed to improve customer experience, or dealing with issues (problems) strategically and quickly, and eliminating backlog or technical debt.

The real challenge in making DevOps work is of course how to move from a culture of process and control, to a more flexible and open way of working. This doesn’t happen easily or quickly and we shouldn’t beat ourselves up expecting to completely change overnight.

How about we start doing "Incremental DevOps", where we look at flow, use visualisation, use business metrics, become more open, use automation where we can, improve our approach to testing, and tackle out backlog – all of these are "DevOps" activities that we can do now without a major programme.

 

This post has not been tagged.

Share |
PermalinkComments (0)
 

Don’t Entertain a Mistaken Perspective

Posted By Ivor Macfarlane, 31 May 2017

Fake News is in the news these days. Of course, there is a degree of circular argument in whether you can believe what they tell you about fake news, but let’s just understand that what people take from media affects their attitudes and expectations.

It’s not just news though. What we see on TV and in movies affects our expectations in real life too. That applies to our understanding of service management as it does to everything else. So … what do the movies do that damages our ability to get service management right? Well, that’s the topic of my talk at the itSMF UK regional meeting at the University of Glasgow on 6th June and the Service Desk and IT Support show (SITS17) on 8th June.

Excitement is usually not good news

For most of us, despite knowing that what we watch is a dramatized and an exaggerated version of reality: entertainment not documentary, nonetheless we let it into our heads.

What that means for many of us is a failure to appreciate that in “real life” IT service management (ITSM) we should be seeking boredom rather than excitement and adventure. It’s all too easy to get distracted by the hero culture. In the movies our heroes rescue us from crashing trains or alien invasion. In our ITSM workspace the heroes repair networks or rebuild broken servers, rewrite code, or recover our lost files. If we could only get the service design and support right then we shouldn’t need the heroics to fix things, because they wouldn’t break in the first place.

Boredom isn’t the only cherish-able virtue we get distracted from though. At both events I’ll also wander through the realms of the:

  • Relative rarity of geniuses
  • The truth behind Stonehenge
  • Differences between inventing products and delivering services
  • Financial benefits of teleportation

There might also be some tangential discussion of James Bond, his bosses both real and imagined, and what they might choose to talk to the media about. All delivered with some degree of an ITSM context. Then rounded off with some opinions on how you might persuade your managers and customers to plump for boredom over excitement and get some credit for that boredom.

What we should be seeing

But, of course, you already know about TV and the movies, and you know a thing or two about service management too. The real point of this talk is to let all that knowledge drive us towards delivering the right kind of service support and improvement.

Specifically we hope you might be taking away some ideas to help you:

  • Take credit for things that are effective rather than innovative. That might mean doing something less interesting to you, but more use to your organisation.
  • Understand what good looks like to customers before trying to deliver it. Sprinting off in the wrong direction might look impressive but it won’t take you where you need to be.
  • Why practice is possible – and valuable – in service management. We all learn from mistakes and get better with practice, but there are ways to do that without risking damage to your business.

Hopefully it will be entertaining to listen to. In Scotland, I’m also looking forward to running a practical session with delegates off the back of my presentation.

Then, at SITS my session is on the second afternoon so I’ll be competing not only with star speakers in other streams but the inevitable event fatigue and a possible rush to get home, vote and wallow in joy/despair at the election results, depending on your political leanings, and whether the electorate choose to opt for frying pan or fire.

For myself, I fully intend to enjoy the whole of the SITS experience and what it has to offer: that rare combination of a snapshot of where the industry stands these days, two days of meeting friends and sharing good company, all along with a mix of interesting talks and good ideas.

See you there?

This post has not been tagged.

Share |
PermalinkComments (0)
 

What an MBA can teach you about improving ITSM practice

Posted By David Backham, 24 May 2017

Studying for an MBA is particularly hard if you try to do it alongside a full-time job. Mine took six years to complete (I took a two year break in the middle), and two attempts to complete the final year module successfully. (If at first you don’t succeed…) However, I believe it was all worth it, both for the personal sense of achievement, and also for all the management learning gained during the programme.

ITSM best practice was historically based upon ITIL. More recently we’ve developed a wider portfolio of knowledge and practices that practitioners can use.

IT service management (ITSM) has a clue in its name – it’s fundamentally a ‘management’ practice, and the MBA study programme includes lots of relevant management theory that has been developed, challenged, tested, and validated. This is why I believe senior ITSM practitioners should consider studying for an MBA.

Improving Customer Satisfaction

In my presentation on “Improving Customer Satisfaction at the IT Service Desk”, which I will be delivering at the Service Desk and IT Support Show (SITS17) in June, I’ll be explaining how one management theory I learned during my MBA studies pointed the way to implementing best practice to improve customer satisfaction.

The theory, called The Service-Profit Chain was featured in Harvard Business Review in 1994, with an online reference here.

The diagram shows the chain linkage from left-to-right whereby improving Internal Service Quality leads to improvements in Customer Satisfaction further down the line.

Whilst at first glance this is a management “theory”, I thought it looked exactly like a suggested step-by-step approach to a Service Improvement Programme (SIP) that could be run on the operations of an IT service desk. I noted that the model had been specifically designed for use by service provider organisations.

Although the model identifies an end-goal of commercial benefit (revenue, profit), I noted that the intermediate goal of Customer Satisfaction was particularly valid for non-commercial internal service providers such as an IT service desk.

I directed my efforts solely on improving Internal Service Quality – the very first box in the model, and I decided to measure customer satisfaction as an indicator to detect any improvement made.

Note that for internal service quality the model identifies specific elements:

  1. Workplace design
  2. Job design
  3. Employee selection and development
  4. Employee rewards and recognition
  5. Tools for serving customers

My SIP addressed to some degree all of these elements during an eight month timescale. The programme work would include:

  • Re-architect of the operation of the IT service desk and IT support teams
  • Introducing a governance and management policy by using the ISO 20000 service management system
  • Adopting some key ITIL processes (incident, problem, change, service level management, knowledge management)
  • Providing all IT staff with ITIL Foundation training
  • Implementing a new ITSM toolset with the ability to configure custom workflows
  • Providing self-service for service requests
  • Re-defining roles and responsibilities
  • Creating management reporting against KPIs specific to each member of staff
  • Showing visibility of performance achievements using a scorecard on the wall

The primary quantitative KPI measurement we used was the “% achievement of incident resolution within SLA target times”, but in the customer satisfaction survey we also asked two key qualitative questions

  • “Did the resolution meet your needs from a time perspective?”
  • “Did the resolution meet your needs from a quality perspective?”

The feedback we gathered from these questions provided additional evidence to show where our standard resolutions needed further improvement, and this data drove a subsequent focus on Continual Service Improvement (CSI).

So, in my opinion, the MBA programme teaches an evidence-based management practice, and the evidence we gained from the customer satisfaction surveys validated the improvements we made.

Want to learn more about improving customer satisfaction?

I’ll be presenting at the Service Desk & IT Support Show (SITS17) which takes place on 7-8 June 2017 at London Olympia, featuring over 80 exhibitors and the largest free education program in the industry.

My seminar session on “A cure for the customer satisfaction problem? will take place on June 8th at 9.30am and will offer attendees the following key learnings:

  • Understand how to use the service-profit chain model for service improvement.
  • Using support processes and the knowledge database to fix incidents successfully.
  • Demonstrating the business value of ITSM by using the available evidence.

You can register for a free visitor pass here.

A Note from itSMF UK

Also, in collaboration with SITS17, itSMF UK is holding the Professional Service Management Awards (PSMA17) on the evening of June 7th offering a unique opportunity for you to:

  • Play your part in the formalization of service management as a recognized profession.
  • Collaborate with other forward-thinking service management professionals, to informally “sow the seeds” that will eventually take the industry forward.
  • Create new industry relationships that will help both you and the company you work for.

 To attend the awards, please register here.

This post has not been tagged.

Share |
PermalinkComments (0)
 

Utilising Storytelling and Objects in ITSM Leadership

Posted By Sophie Danby, 17 May 2017
Updated: 17 May 2017

This is a guest post, contributed by Joe McGee, Leadership Founder and Consultant at McGee Leadership.

 

In leadership, whether in IT service management (ITSM) scenarios or elsewhere, there’s sadly no operating manual for how one should lead teams effectively. And leadership training for new managers and leaders is often not part of the company budget. So how do you become an effective leader? 

In my experience, new leaders will often stumble, fall, and overcome adversity in their new roles. It’s the “discovery” phase that can be somewhat overwhelming for many people. Then, as new leaders, we often overlook simplicity and overthink things when performing every day work.

Leadership Lessons Inspired By a Six-Year Old

You might not initially relate fatherhood to leadership but, in 2009, I was blessed with the birth of my daughter Ursula which offered me a new and somewhat unique view on developing IT service desk teams.

This new way focuses on the use of storytelling and objects to help people to understand and embrace change or, more precisely, the delivery of change. It uses first-hand stories of my experiences raising children along with the Learn It, Teach It, and Apply It (LTA) principle to build confidence and “shape” subject matter experts (SMEs) in the workplace – in this instance a service desk team.

Please read on for more detail on what this involves.

Using Objects in the Workplace

I want you to go back in time for a moment in your mind. Think about elementary/primary school…

Do you remember “show and tell”? It’s a common exercise to show an audience something and then to tell them about it. In the United Kingdom, North America, New Zealand, and Australia, it’s a common classroom activity for young children – used to teach them the skills of confidence, public speaking, and the importance of sharing information that has value to them.

Jumping back to present day, you too can successfully bring objects into the workplace to enhance a given point that you’re delivering. For instance, an object I’ve used to illustrate a point and to build confidence is “Orgone Energy.”  It’s a pseudoscientific and spiritual concept described as an esoteric energy, or hypothetical universal life force, originally proposed in the 1930s by Wilhelm Reich.

Instilling Confidence with an Object

The average person will make 773,618 decisions over a lifetime – and will apparently come to regret 143,262 of them. And, in the technical support world we work in, we need to instill confidence when troubleshooting. I use this Orgone energy object to reinforce why it's important to sell yourselves as technicians, and that we need to wear both sales and technical hats when speaking with customers. 

During an informal gathering, I will pass the object around the room. I tell my team to feel the object and I explain its origin, and that when the item is close by it's supposed to give a life energy to provide good health and to possibly prevent cancer. Next I ask: “Knowing the history of this object and its energy, how many of you want to keep one and try it out?” Everyone usually drinks the Kool-Aid, but why?

It's because of the pitch and sounding confident, even when you really don't know too much about the product. After my last demonstration, I had members of my team approach me to ask if I had made it all up. But whether I had made it up or not, sounding authentic and believable is what we need to do at all times. 

 

Story Telling – The Origin of God's Vision

 

When making changes in your department it's important to utilize stories to show that change is acceptable and happening all around us. One of the examples I use for selling change in the department is the "Origin of God's Vision," noted below. 

 

 

Your perception of an idea is usually based on your observations, which could lead your mind into misdirection. For example, do you believe God to be sexist? Let me explain why I say this…

Think about it for a minute – did God deliberately make man superior to woman? Is this the perception we have engraved into our minds? Consider the following:

 

  • When we watch movies, lines such as “For all of mankind as you know it” are often said. Notice that I’ve underlined the word “man.”
  • For many years, highway construction workers put up signs that said: “Men Working.”
  • When our children want to build something out of snow, what do they call it? They surely don’t say snow person, they say “I want to build a snowman.” Again, the word “man” is embedded into our minds and how we have phrased things over many years.

Because since the dawn of time – let’s call it the origin of God’s vision – men and women have been seen as different. Men and women had their roles, and society has reinforced the differences (and often inequality). But thankfully, as time has moved on, our perceptions of what a person, rather than a sex, is capable of has most certainly changed. My point is that we need to question the perceptions we have and how they have influenced our thinking.

In terms of your workplace, understand what your team may believe in and how they arrives at their conclusions. And, just because it’s how it has been, it doesn’t mean that the perception or the end result cannot be changed. It can, point in case with the above example. 

Hear More at SITS17 

Want to find out more about the use of storytelling and objects at work? I’ll be presenting at the Service Desk & IT Support Show (SITS17) which takes place on 7-8 June 2017 at London Olympia, featuring more than 80 exhibitors and the largest free education program in the industry.

My session on Leadership Lessons Inspired by a Six-Year Old will take place on June 7th at 10:30am and will offer attendees the following key learnings:

  • How to bring lessons from home into work
  • How to discover the power of the “Learn It, Teach It, Apply It” principle
  • How to avoid tunnel vision to find the answers you really need

You can register for a free visitor pass here, with free tickets for all seminars available on the day on a first come, first served basis from the Seminar Registration Desk. But you can alternatively pre-book seminars for just £6 per session (including VAT) when pre-registering.

A Note from itSMF UK

Also, in collaboration with SITS17, itSMF UK is holding the Professional Service Management Awards (PSMA17) on the evening of June 7th offering a unique opportunity for you to:

  • Hear about the future of ITSM and the wider service management industry.
  • Play your part in the formalization of service management as a recognized profession.
  • Collaborate with other forward-thinking service management professionals, to informally “sow the seeds” that will eventually take the industry forward.
  • Create new industry relationships that will help both you and the company you work for.

 To attend the awards, please register here.

Tags:  SITS17 

Share |
PermalinkComments (0)
 

Getting Practical with DevOps

Posted By Daniel Breston, 10 May 2017

Recently I had the privilege of being asked to develop and subsequently deliver an itSMF UK workshop on “Practical DevOps” explaining:

  • What is DevOps?
  • How does DevOps blends Agile, Lean, Theory of Constraints (ToC), and IT service management (ITSM) into a common framework?
  • The value and principles of DevOps
  • Metrics that matters to DevOps
  • DevOps concepts like Continuous Integration and Continuous Delivery
  • Practical tips related to DevOps success

A Day of Post-it Notes

The workshop was designed from the very beginning to be interactive so no segment went without an exercise. For instance, as we went through the history of DevOps, I asked participants to write their own definition of DevOps on a post-it note. The answers were quite revealing in that most concentrated on the automation aspects of improvement, or just commented upon the need to align Dev teams with Ops/ITSM teams. And by the end of the day, their views had changed to be inclusive of stakeholders, vendors, and all aspects of technology service and delivery.

In fact we used post-it notes in several exercises and the group soon began to see how important visualisation was to DevOps. We used post-it notes to:

  • Create a manifesto of DevOps that was relevant to them (which they then compared to the Agile Manifesto and were amazed at the resemblance)
  • To map the flow of service provisioning from the time the idea gets requested until it’s delivered. We used a Lean concept called Value Stream Mapping and created an alignment charter, visualising the current way of working with time and quality measures, mapped the future, and highlighted some iterative experiments that could be performed in each two week sprint.

Flow of Work

All of the participants were looking at introducing Scrum into their organisations. This picture (from The DevOps Institute) highlighted the view of including not only new or feature related work into your product backlog, but creating a process, the removal of technical debt, and improvement ideas. 

So, Metrics: Do They Matter

So, back to the workshop, using Service Level Agreements (SLAs) as an example, we discussed metrics from an ITSM view and then again from the speed and quality view of DevOps. The group created metrics, using templates on how the automation of a process could help reduce MTTR (incident time) or make collaboration better across teams by automating trust to reduce the need for a Change Advisory Board (CAB).

We reviewed Key Performance Indicators (KPIs) and how to align metrics top down and out to suppliers via a Lean technique called Catch-ball.  Finally the group used their templates to create their own KPIs that they would introduce the following day at work. The template highlighted who owned the metric, the formula, the reason, frequency, what to do if the measure was breached, and the benefit of this measure.

This discussion highlighted again the principles of flow, feedback, and learning against the culture and knowledge sharing engendered by DevOps.

 

Tips and ITIL Principles?

Finally, we reviewed practical tips on how to get started such as:

  • Organisation: don’t immediately create a team but instead look at how to pilot DevOps practices in your existing organisation.
  • Processes: all processes at some point can be automated and DevOps enables the iterative use of tools to help create faster ways of doing things.
  • People roles and skills: cross-functional sharing, training on not only the new tools but also cultural change, and leadership coaching are all needed.
  • Tools: collaboration and knowledge management is as important as testing and release/delivery automation.

The final part of the day reiterated that ITSM is a valuable part of DevOps (as often mentioned in The DevOps Handbook). We did this using the “9 Principles of ITIL” as documented in ITIL Practitioner.

At the end of the day, participants went away with a better understanding of DevOps, how it works with ITSM, and how to measure its success. The key takeaway was to try something new and iteratively introduce the practices of DevOps into their own organisations.

So how much do you know about DevOps? Would it be of value to you to learn more? I hope to run this workshop via itSMF UK again in the near future, and it’s also available as an in-house event. For more information email itSMF via membership@itsmf.co.uk. Or come and speak to me at the itSMF UK stand at the Service Desk and IT Support Show next month.

Plus, it’s worth noting that itSMF UK are also running a “DevOps simulation event” on 5th July, which you can see more details on here.

In the mean time you might find some of the following resources useful:

Books:

Websites:

Tags:  DevOps  Workshops 

Share |
PermalinkComments (0)
 
Page 4 of 14
1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9  >   >>   >| 

Premier Gate
21 Easthampstead Road
Bracknell
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us