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 

Automation and Self-Resolution – Are we up to the challenge?

Posted By Robert Stroud, 06 September 2016
Updated: 05 September 2016
With our growing dependency on IT, we need to start delivering services in the way that our customers really want them.
I was recently shopping in a store, something that I don’t enjoy doing. Whilst waiting in the long line the announcement echoed over the store intercom that sales were temporarily suspended due to a computer failure. Now, instead of abandoning my trolley and leaving the store, I thought that I would wait this one out and see how IT and the business interacted to resolve the problem. As I watched, the store manager worked on the phone with the ‘help desk’ to isolate and remediate the problem. The triage and resolution took for what seemed hours but actually was only a matter of minutes.
Especially interesting to me during this entire incident was the reinforcement that technology was a single point of failure in the company’s business process and the assumption that ‘IT’ will always be on and will work. 
After the shop had reverted to business as usual, I asked the manager why his staff couldn’t simply use calculators to process the customers’ orders. He explained that it was company policy to suspend transactions in these circumstances due to the total interconnectivity of inventory systems, differing tax rates and so on for which the staff had not been appropriately trained.
For me this was a stark reminder of the growing dependency on technology that we all face in our lives, a situation reinforced by a number of changes:
  • Mobility – no longer a fad but business as usual.
Smartphones and tablets are everywhere; just look around you at the moment. Today, enterprise applications are being delivered in ‘fit for purpose’ apps on mobile devices, threatening to make desktops and even laptops irrelevant. Think for a moment about the growing number of virtual stores where cameras on smartphones are used to scan barcodes, and then the associated app interfaces with the inventory system, processing orders and credit card transactions and emailing receipts. This represents only the beginning. Apps will proliferate and even be integrated into a constructed business process that can be developed within the organisation by a business analyst. Mobility is no longer a ‘fad’, it’s the norm.
  • Complexity across the service value chain 
IT services are becoming increasingly complex. This is partly due to the way that third parties are used for selected functions, while older technology retained at the heart of the organisation is required to do unnatural acts! This added complexity makes it more difficult and expensive to address issues with these services, which means that IT must become more proactive. This can be achieved with the integration of IT infrastructure tools that monitor all aspects of the service topography, including partner interfaces, and then aggregate the outputs of these tools – metrics, alerts, etc. – related to the services. The goal is to understand potential performance issues or failures and to deal with them before they recur or become a problem.
  • Self-resolution the norm 
I, like many others, regularly network with my virtual peers and community to seek answers to questions. My daughter-in-law, for example, was recently trying to resolve a problem with some software she used for her work. Instead of calling the service desk, she posted a question on Facebook and the community pointed her to an update to the software application and she self-provisioned the solution, without any interaction with the IT organisation.
Today we trawl the internet for great travel deals and book our travel online. Only a decade ago we used a travel agent. Now, if there are problems with our reservations, we can resolve them quickly on our own, instead of having to queue or contact a service desk. Today, if my plane is cancelled, I am notified almost instantly of my new arrangements on my wireless device and I only need to call if I am not satisfied. The airline is acting proactively, not waiting to react when the phone rings.
Self-resolution is clearly becoming the norm and will become more pervasive.

  • Automate everything 
IT organisations must focus on the automation of service creation, delivery, resolution and escalation. This is not just to provide better customer service; forward-thinking organisations are automating in order to make resources available for value-added activities such as building new services or proactive problem management.
It is not enough, though, just to automate the IT process. We must ensure that relevant audit checkpoints are maintained and automated restoration is available in case of failure. Automation is critical!
  • Deliver services, not resolve incidents
The accelerated business cadence is all about delivering service to the organisation’s customers with speed, quality and differentiation; but to achieve this requires more than automation and slick technology.
The service desk team must also transition. The team must shed the image of waiting for the phone to ring, documenting and passing the issue to the next step in the chain. The team must focus on building and delivering in order to increase both their real and perceived value within the organisation; otherwise they will quickly become irrelevant.
Many people tell me that service management is dead. Not true! What is true is that the role of service management is evolving - from one of support to one of focus on delivery and proactivity. With our growing dependency on IT, we have a challenge and an opportunity to add even greater value to the business in the months ahead. 
Are you up for the challenge?

If you'd like more help with this subject then why not attend one of our workshops? For more information visit our events page 

Tags:  Automation  Managing Complexity  Service Catalogue  Service Delivery 

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)

