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 

How relevant is the Service Design Package in the age of Agile?

Posted By Anthony Oxley, 27 September 2017

 


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. 

Put simply…

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.

Tags:  ITSM 

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.

 

Mon

Tue

Wed

Thu

Fri

Sat

Sun

12

9

4

7

5

6

10

 

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)
 

ITSM Podcast Episode 1 - SITS16

Posted By Rebecca L. Beach, 12 July 2016
Updated: 12 July 2016

 

In this new series of podcasts we'll be talking to self proclaimed ITSM "old fogies" Barclay Rae, James Finister, Stephen Mann and Pat Bolger and other guests about everything ITSM.

Episode 1 comes from the floor of SITS16 and features guest Ollie O'Donohue from SDI and a brief gatecrashing from Chris Matchett

View all our podcasts on SoundCloud or iTunes.

 

Tags:  ITSM  Podcast  SITS16 

Share |
PermalinkComments (0)
 

The Millennial Shift: How to Bring New Blood into ITSM

Posted By Sandra Whittleston, 08 July 2016
Updated: 07 July 2016

 

Very often when attending IT Service Management (ITSM) events and meetings, discussions focus on the newcomers to our industry. Popular questions include, “where is the new blood and where it is likely to come from?” and “how can we encourage new people into our industry?” Teaching ITSM to young people and older career changers whilst they study on university programmes sends hope for the future because of the way that students engage proactively with the concepts and easily join in debates. This is primarily because they understand the service culture and often have strong opinions, both of which can have a positive effect on how they approach their studies.

 

There is no doubt that young undergraduates learn best when using technology, respond to different assessment types, can socialise, take global stances and use problem solving activities as a way to explore and develop their understanding. These younger students leave university and go into the world of work armed with theoretical knowledge of ITSM and with an enthusiastic and creative view of how they can use this knowledge in their new employment. Indeed, students can often get interviews and sometimes a job offer directly on the strength of studying ITSM on their degree course.

 

Mature students (better described as those with working experience and/or who already have jobs in ITSM) relate stories about how they have become more confident in using the material; often pushing back pre-conceived ideas held by them or their colleagues.

 

Whether they are young undergraduates or part of the more mature group, ITSM lecturers often find students enjoy the ‘journey’ rather than concentrating too much on the destination.
Longitudinal study of ITSM (observation over a period of time) has some benefits here; teaching staff witness the growth of the individual over the timeframe that they study.

 

The diversity in the student demographic is both constructive and challenging. It is often found that mature students engage more proactively with the material from the initial weeks of study as they are keen to apply additional concepts not normally included within the ITSM material; for example organisational change. However, this is not always the case as prior knowledge of ITSM is not always a prime motivator, nor is lack of prior knowledge a de-motivator; much depends on the individual.

 

The prime focus of many business and management events these days is about the value of good service and how businesses can use technology more efficiently with good outcomes for the customer. Aimed at business and IT professionals, these events prove beneficial as talking shops where the old chestnuts of organisational change, effective project planning and understanding stakeholder needs can dominate conversations. The ideology of a ‘service culture’ is easy to understand, but creating it is can be another matter. It seems that whether a person is a young undergraduate or a mature business or IT professional, the issues around creating good service are well understood.

 

It is easy to see why, in today’s service-orientated world, the progression to advanced thinking and understanding is important. This is confirmed by listening to conversations at ITSMF UK conference and events, where there are often enquiries from those working in ITSM about what further opportunities are open to them. For example, some people wonder what they can do after they have achieved ITIL Expert, when they may also have a range of other business or IT standards qualifications under their belt. Some have achieved a Master of Business Administration (MBA) from a university. Still questions remain about further ‘inquiry’ and/or personal or work-based research on service issues.

 

These are pertinent questions. After all ITSM is a practically based discipline and lends itself to further personal or organisational research beyond training or undergraduate education. One route for working students with a quality undergraduate degree, underpinned by other professional qualifications or industry experience, is that they may be eligible for direct enrolment onto a PhD. The challenge for universities is to understand the market need, to develop academic programmes which will be conducive to this, and to have specialist academics or professionals who are equipped to supervise students whilst they research. It could be argued that the ITSM industry needs its own journal where quality papers including sponsored and unsponsored research are peer reviewed and published.

 

Generational Differences

Going back to the question of trying to get to grips with where the next generation of ITSM professionals are likely to come from, it is important to understand how young undergraduates perceive service. As already noted, the concept is not alien to them. It is also important for the ITSM industry to understand the demographic of those already working in the industry, their motivations for further inquiry, and how they currently embrace the service culture.

 

Human resource research identifies the challenges to handling a multi-generational workforce by understanding the preferences, expectations, beliefs and behaviours of each generation*. So how can this apply to ITSM? It could be argued that those with work experience and/or qualifications in ITSM are more than likely to be aged from 34 to 45, a group which has distinctive attitudes to life, work and learning - tending to be salary driven and to see work as an anchor. Research shows that people in their mid to late thirties also place great value on work-life balance, and are less likely to succumb to work pressures than those over 45.

 

Conversely those in their late teens up to early thirties are the techno-savvy, confident and tenacious generation who rely heavily on technology for both work and pleasure and as such have different perspectives on jobs and lifestyle from their older counterparts. Having easily embraced technical inter-connectivity through social media, they are known for their collective action, flexibility and (generally) being street-wise. They naturally challenge long-held views and methods and are not afraid to say so. As such they expect old ways of thinking to be re-evaluated and for others to see that it is the end result that counts, not the perception of when, where or how things are done. In the university environment, they expect their lecturers to not only be cognisant of their view of the world but also to embrace differing views themselves.

 

