Print Page | Contact Us | 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 

Behaviour and Relationships in Professional Service Management

Posted By Mark Lillycrop, 13 September 2017

This is a guest post, contributed by Mark Smalley, IT Paradigmologist, ASL/BiSL Foundation


If you’ve been attending IT service management (ITSM) conferences for five, ten, or more years, you’ll have noticed a shift in focus. While in the ‘good old days’ it was mostly about process, now that we’ve got this important aspect more or less under control, we’re realising that people are often the weakest link in the people-process-product-partner chain. This explains an increase in interest in topics such as Business Relationship Management (BRM) and competence frameworks like the Professional Service Management Framework (PSMF). We understand the value of behaviour and relationships, and realise that it’s more a question of having the right skills and attitudes than well-defined processes.  

Effective Business-IT Relationships

I have responded to this shift by developing a workshop around desired behaviour in the context of effective business-IT relationships. The concept is simple. The participants are divided into two ‘factions’: business and IT. The business group is tasked with identifying the kind of behaviour that they’d like to see from their IT colleagues. And vice versa, the IT group identifies desired behaviour from their business partners. I’ve done this workshop in more than ten countries on three continents and the results are pretty consistent across countries and cultures. The business not only wants IT to be quicker, but also more reliable, business-savvy, and empathetic. IT wants the business to be clear about what they want and to set priorities and to understand and accept risks. These are the findings in a nutshell.
The next step in the workshop, once desired behaviour has been identified, is to think about what actually drives behaviour. While behaviour can be influenced to a degree by extrinsic carrots and sticks such as bonusses and appraisals, much boils down to less visible stuff below water level. To quote a workshop participant, “Observable human behaviour is just the tip of the iceberg. Below the surface is the complex yet fascinating world of emotions, attitudes, and values that influence how we work, cooperate and react.” These ‘soft’ topics are often tricky for people with a technical bent. They can’t be expressed in zeros and ones. Or boxes and arrows. They’re messy. 
In a workshop that I conduct together with Simone Jo Moore, who’s done a lot of work in this area, I’ve observed that it helps to do some simple exercises with values and emotions. For instance, choosing a core value from a set of cards with more than 50 values. This makes people aware of the values that are very close to what makes them them. Another exercise gives them a vocabulary with which they can better understand, recognise, and express emotions. We’ll also talk about persuasion, referencing Cialdini’s work in this area.

At the itSMF UK Conference (ITSM17)

This is the core of the workshop that I’ll be conducting on the first day of the itSMF UK conference this year. In 90 minutes we’ll establish desired business-IT behaviour and will explore the factors such as values and emotions that are key drivers of behaviour. In terms of itSMF UK’s Professional Service Management Framework, these relate to communication skills, empathy and getting on with different personalities, Influencing and persuading, collaboration, relationship handling / development, motivation and team building, coaching and performance management, and organisational change/development. Hopefully this workshop will help the participants influence behaviour in themselves and in others, leading to improved relationships and results.
Of course I’d love to see you in the workshop but if not, please consider the kind of behaviour that you’d like to see not only between business and IT but between any parties that need to collaborate better. Then have a think about the factors that drive behaviour, in particular values, beliefs, and emotions and how you could go about influencing these.  Karen Ferris has made a good contribution to this field – you’ll find her white paper Balanced Diversity worth a read.



This post has not been tagged.

Share |
PermalinkComments (0)

Why do we bother measuring?

Posted By Daniel Breston, 06 September 2017

Metrics! Bah! We’ve measured in IT for years all sorts of things like: quality, cost, safety, people, customers, availably, reliability, continuity, and so forth. Every major framework has suggested measures but they don’t seem to be able to help me get my teams to satisfy my customers or stakeholders. HELP!!!

This is the dilemma of most IT leaders. How do you know what is good, bad, or great in terms of what is occurring in your organisation? How do you set some measures to help your people and suppliers understand and know how they’re performing against agreed expectations?  Let me share a story with you, and it goes back four decades to when I first started in IT at a large Texas bank.


Taking Us Back to Texas

My CIO, ex-IBM, ran almost the entire IT division on one metric: MTBK (Mean Time Between Kicking). Not when he kicked us, but when he got kicked.

You see he walked the halls of the bank, went to branches, and visited suppliers weekly. Every time he heard: “Ah your IT is terrible” or “Your IT is not helping me” or “Why did you make that change?” then he marked it down. When he returned to his office he went to a board and logged the number of ‘kicks’ he’d received.

















Over a short period of time he noticed something. When we did IT changes, the number of kicks was higher. The other thing he noticed was that there was never a day with zero ‘kicks’.

