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 

9 Top Tips to Create an Awesome Service Catalogue

Posted By Rebecca L. Beach, 31 May 2016
Updated: 31 May 2016


Some people will tell you that your Service Catalogue is the most important step in the journey of your ITSM organisation. That’s a lot of pressure.

There’s no denying it’s hugely beneficial to the business (that includes IT!) as it can improve communication between service providers and consumers, increase demand awareness and service visibility. The problem is that when there’s that much pressure it makes it difficult to know where to start.


At ITSMF UK we’ve been developing a new set of workshops and masterclasses and while working on Service Catalogue I started thinking about what my top tips might be to get started. Then I thought why stop there! So I asked some of my favourite ITSM experts what their top tips would be. Check them out below. 

1.     Ian Connelly, Chair at BCS Service Management SIG

The one tip I would suggest is not to try and boil the ocean… Very simply, start small. Either a limited scope (part of an office, datacentre etc.) or selected attributes from each CI, then expand it out.

Too many initiatives have attempted too much too soon, which leads to a feeling of climbing a mountain with the task.


2.     Barry Corless, Business Development Director at Global Knowledge

Service catalogue implementations that fail often do so because we are unsure of the objectives that service catalogue management (the discipline) is aiming to meet.  This leads to building and implementing the wrong tool.

For example, there is a big difference between what a vanilla service catalogue (a list of services) and a service request catalogue (used to drive self-service and automated workflow) will deliver.  Both outcomes are eminently possible using modern toolsets but we must concentrate on what we want service catalogue management to do before rushing headlong into a toolset implementation.  In many respects, the throw backs and similarities to the early days of configuration management and the lust for a CMDB should have taught us valuable lessons.  


3.     James Finister, Global ITSM Strategist at Tata Consultancy Services

Check and double check that the services you put in the catalogue are recognisable to senior managers in the business


4.     Stephen Mann, Writer at Quick Content Ltd

Involve the service catalogue's customers from the outset. It’s clichéd, but getting the right people involved is key. Remember that this is the business’ service catalogue, not IT’s. Thus IT shouldn't drive the look and feel, or content of the service catalogue – the business should. And it’s not a one-time consultation – keep them involved from design through to delivery.

Plus, given the growing pressure on corporate IT organizations to keep up with employee's consumer-world experiences and expectations of technology and service, the user experience and customer experience aspects of self-service and service delivery will be key to service catalogue success. With those responsible for the service catalogue needing to differentiate between the sexy-looking technology, with its great-looking user interface (UI), and how end users actually use and experience the technology and the service it provides. 


5.     Steve Morgan, IT Transformation and SIAM Consultant at Syniad IT Solutions Ltd

Ensure that you understand the business outcome that you expect the Service Catalogue to achieve.  Failure to “begin with the end mind” can lead to huge amounts of time being spent developing massive spreadsheets, that are never used.  For example, the term Service Catalogue can be confusing.  Ensure that you understand whether it is a “request” catalogue or a “business service” catalogue that you’re developing, and ensure that all of those involved in its development understand the definition, to avoid the risk of you veering off track, or producing a document that doesn’t hang together as a single entity.

Be very wary about trying to build a paper version of your CMDB under the guise of a business Service Catalogue.  It may be better to build a data model within your Service Management tool, and build a prototype directly into the tool, rather than trying to import a few thousand lines of Excel!


6.     Barclay Rae, CEO at ITSMF UK

Collaboration and close working will sort out more problems than a perfect design


7.     Stuart Rance, Service Management and Security Management Consultant at Optimal Service Management

Don’t confuse a service catalogue with a request catalogue

Many service catalogue projects fail because IT organizations are confused about what a service catalogue is, and what it should be used for. Every company needs a catalogue to help customers understand what services they offer, and IT is no different. You should create a service catalogue to help your customers understand what services you can provide and help them choose what will be available for their users.  Don’t confuse this service catalogue with the request catalogue that you make available to users so that they can order components of a service. For example, a customer may choose “mobile user support” from your service catalogue. This service could provide phones, tablets, connectivity, an app store and many other things needed to support a mobile workforce. If the customer chooses this service, then you will need to add specific phone models and apps that a user can select to your request catalogue. You need both types of catalogue, but make sure you know which you are trying to create and why.


8.     Matt Hoey, Chair at ITSMF UK Service Transition SIG

One of the difficulties in creating a Service Catalogue is the daunting amount of time it could take.  Tasks such as getting agreement on what goes into it and writing the definitions all take time when you are starting from scratch.  This can lead to a large amount of time elapsing between starting out and customers and Service Management teams getting value from it.