5 Simple Tips for Effective Problem Management

Posted By Charles Fraser, 23 June 2016
Updated: 22 June 2016


Undertaking effective ITIL-based problem management is essential for any IT organisation that wants to deliver high levels of service availability and consistently high quality IT services.

It is however an unfortunate fact that the great majority of IT organisations fail to realise any noticeable benefits from the time and effort they spend undertaking problem management.

This article provides you with five simple and practical tips to help you to set up and maintain effective problem management.


Tip 1: Focus your problem management efforts on finding permanent solutions

Forget about using problem management to find temporary solutions.


If you want problem management to deliver real and tangible value then you must develop a problem management process that focuses on finding permanent solutions.


Only by focusing your problem management activities on permanent solutions will you be able to substantially reduce your volume of incidents. And it is in the reduction in the volume of incidents that the real value of problem management is to be found.


It is important to be clear about the distinction I am making between permanent and temporary solutions:


  • A permanent solution is where the underlying cause of the incident(s) has been addressed in such a way as to prevent the incident from occurring again


  • A temporary solution is one which is employed to get the user up and running again ('as quickly as possible') but which will not necessarily prevent the incident from re-occurring in the future – e.g. temporarily re-routing a user to a different print queue


Please note I try to avoid using the term 'workaround'. This is because it confuses everybody. It is confusing because it can be applied to both permanent and temporary solutions. Because of this it is best to avoid this term (stick with permanent or temporary solutions – these are terms that everybody can understand).


So, the key to getting real value from problem management is to build a process that concentrates on finding permanent solutions. Only by doing this will you be able to deliver the value (reduced volume of incidents) that justifies the time, effort and resources involved in the investigation of problems and the subsequent deployment of permanent solutions.



Tip 2: Make sure your problem management process delivers real value

Most organisations that are familiar with ITIL undertake some form of problem management. And with very few exceptions they are wasting their time. This is because they have put in place a problem management process that delivers no real (tangible, meaningful and measurable) value.


How do you know if your problem management process is actually delivering value? Well, first of all you need to forget all about the various (irrelevant) metrics that are often mentioned. For example, the time taken to complete a root cause analysis, the number of problems in the backlog, etc. None of these actually indicate, reflect or measure the value of undertaking problem management.


There is in fact only one truly tangible and meaningful measure that your problem management process is delivering value – and this a reduction in the volume of incidents. If this is happening you have a worthwhile problem management process. If this is not the case… well, sorry to be blunt but you are just wasting your time. It is that simple.


You must regularly (every three months?) review your problem management process to check that it is delivering value and that the volume of incidents is falling. If it is not then you need to stop what you are doing and change. Change your process. Make it better – make it effective.


If you want, you can go a stage further and set some specific targets. For example, reduce Priority 1 incidents by 40% within three months (this is a very valid target because it ensures that you are addressing the incidents with the greatest adverse impact), reduce network printing incidents by 60% over six months, etc.


Now I am fully aware that other factors can impact the volume of incidents, and a lot of organisations use this as an excuse for not using incident volumes as a measure of problem management effectiveness. I do accept that many factors can impact the volume of incidents, and in some circumstances even with good problem management in place you might see incident volumes (temporarily) increasing.


But even with all these potential issues the volume of incidents still remains the single most important indication of the effectiveness of your problem management process. Forget everything else: just make sure you are achieving this and, if not, then do something about it!


Tip 3: Make your service desk/incident manager your problem manager

Yes – I know. This is something that ITIL advises against. And I know and understand why ITIL advises against this. But I believe that in this case ITIL has got it wrong.


There is in fact a very good reason why your service desk/incident manager should also be your problem manager. But before I go into that I want to be very clear on what the role of problem manager actually involves.


Problem manager is not a technical role, and the problem manager does not undertake problem investigations. Problem investigations (both the root cause analysis and the solution identification) are undertaken by an appropriate subject matter expert (SME).


The primary responsibilities of the problem manager are in fact administration, co-ordination and facilitation. The specific activities, among other things, include:

  • Reviewing requests for problem investigations to see which are justified
  • Developing the business case for each problem investigation in order to justify the resources required for that investigation
  • Arranging for the appropriate SME resources to be made available and assigned to a relevant problem investigation
  • Producing the terms of reference to be followed by each SME undertaking a problem investigation
  • Overseeing the investigations undertaken by the SME
  • Validating the root cause analysis and the proposed permanent solution
  • Reviewing the effectiveness of the deployed permanent solutions.


