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.
For many years in IT service management (ITSM), we’ve been extolling, nay evangelising, about the importance of the Service Design Package (SDP) when delivering and running IT Services in an organisation. With the increased adoption of agile techniques and minimum viable product (MVP) as a “thing”, many are asking whether Service Design Packages are still relevant (if they ever were), and if so how can we make best use of them to enhance service delivery rather than burdening delivery with unnecessary bureaucracy, or worse still the creation of “shelf-ware”.
The Service Design Package
Let us first look at the core elements of a SDP and the value they give in the traditional service delivery model. The SDP consist of four core pillars that underpin the delivery of services, as follows:
The Requirements pillar includes our business goal, service contacts, and service applicability – the why, for whom, and from where we deliver the service. The Service Design pillar is more than the name suggests and covers the functional management, operational, and service level requirements alongside an approved design topology to satisfy all of these requirements. This is the basis for agreement of what is to be delivered. The Readiness Assessment pillar makes sure that the business is prepared financially, technically, and organisationally to receive the service, and is resourced to make the most effective use of the service. In Rugby terms, they’re “eyes up, and hands out ready to receive the ball”. Finally, we have the pillar that represents the Service Lifecycle Plan. This covers, how a service is delivered, and how it will be used throughout its lifecycle.
Agile Service Delivery
Now, let’s think about Agile Service delivery using the principal of MVP. The end customer still has a vision that they want to realise, however rather than spending an inordinate amount of time gathering “finger-in-the-air” requirements and waiting for a single delivery of the final all singing and dancing product – as we did traditionally – the MVP model focusses on validated learning using the least amount of time and money to satisfy a specific customer requirement. Couple this with the fact that Agile is about iterative and incremental delivery, and we can start to see how services can be delivered in this way and how, by adopting this approach, we can ensure that we’re building the right thing by validating the design as each incremental part of the service is delivered, as well as minimising the impact to the customer of receiving the service.
Delivering services in this way can mean that the final service offering may differ quite considerably from that which was originally scoped, having been through numerous iterations and requirements reviews before the whole service is finally provisioned. So how are we expected to record this build journey so that the service offering is supportable? We do this simply by ensuring that all design features, changes in scope and/or functionality, and agreed delivery milestones and accepted elements of the service are fully documented in parallel with the incremental delivery of the service.
Delivery of services in the Agile age does not negate the need for a SDP, but in fact, due to the evolutionary nature of services being delivered in this way, the need for a comprehensive source of knowledge, detailing what was, what is, and what is to be for the service continues to grow. And, as demand for this information grows, the requirement to provide it in a useful and usable form will grow also. This demand is not going to diminish as we move further in to the digital age, and indeed new sub sets of data or information may be asked for in the support of service delivery, and the logical place for all of this remains the SDP. In conclusion, as ITSM develops and matures through new technologies, processes, and frameworks so does the relevance of the Service Design Package. The Service Design Package is just one of a range of tools available to Service Level Managers and its importance cannot be underplayed. Join us at our session to explore the challenges currently being faced in Service Level Management (SLM), and what tools and approaches we can use to address them in the digital age.
Join me at the itSMF UK Annual Conference
Interested in learning more? At the ITSM17 conference I’ll be exploring the rise of Digital and Enterprise Service Management and how Service Level Management needs to evolve to meet the changing needs of the Digital Age.
There is a growing trend of organisations changing their focus, from products to services, even in the most traditional of manufacturing companies. To be successful, they’ll need to start viewing the supply of a product as the result of a combination of processes and services, not as the creation of a specific item. This is especially true for digital products and services where often the final consumed “product” is nebulous. In my presentation, I’ll examine the traditional model and focus of SLM; and question whether it’s still relevant, and what new elements need to be considered to ensure that the function and the service as a whole deliver business value. I hope to see you there.
We used to believe that the only way for people to get money out of their bank account is to go visit the bank, fill out a form, stand in line, and submit the form to a cashier who would then verify it and give you the cash to be used for transactions.
Then, ATMs questioned the need for customers to visit the bank and provided cash machines that were easily accessible. Customers were given the ability to withdraw cash at their own convenience without having to visit the bank and fill out the form – saving them a lot of time. Customers now had easier access to their cash.
After this, payment cards questioned the need for customers to use cash to make transactions. They made it even easier for customers to make transactions by simply carrying around a card that’s linked to their bank account.
Now, services like Android Pay and Apple Pay are questioning the need for payment cards as well. We can pick up what we want, go over to the counter, tap our phones, and walk away just like that.
Should I even mention Amazon Go?
Look at how quickly the industry moved from a service where the customer had to go out of their way to a bank to fulfil their needs, to self service where the customer could help themselves to their need, and finally to what I like to call “selfless service” where the service is so ingrained into the customer’s daily life, that they feel that it’s simply a part of life.
This happened right before our eyes in the consumer world. So why can’t we apply this to the service management world?
I don’t have anything against self service but...
In IT service management (ITSM) we’ve been talking a lot about self service and we celebrate fairly decent self service portal adoptions. Now let’s pause and think about what this means for our end users. By navigating to a self service portal, our user probably stopped what they were working on, went to their bookmarks to fetch the self service portal link, and figured out a way to access the knowledge base to solve their issue.
Is that really the most optimal way to serve our customers? We want them to do their jobs without any interruption yet, why do we interrupt them when we want them to consume our services? Why do we tell them “Hey, if you want to access our knowledge base you should stop whatever you’re doing and visit our website” and when they can’t help themselves, we say “Oh that’s bad. Why don’t you send me an email or fill out a form that’s available on our portal?”
Why should we make our customers come to us? Why can’t we take the service desk to them?
What do I mean when I say “selfless service”?
Self service still requires people to go to a place. That place could be a link, an app, or anything anywhere.
(def) Selfless - concerned more with the needs and wishes of others than with one's own;
Selfless service puts the user above the service desk’s needs. It tries really hard to get the service desk to where the users are and not make them have to come to it.
How do you develop a selfless mindset?
It’s important to have a selfless mindset right from the initial design phase. While designing your self service model, think hard about your end users. Think about their daily life. Think about the applications they use in their daily life. Now, think about how to get your service desk software into the applications they use in their daily life.
Remember, there is no Selfless good deed
If you’ve watched the TV Series F.R.I.E.N.D.S, you’ll remember Joey giving this wise advice. So you can ask the ultimate question - “What’s in it for me?” Think about what you really want. Do you want high self service adoption or do you want the business to run smoothly? By moving the service desk closer to your customers, you’re actually ensuring that you have easy access to them.
So what are the benefits?
1)Better adoption of the knowledge base Trust me, your users would rather solve their own issues than send an email or call you. It’s just that you have to make it easy for them.
2)You’ll get a more structured email aka a ticket The most annoying thing about email or phone calls is that it’s not structured and you’re always missing key information. That can be solved when your users fill out the ticket form. That doesn’t happen often, does it? If you’re thinking about this selflessly and make it easier for your users to fill out the form, maybe it will happen more often.
3)Everyone goes home happy! Think about all the good customer support experiences you’ve had. Doesn’t it create a warm fuzzy feeling towards the organisation that gave you the good experience? Your end users are no different. Make life easy for them and you’ll instantly find that the interactions are more positive. Don’t ask me how we can measure the positivity - you’ll just have the count the number smiles you get near the kitchen.
I’ll be talking about “selfless service” at the upcoming itSMF UK conference in November, on why it should be the way forward for service management. Here I’ll be sharing actionable advice to help you move you closer to your end users. As part of this to drive a mindset change within the audience.
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 Ferrishas made a good contribution to this field – you’ll find her white paper Balanced Diversity worth a read.
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?
·Right first time
·Escalation is bad
·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.
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.