Taking an agile approach (in a nutshell: early minimum viable product and then iterating incrementally through feedback) can help you get something out sooner.  Make a first pass at the catalogue picking out the easily identifiable services, some basic information and put an early version of the catalogue out there.  You may not have all the services identified, or all the definitions written or even all the fields for the definition identified, but why not start using what you have rather than waiting for it to be complete?  In other words, don’t lock away that value whilst you wait for the finished product.  You’ll also get feedback from customers and Service Management teams from the early use which will help you with the further work on the catalogue which you can continue to do incrementally until you’ve built up your catalogue.


And my tip?


9.     I see many people creating what is, in effect, a repository of services. Having a centralised area for this information is good but if that’s all you’re creating it’s a waste of time and effort.

Create your Service Catalogue like you’re going to use it! Think about how and why IT and the business will be using this information and design it accordingly.


What’s your tip for creating an awesome Service Catalogue? Comment below or why not share with the ITSMF UK community on Twitter.



Tags:  Service Catalogue 

Share |
PermalinkComments (0)

How to Support the Innovation Mandate with DevOps

Posted By Robert Stroud, 25 May 2016

DevOps isn’t the answer to every business demand, but it might be the best way to keep up with the accelerating rate of change.


Travelling in Norway following a chapter conference there, I was undertaking some research for this article. As I searched the relevant web page, which was delivered to me in Norwegian, I was immediately asked if I wanted it translated. Shortly afterwards as I was looking for a hotel, I was immediately shown hotels close to my position. Location services and related technologies – determining from the available information who and precisely where the user is – are now becoming prevalent in all aspects of the online user experience. Indeed, they are at the centre of business solution design in a customer-centric era. It’s an era of disruptive technologies and rapidly evolving business models, and what continues to surprise me is the rate of acceleration in technological solutions to deliver business outcomes in ways that IT could not have imagined a couple of years ago.


This acceleration is creating significant issues for many CIOs and senior IT managers. Many have not yet realised their return on investment in existing solutions and are being pressured to accelerate their pace of change faster than ever before. The outcome in many cases is business management who claim that IT cannot react and deliver in a timely manner and then choose to source the technology via another route!


This has led to the rapid adoption of agile development methodologies to meet quickening business change requirements, and many IT organisations are looking to DevOps as the answer to their problems.


DevOps as the name suggests is a merging of Development and Operations. DevOps asserts a philosophy that removes barriers between the development and operations functions, allowing the rate and pace of change to accelerate across the business. The question that I am often asked by ‘disbelievers’ is whether DevOps is simply a strategy to give development and the business the right to skip the proven change processes and avoid the rigour of operations and its investment in current service and project management best practice.


This could not be further from the truth: DevOps is a business-centric philosophy to deliver business outcomes.

Tweet: #DevOps is a business-centric philosophy to deliver business outcomes - @RobertEStroud #ITSM


Speaking to the CIO of a large manufacturing organisation at an industry conference, he mentioned to me that their DevOps initiative is being led by the operations function, who are looking to accelerate the pace of change through pre-production testing to production, even to the point of automation of change reversal where change doesn’t quite deliver the desired results (this depends on processes being implemented to automatically validate change once in production).


The point is that IT needs to react and challenge current philosophies and framework implementations. DevOps is a philosophy that supports rapid innovation and IT-powered business change but it is not a panacea.


So how do we work with DevOps to accelerate our rate of change and overcome the resistance of the existing culture, and what techniques do we use? I thought that I would share some practical steps leveraged by other organisations to commence the journey:


Create a leadership DevOps advocate

Let’s face it, most organisational structures are overly complex, and red tape is often the primary obstacle to success. The first stage in the cultural change is to create a role for a senior executive who has power across the full IT domain to evangelise and sell the organisational benefits of DevOps.


Create the team

DevOps by its very nature is a combination of development and operations. Therefore, DevOps requires a cross-functional team with skillsets reflecting both areas; and to be successful the business must be represented as well.

These individuals should understand DevOps itself, but also be familiar with the processes and technologies that are needed to make the DevOps implementation successful. They must be completely dedicated to the cause and not distracted by other business. As the team progresses, process experts and tool specialists might also be required. The key thing to remember, particularly if you are using consultants, is not to forget the training or skills transfer.


Streamline processes

One of the major outcomes must be the automation of processes across the business. The starting position should logically be demand intake of all levels. More often, the initial focus is within the development organisation, through to QA/test and operations, including back-out in the case of failure. Before rolling out technology, DevOps teams must work on business and IT process improvements to ensure they have identified the challenges that their work could encounter and plan how to eliminate gremlins. Knowledge of existing business processes is a key skill, as is the ability not just to plan and test for success but also to prepare for process failure both for education and triage.


Budget for talent and technology

Although additional headcount, training programmes and technology will be needed to drive DevOps through the organization, over time the value and automation will change the way teams work and should release headcount back into the pool.