In the majority of organisations there is rarely the justification for a full-time resource to act as problem manager. Therefore it is often combined with another role. The first, and very important point, is that you must appoint somebody to this role. You will not be able to undertake effective problem management without somebody acting as (an effective!) problem manager.


Now back to the original point. Why do I disagree with ITIL and recommended that you combine the roles of service desk/incident manager and problem manager?


Well the reason is simple. The primary goal of the problem management process is to reduce the volume of incidents (see Tip 2). So you want to ensure that the problems prioritised for investigation are those that will deliver the greatest benefit – i.e. will lead to the biggest reduction in re-occurring incidents (or will eliminate the most 'damaging' incidents). Makes sense so far?


So - who is best placed to decide which problem investigations will deliver the greatest benefit? Who is best placed to decide which problems will justify the resources required for investigation?


It is clear this has to be the person who stands to benefit the most (in the IT organisation) from the reduction in incident volumes, and the person who has the greatest visibility and understanding of current incident trends and volumes.


This is clearly the service desk/incident manager. This is in fact the IT role that has the greatest vested interest in ensuring that you are undertaking effective problem management. And this is why the roles should be undertaken by the same person.


There is no 'conflict' between these roles; there are only shared goals and benefits. So combine the roles - it is the only sensible option.



Tip 4: Get on with it – you do not need specialist resources or tools 

Some organisations hesitate to put problem management in place because they believe they lack the 'resources' to undertake problem management – i.e. the required people and an integrated incident/problem management system.


This is nonsense. You do not need any special resources in order to undertake effective problem management. You can do it perfectly well with the resources you already have.




Unless you are a large third-party IT service provider you do NOT need to set up a dedicated problem management team, full of technical experts to undertake problem investigations. This is in fact completely the wrong thing to do.


The SMEs you allocate to undertake the problem investigations will in fact come from your existing IT departments and teams. The key is to make sure that the time and effort they spend on problem investigations is fully justified. This is a responsibility of the problem manager (see Tip 3). How much time will the SMEs need to allocate to problem investigations? Well, this depends on the nature of and the number of the problems you decide to investigate.


The bottom line is that you can start problem management with the staff you currently have.


One important point to note: please be aware that a significant proportion (the majority?) of problem investigations will be non-technical in nature. The great majority of incidents are caused by failures in process, procedure, human error, etc. Problem investigations are often more about finding out why a procedure failed than why technology failed. So an SME is not necessarily a technical resource.




You do not need to spend money on specialist tools/systems for problem management. There is absolutely no need to dynamically link incident records to problem records, and problem management is not dependent on an integrated incident/problem toolset.


And contrary to what is commonly believed, there isn’t any real benefit in the service desk being able to access the problem records. 


So, to be clear - you do not need any special resources to start undertaking effective problem management. Just get on with it.


Tip 5: Don’t worry about distinguishing between pro-active and reactive problem management

Who cares where problem requests come from?

Does it really matter if they come from undertaking regular trend analysis of incidents, or if they are generated automatically as a result of a Priority 1 incident being logged? No - from the perspective of developing an effective process for the investigation of problems the source of those problems is largely irrelevant.

Many organisations set up overly complicated problem management processes because of the perceived need to have separate procedures for proactive and reactive problem management. But the distinction between proactive and reactive problem management is an unnecessary complication. You do not need two separate set of problem management procedures.

Now it is undeniably important to carefully identify how, when and from where potential problem requests originate, and how they are to be submitted to the problem manager for consideration. For example, who has responsibility for analysing the incident trends, how often should they be analysed, how are they to be analysed, etc.? If a problem request is to be raised after a specific event (e.g. a high-priority network failure), then how is this to happen. All of this should be defined and clearly documented within your problem management process documentation.

But from the point where the problem request is submitted to the problem manager the process for considering the justification for that request, accepting and prioritising the investigation, assigning the resources to the investigation, validating the results of the investigation etc., is the same irrespective of the source of that request.

So avoid the unnecessary complication and ignore the irrelevant distinction between pro-active and reactive problem management. Develop a single end-to-end problem management process.


If you'd like more help with Problem Management then why not attend one of our workshops? For more information visit our events page 


Tags:  problem management  Tips 

Share |
PermalinkComments (0)
Page 7 of 13
1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9  |  10  |  11  |  12  |  13

Premier Gate
21 Easthampstead Road
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us