Whilst these are generalisations, they are borne out by the author’s teaching experience. The prevalent attitudes of these two demographic groups can meld together quite happily, though, not only in the work place but in the way that they are trained or educated.

 

Embracing the Millennials

Understanding the mind-set of the newer generation (often referred to as Generation Y or Millennials) is a challenge for those teaching in universities. It is important for the service management industry to understand it too. Collectively, university staff and ITSM professionals may require a shift in thinking about how to encourage Millennials while holding onto existing values too. The shift must develop naturally from a blend of teaching and learning built on solid educational foundations. Importantly, it must come from positive knowledge sharing across generations, as noted by those developing multi-generational concepts in their workforce.

 

Enlightened ITSM departments will set up mentoring and coaching for these newcomers, passing on war stories and the benefits of practical experience. However, the shift should not just be one way. We should encourage the latest generation to influence and challenge old ways of thinking, readjusting long held perspectives and creating a new thrust in the development of the core material which reflects a ubiquitous service culture. As Gilbert K Chesterton stated, “Education is simply the soul of a society as it passes from one generation to another”. Therefore the soul of ITSM must persist and be passed onto the next generation.

 

Attitudes and values go beyond the generations. They are also affected by social, cultural and behavioural influences, so things are not always clear cut. The new generation, however, will not wait for changes to be introduced by their older counterparts; they will find their own way and they are here amongst us today!

 

We should value the mind-set of the newcomers for what they will bring to ITSM, giving them a status they can relate to: say, Young ITSM Professional. We should create the conditions where an inter-generational community of inquiry exists which is built on new ideas, is readily shared across social platforms, and fosters further debate.

 

Above all we should not be afraid to encourage profound feedback and comment from them as they challenge long-standing views and beliefs.

 

Quite rightly educational institutions should create mechanisms for all of this. Importantly, there has to be an endemic understanding of the challenges that these institutions face as they include ITSM in their academic portfolios. The ITSM community must also reflect and respond accordingly. Collectively education and training providers must work together to create mechanisms for lifelong learning and development in ITSM so that newcomers and those developing their existing careers are exposed to a blend of education, training and experiential learning via dedicated but flexible routes. The term ‘education’ in ITSM must be seen as a generic concept, not purely academic learning.

 


This article first appeared in the Autumn 2014 issue of Service Talk. 

Tags:  Career  ITSM 

Share |
PermalinkComments (0)
 

Release Management - Delivering More and Breaking Less

Posted By Richard Horton and The Transition SIG, 30 June 2016
Updated: 30 June 2016

 

If you want a one-line summary of the challenge faced by people delivering IT services, you could do worse than “How to deliver more and break less”.

 

Given that there isn't a limitless pile of money available to throw at this problem, and that there are constant pressures to reduce costs, clearly we need to improve our practice if we are going to reduce the breakages.

 

The good news is that there is room for improvement. Despite years when change and release management have been viewed as core ITIL processes, likely to get an organisation’s attention before many others, we still haven’t got these essential elements cracked. Much is spoken about agile and DevOps, but when push comes to shove, many people are still taking a more ‘traditional’ approach to release management, if they have got that far.

 

At a recent Service Transition SIG meeting, we took a look at the sort of challenges that face us in deciding how to do release management, and a range of approaches we can use in addressing them. 

 

We started with our hosts Arqiva, who outlined to us the complexities that they face as they serve customers with competing demands. They have to balance their requirements on a shared infrastructure. And if they mess up, they are acutely aware that the nation will know, as their mistakes have the power to bring down television or radio transmission. Arqiva explained how they have delivered impressive increases in the reliability of change implementation, but still face some challenges in release management.

 

So what sort of models could be applied? There isn't a ‘one size fits all’ here. Some organisations, we discovered at the meeting, focus their release management more at the technical level, while others opt for an implementation scheduling approach. Others might want more of an enterprise overview, coordinating the dependencies which projects look after. We looked at the challenges faced in each case and the potential role conflicts inherent to each approach.

 

We then considered how to bundle releases, whether going for the ‘small and often’ or the ‘big and occasional’ approach (or a mixture). We considered the possible constraints in both cases and what kind of a release plan you might put in place to help alleviate these limitations.

 

Smaller and faster projects tend to be linked with agile, but this isn't necessarily the case. Those using the traditional ‘waterfall’ approach can learn from agile here. On the other hand, if attempts to be more agile are too eager, there is a danger of relaxing the waterfall controls without recognising that agile has controls too. Basically there isn't a shortcut. If you want to improve you have to work at it.

 

Planning is an important area. We considered the factors that can torpedo what might look like a good plan, complete with plenty of contingency, as projects still end up getting put back and put back, with huge overruns resulting.

 

So, now we have set ourselves up to deliver more. Great... but only if it works. How do we reduce the fallout? Approaches to testing are key. A measured approach comes in handy here. Things don't always work first time so why do we assume they will? We want a well thought through approach to testing, including awareness of the risk/opportunity equation, so that we are not just doing endless testing for the sake of being bullet proof, but delivering too late to be of any use.

 

If we understand the importance of good testing we will prepare our scenarios in advance, consider where automation can help (bearing in mind the pay-back period) and, where we are not automating, assign people to perform testing who have both the right skills and the will to do it. And it would be really helpful if we could ensure our environments match as well, so that we are testing like for like and can see the wood for the trees.

 


 


If you would like to find out more about the Service Transition SIG’s work on release management, why not attend one of their regular events which you can find on our event calendar.

 

ITSMF UK also run a series of workshops and masterclasses covering many topics including Release Management.

 


               

 

This article first appeared in the Spring 2015 issue of Service Talk

Tags:  ITSM  Release Management  Service Transition 

Share |
PermalinkComments (0)
 

Premier Gate
21 Easthampstead Road
Bracknell
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us