Processes including application delivery, service virtualisation, IT automation and release management integrated directly with your change and management systems with will only be successful with knowledgeable team members taking the reins and leveraging their intellectual knowledge. As a first step you should conduct an internal inventory of tools, identifying the gaps and filling the holes needed to support the DevOps methodology.


Get started with your troublesome applications and services

Rather that starting with a ‘big bang’ approach I recommend that organisations consider piloting or testing DevOps before committing completely. The best way to prove the value of DevOps is to start with an application and/or business service that has been causing problems across production and creating headaches for developers and operations alike as they attempt to remove defects. This sample service/application should demonstrate the value that DevOps can deliver. Once you have the recipe correct, repeat and repeat and this approach will soon attract attention across the organisation.


DevOps is a philosophy to focus the organisation on outcomes needed to support the velocity of change in an innovative world. It is not an answer to every business demand but when used effectively and correctly it can deliver real business innovation.


This article was first published in the Spring 2014 issue of Service Talk which is a benefit of ITSMF UK membership

To find out more about our range of workshops and masterclasses including DevOps visit our events calendar


Tags:  DevOps 

Share |
PermalinkComments (0)

How does IT4IT fit within the world of ITSM?

Posted By Rebecca L. Beach, 16 May 2016
Updated: 22 May 2016

I first heard IT4IT mentioned at the ITSMF UK conference last November. It piqued my interest but I admit to being unsure as to how this fit within the world of ITSM.

Fast forward six months and we’re holding a joint event with The Open Group to illustrate some of the benefits specific to those working within the world of ITSM. 

Ahead of the event on 25th May at the Copthorne Tara Hotel in London I chatted with Andrew Josey of The Open Group, Tony Price of HPE and CEO of ITSMF UK, Barclay Rae about what delegates can expect from the day.


Q. Without giving too much away ahead of the event what kind of impact can IT4IT have on a Service Management environment?

Tony - IT4IT has the potential of “providing the missing link” we have had in IT for so many years.  A prescriptive reference architecture for running the business of IT.  If organisations adopt this then IT Service Management at last will be contextualised and in my opinion even better understood.   We have always said ITSM is about People, Process and Technology but combine this with the overarching IT Value Chain and supporting value streams and you have something significantly more powerful than we have had in the past that the business can understand and that will drive IT to deliver true value.

Barclay - We’ve talked for some time about supply chains and value chains for IT Service Delivery. However the reality within ITSM delivery has been a focus on some effective yet still silo-based processes. IT4IT is a means to combine these approaches by applying a supply chain approach to established processes – so it builds on and complements ITSM/ITIL. I’m looking forward to this event to hear some good practical stories…



Q. On The Open Group website FAQ’s it says "The IT4IT vision is a vendor-neutral open standard Reference Architecture and value chain-based operating model for managing the business of IT.” What does this actually mean for organisations?

Andrew - IT management is fundamentally industry agnostic and up to now has had no prescriptive reference architecture - there has been no standardised approach, no common information model. The IT4IT Reference Architecture fills the gap. It was created as a holistic, concise and structured standard for how IT should be managed in order to provide maximum value for the business.

It can be thought of as a blueprint to accelerate IT’s transition to becoming a service broker and service integrator. While existing frameworks and standards have placed their main emphasis on process, the IT4IT standard is process-agnostic, focused instead on the capabilities and information needed to manage a service through its lifecycle. It defines how the IT function can be supported by information systems automating the IT activities as well as providing the necessary insight to improve IT decision-making and support continuous improvement.


Q. Why is holistic management of the business of IT so important?

Andrew - The essential principle behind the IT4IT approach is that the IT function should be organized and managed as a business. The IT4IT value streams and IT4IT Reference Architecture define an overall framework that can be used to identify the end-to-end workflows in the IT organization that create value for the business — they provide the bigger picture of how IT services should be managed, throughout the entire lifecycle. Every IT organization can benefit by adopting this holistic end-to-end view based upon the IT4IT value streams.


Q. Finally what can delegates expect to take away from the IT4IT for Service Managers event on the 25th May?

Tony - A good background on IT4IT and how complementary ITSM is. Plus, some real life practical examples showing how IT4IT has delivered true value.  We will also highlight some lessons learned by early adopters and show some comparisons to lessons in the ITSM world.

Barclay - We'll be exploring this area as a complementary approach for service management as part of our wider debate about professionalism in ITSM - it'll be a great event


Join us on the 25th May and find out how IT4IT can drive your ITSM organisation to deliver true business value 

Tags:  Event  IT4IT 

Share |
PermalinkComments (0)

What does studying music have to do with Shift Left and ITSM?

Posted By Barclay Rae, 08 April 2016


When I was younger I learned to play the piano and the drums. I was often bored and irritated by the need to learn scales for the piano and ‘rudiments’ (rolls, paradiddles etc) for the drums. “I won’t ever actually need to play these,” I would think (and I see this with my own elder son who is also learning piano).