The thing is, my CIO, he wanted zero ‘kicks’ for at least one day. So he challenged his team to come up with metrics in their area that would help the IT division have a day of zero “kicks’, aka no bad comments.  If we did this he promised a night out at a major restaurant.

He could have told us what the metrics he wanted us to hit were, but instead he coached us to find metrics that aligned across all the teams to help make quality and performance as great as possible. Development looked at how they found defects and improved testing by using a Right First Time metric. Development and PMO realised though that issues happen so they asked the Service Desk to help create a robust incident handling process to minimise downtime or impact of an incident. Infrastructure added performance metrics and used these to improve how applications or services worked such as load balancing, more memory when needed, tuning of databases, etc.

Think about what we were really doing though. Think about the problems we were finding and addressing not just in our silo but across the silos. In my role as Service Desk Manager I could fix nothing. I had to find a way to use my team to work with other areas of IT to develop faster incident response and resolution times and they had to find ways to stop incidents from occurring or at least help my team. Collaboration – not just here “read and do this” communication.

Three months later we had our first zero day. I remember my CIO walking into the computer room and shaking every persons hand. He then went to Dev, Tech Support, the Service Desk, and he called every supplier. The impact was amazing.

After that we never had to be told to aim for a week or a month or a year of zero ‘kicks’ – we did that ourselves. We never made a year, but there were times where we did achieve an entire month free of complaints.


So, what measures did we use?

We used:

·      Right first time

·      Escalation is bad

·      Monitor-Alert-Respond Fast

·      No rollback, no roll forward

·      Quality before being on time


Some of these you will recognise from suggested metrics in DevOps or ITSM. A few we made up just to make it fun like we had a measure to count the bouncing incident (number of times we escalated and it bounced back for more information). The challenge was to have no more than one bounce.

None of these were ITIL-based, but then this was before ITIL existed. We also were not afraid to prune our KPI tree. Yes, it you think about the main trunk: no bad comments, then all of the branches from all of the areas linked to the trunk to keep it healthy. If a metric no longer mattered or needed to be adjusted (pruned) we did so as a team and since we were all working on the same tree, we had to do this collaboratively.

Our metrics became linked to customer satisfaction. Any metric that could not be linked to customer satisfaction was removed. An example would be: we were only down for 80 minutes so we hit our SLA. We looked harder and saw that 80 minutes at end of month (payday for many people) was not really acceptable. The other metric we had was Mean Time Between Failures. Hey it has been 4 days since we had an issue!!! Who cares you have an issue and it took you hours to get it resolved was the response back from our customers. Out went MBTI to be replaced by Mean Time to Get It Back Up.

The better we became, the less it cost to manage our services. No staff loss. Staff instead were busier as we were able to offer more services that the bank wanted so training time went up. Quality up, performance up, customers satisfied up, employees satisfied up, costs down. Yes this was not easy and yes we still had our bad days. But: we had the trust of the bank that we would get it right.


So how do YOU help your teams to do better, faster, and safer IT?

Do you let them set their own goals and allow them the time, training and environment to achieve them? Do you celebrate success?

Key Performance Indicators (KPIs) are forward looking indicators. They should help teams make immediate decisions. They should act as a guide that what they are doing is good, bad, or great in terms of quality, cost, safety, performance, and satisfaction. Let your teams create these indicators that are KEY to them. Then just watch the magic happen!


Want to learn more?

This is the very topic that I will be discussing at the upcoming itSMF UK Conference 20th-21st November. Join me for what is set to be one of the best itSMF events in many years, and learn a thing or two about improving your metrics to help ensure you actually deliver business value. 

Tags:  ITSM  Metrics 

Share |
PermalinkComments (0)

Anyone for tennis?

Posted By Richard Horton, 12 July 2017
Why do we do processes? When Service Management theory is structured around using them it seems a bit of a basic question, but when they aren't applied appropriately we can find them shackling both our organisations and how we are perceived. As Johanna Konta finds herself in a Wimbledon semi-final I was struck by something she said in the euphoria of her quarter final win. "I've always believed in my own ability and I've always dreamt big. But I'm much more process orientated, so I don't give myself too much time to dream. I'm more focused on the work." [BBC Sport] Here we have a telling example of how processes are there to do something, but can only help to deliver that dream (or business objective if you prefer!) if they are followed through in a focused manner. It's not always obvious how our processes align to the business dream that they work towards. And maybe sometimes they don't. Konta's success illustrates what can be achieved. Maybe it's time for a reality check on whether we are putting our efforts into the right processes... and not forgetting to celebrate when processes lead to the fulfilment of dreams.

This post has not been tagged.

Share |
PermalinkComments (0)

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)
Page 2 of 13
1  |  2  |  3  |  4  |  5  |  6  |  7  >   >>   >| 

Premier Gate
21 Easthampstead Road
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us