This of course is true: no one wants to go to a concert to hear major or minor scales. The point however is that they provide two things... 

  • technique to play the instruments 
  • an awareness of the musical environment of music. This helps with creating new and interesting melodies, harmonies, rhythms and motifs.

There are similarities here with how we perceive and use the core elements in the ITSM world…


Much of the traditional training content built around ITIL and ITSM focusses on processes. We still need these, of course, but often we focus on the process rather than the outcome or intended goal. It’s important that we use these processes. But they are not the end game of this work. They are just the building blocks that we use to create practical and effective service solutions.


Here's an example. Many of us use Incident, Problem and Knowledge Management with CSI to improve the following:

  • Cost effectiveness
  • Customer satisfaction  
  • Employee satisfaction.

If we improve our CSI and Problem processes to move more issue resolution to the front line we can reduce customer downtime. This also reduces the cost of managing incidents. We can also deploy Knowledge Management to re-use fix activities to speed up future resolution. 


Improving first-level fix rates is better for customers and also for support staff. It creates a more rewarding role for service desk staff, and second/third line staff are able to focus more on strategic technical issues. All these practices use ITIL/ITSM processes. They are the scales and rudiments that we can use to create a great customer experience and effective service operation.


We often call this ‘Shift Left’ – ie to move the resolution point as near as possible to the customer. Shift Left is an application of ITSM using existing processes. It is a focussed way of thinking around improving service quality rather than simply a boring old process. Just as with music and other endeavours, if we want to be successful, what matters is not just that we learn what the basics and rudiments are, but how to apply them.



Check out details of our new Shift Left workshop on 26th May.

Find out more about:

  • What you need to know about Shift Left in ITSM
  • Creating the right environment and culture for shifting left
  • Identification of areas to shift
  • Why self-service isn't always the answer.

This post has not been tagged.

Share |
PermalinkComments (0)

Progress from the SIAM Process Working Group

Posted By Administration, 11 March 2016

Back in October 2015 the SIAM SIG process working group was formed from a number of willing likeminded volunteers.  We were given the following challenges:

  • To identify which processes are included in a SIAM Process Framework

  • Establish the demarcation between the Integrator, Service Providers and the Retained IT organisation?

So over the past few months the SIAM SIG Process working group has been working hard to clarify the impact of the various SIAM implementation models on established Service Management processes as well as identifying additional processes which either underpin or complement the implementation and operation of a SIAM solution.


As part of the work completed to date, we have developed a number of spreadsheets which have taken inputs from ITIL as well as the groups ideas and experiences re business based processes.  The majority of the work to date has been focussed on the Outsourced SIAM model as we all believed that if we got one model completed then the others would contain the same information but the responsibility for the process and outputs may change.  However, it soon became clear that the 4 SIAM models can be tailored to meet the needs of the business implementing them, so throughout our work and discussions the phrase ‘it depends’ has been used extensively.


Within the spreadsheets we have:

  • Identified the overarching process framework (30+ processes) and the stakeholder groupings

  • Assigned individual processes to the stakeholder groupings

  • Identified the mandatory Service Integrator processes 

  • Identified process outputs / deliverables from each stakeholder group in the framework 

  • Mapped processes between SIAM, COBIT, CMMI and ITIL

In parallel to identifying the processes we began to document the ‘steady state’ RASCI (Responsible, Accountable, Support, Consulted, Informed) matrix.  This has grown and to date has circa 200 activities identified.


The work to date culminated in us sharing our progress with industry at the ITSMF UK SIAM SIG meeting on the 29th Feb 2016.  In the morning we presented an overview of the SIAM models and what the group had been doing.  The afternoon saw us presenting a detailed view of the RASCI and process spreadsheets to a very enthusiastic audience, within 10 mins we were being bombarded with positive questions about how we had come up with the various RASCI allocations, from the participant’s feedback on the day, it soon became clear that as a start point the matrix worked very well but it would still need tailoring to individual businesses and projects because ‘it depends’.


Everyone on the day was keen to get their hands on the output so far but the session, whilst giving us great feedback on what we have achieved, also demonstrated that we are not there yet.  There were a small number of processes and activities offered which require consideration.  In addition, there were some good suggestions regarding referencing other frameworks / standards such as IT4IT.


So after a quick break to catch our breath it is back to work, completing the RASCI and Process spreadsheets for the 4 models and then moving to the next stage which could be ……. well it depends.


This post has not been tagged.

Share |
PermalinkComments (0)
Page 10 of 14
 |<   <<   <  5  |  6  |  7  |  8  |  9  |  10  |  11  |  12  |  13  |  14

Premier Gate
21 Easthampstead Road
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us