Fox IT® is a registered trademark of Fox IT SM Limited
The Service Catalogue, Part 2 – Getting Started (10 Steps to Success)
An Article by Neil Walker, Principal Consultant at Fox IT. ‘The Service Catalogue, Part 2 – Getting Started (10 Steps to Success). This is Part 2 in a series of articles promoting the benefits of the Service Catalogue.
We should all now be convinced of the benefits of a service catalogue. If a reminder is required, visit The Service Catalogue, Part 1 – Why Have One? The problem next for discussion is how to get started?
This article sets out pragmatic steps for planning and implementing a service catalogue. It is a guide to those wishing to identify improvement activities for pursuing with their own resources, or as a lead-in to discussion with consultants where more guidance or a ‘hands on’ approach is needed from a third party.
The steps will prove useful to organisations that are interested in (but are struggling with) formalising their agreed business customer requirements, cataloging their services and implementing a service catalogue process.
Although the primary audience of the article is those involved in IT, the concepts and steps can equally be used for other business supporting services.
10 steps to success
1. Ground rules
The first step is to have a clear view of what you want to achieve from the exercise; the benefits you hope to realise and those that need to be involved. Failure to crystallise and articulate your own thoughts will run the risk of not engaging support from others and not progressing past the next early steps.
Self-questions that should have answers ready include:
- What is a service in your organisation? For example, a collection of components and other services that, when combined, provide the business with the functionality it needs to operate.
- What is a service catalogue? In simple terms this could be a list of the ‘services’ (not systems) provided to supported business(es).
- What services and service structure do you have in mind (although this will be defined or refined later)?
- What data exists and where is it? You probably have more information than you think.
- What visibility of the service catalogue is required?
The exercise should be run as a project with realistic objectives and timescales; also consider a pilot to establish the approach and credibility.
Underpinning all of the following steps is the establishment of a ‘service-focused culture’ within the organisation, so start thinking in service (not technology) terms.
Success will rely on a collaborative approach so if not already established, start to develop the relationships with business customers and other stakeholders.
Due to differences of perception of services between those receiving them to whoever provides them, it is wise to include business input into the project. However, from experience I also understand that many service providers prefer to initially work through developing a business-value-based service catalogue internally, making the distinctions between services, processes, products and platforms; thus preventing going to the business with a blank sheet of paper and asking them to define the services.
The choice on how deeply and when to involve business stakeholders will be on an organisation-by-organisation basis and will depend on the maturity of the IT-business relationship. If not involved at the outset, there is always the opportunity to engage with business departments later on after an internal review has taken place.
Education at the outset aids buy-in; speeds up the process; avoids costly delays later in the project; gets everyone talking in the same language and establishes open communication channels.
A service catalogue presentation and workshop will:
- build common awareness and understanding of service catalogue concepts, practicalities and business value
- build a common understanding and consensus around the approach
- provide advice and guidance on the development of service catalogue schema
- kick-start the service definition process and give everyone a clear plan for moving forward.
A key message is to reflect the words and perceptions of the business and users. IT professionals too often confuse processes, technologies and platforms with services, and then wonder why they aren’t connecting with their customers.
Because every organisation is unique (type of business, services offered, size, supply chain, etc.), each IT organisation will need to build its own IT service catalogue. While many IT organisations may offer more or less the same fundamental services, the way in which you describe and position those services must be specific to each individual business context. For this reason, there is no such thing as a single “best practice” IT service catalogue.
Closely linked to the previous steps, management support must be obtained. Produce a formal presentation about the benefits of the service catalogue, how you plan to use it and the importance of top-down sponsorship.
Working with management, choose a person to lead the building of the initial catalogue and a representative team with various viewpoints. Getting the right people involved is crucial and could include:
- Service Delivery Manager(s)
- At least one senior stakeholder to support the work
- Some service experts who can help align the services with the technology that make them work
- Process owners (typical inclusions for IT are – Change Management, Service Asset & Configuration Management, Service Desk Manager).
Develop a policy of what is a service and how it is defined and agreed. The policy sets management intent and direction. It is needed at an early stage so that everyone involved in the implementation is clear about what is to be achieved.
4. Think business – not technical!
Reflecting the customer’s viewpoint in how services are described is often one of the biggest challenges. A common mistake with many service catalogue initiatives is defining services in technology terms, with service levels based on the metrics that are easiest for IT to track.
The problem is that while IT tends to be organised around technical, skill-based or asset- based silos, business users think in terms of business outcomes. So while IT’s customers may be thinking about on-boarding new employees or their order-to-cash process, IT is talking about their change management process or distributed computing.
This inside-out view is a common trap and is destined to lead to failure of the service catalogue undertaking. Successful service catalogue projects start by asking business stakeholders and service users what’s important to them, and then building the catalogue around those success factors. This is the outside-in approach.
We’ve already mentioned in step 1 the choice of business involvement but working with customers to understand their business processes, service expectations and priorities will help in how these could be created as services.
If you package and communicate your services and metrics with a focus on business relevant deliverables, rather than the underlying technologies and technical service levels, you’ve overcome one of the greatest barriers to success.
5. Service identification, naming and bundling
Firstly, it is necessary to review the current state environment to understand the current services being offered before documenting them. This step establishes the ‘highest’ level within the service catalogue structure and provides a comprehensive infrastructure that supports all services that once agreed will hopefully require minimal revision. In many cases one higher level service can be made up of other services. Therefore, the services can be formed into groups or a hierarchy of services.
Start with a reasonable number of services and don’t attempt at listing hundreds of subservices.
The best approach is to hold a ‘brainstorming’ workshop to identify the business level services provided; this not only works well in recording the services but it also helps everyone involved reach common understanding and visualise the scope of services involved. I have found that this often results in a “wow” moment for those involved at the volume of output.
The team must work to achieve a consensus on the service names. This is important as the business and IT will probably have different names for the same service (e.g. messaging & calendar, email, MS Outlook). Sometimes a consensus on service names proves difficult due to dissimilar names across departments (e.g. following a company merger or acquisition). Where this is the case make sure this is captured and documented for both IT and customers and not simply ignored. Regardless, try to ensure that all services are viewed from a non- technical viewpoint to form a ‘customer friendly’ catalogue name. IT organisations must define IT services in a language that consumers can understand.
Clear naming will aid clear definition of the services in the service catalogue later and provides a sound foundation for appropriate SLAs.
Using the generated list of services, look for relationships to form into service suites or bundles. For example, Desktop Management services could include the PC or laptop – installations, moves and changes; whilst Professional services could include consultancy, project management and training. Review any existing service structure and either validate or challenge the services recorded and the logical service bundles that form the hierarchy.
Combining services into suites helps providers communicate with customers, manage the demand and report cost at a service group basis.
Remember each service catalogue is different; a service may appear under a high level group in one organisation but in a completely different group in another. There is no right or wrong way of grouping or separating these; only what feels right for your organisation.
Experience has shown that it is a good idea to go over this step again after a period of reflection as viewpoints change. An iterative review ensures better data capture of services and agreed bundling, thus preventing time consuming revisions later. Document the outcome from workshops, finally ensuring the level of detail does not include the technical details of the service at this stage.
Finally provide a detailed description of each service. This description should be easy to read and written in a non-technical manner. A further step could include defining the service offerings within the service family structure (e.g. Provide PC, Move PC, and Recover PC).
6. Consumers and owners
Having identified services and classified them into bundles we now need to consider who consumes them and who owns them. Are the services universal for all customers or do they differ by user group? Who is accountable for their supply?
This step focuses on mapping the recorded services from the previous step to the existing customer population, providing IT with an understanding of service demand and an opportunity to validate all of the services actually being used. Any unused services revealed are altered or decommissioned.
Identify all service consumer/user groups and any sub user groups. Create a service summary sheet as a checklist of services and user groups. Plot these user groups against the services previously identified; this is particularly helpful when all services are not uniform across the organisation or services are delivered to different customers.
Validate the service summary with key stakeholders within the user community to ensure completeness before ‘sign-off’.
The information gained can prove invaluable to IT to attribute costs to relevant business units. Regardless if this is applied for chargeback, it will prove useful in demonstrating the cost versus value of IT in business relationship discussions.
Finally, identify service stakeholders within IT (e.g., service owners, suppliers, Service Desk) who will be accountable for the services or at least consulted in the event of any changes.
7. Format and population
What does a service catalogue look like? Earlier steps would have decided the purpose of the service catalogue and this will largely guide your response to the format.
Basically, it can look like anything you want. Many service catalogue’s start life as a matrix, table or spreadsheet. It can be either rich in detail or simply provide a top-level explanation of services.
Using a service catalogue has become increasingly common practice as service providers move towards holding SLAs and service catalogues online, often on an intranet service. As discussed in The Service Catalogue, Part 1 – Why Have One?, it can be used to hold the generic elements of SLAs thus preventing repetition and reducing the SLA maintenance overhead.
If service catalogues are held online, it also means the information about the service is readily available to both the service provider and customers.
Explore and choose a template style and customise it for your organisation.
Next identify and clearly articulate the IT service characteristic titles, or attributes that you want to record. Typical characteristic titles include:
- Service name
- Service description
- Hours of availability
- Performance level
- Who to call if you need support
- Service owner
- Continuity arrangements
- Ordering and request processes
- Prices (if you charge for services)
- ….. some photographs!!
The above list is not exhaustive and your characteristics will depend on the level of detail required by your organisation. Be careful to choose only those that are meaningful – I have witnessed service catalogues with extreme levels of detail that no one refers to, thus becoming either a valueless overhead to maintain or too complex for anyone to use.
Having agreed a format you now need to populate the catalogue with details of the services identified earlier. Identify the characteristics of each service and any variants (if applicable) for different user groups.
Depending on the number of services being recorded and the availability of data, this process could require considerable effort therefore allow sufficient time in project planning. Full information may not be available until the next step is undertaken thus preventing full population at this stage. If this is the case, it is recommended that you start with the most popular or most critical services, completing these first will gain creditability with sponsors/stakeholders and help to maintain project momentum.
8. Service decomposition
What has been encouraged up to now is to consider services from the business view and to describe the components in a ‘top down’ direction. The inclination in the past has often been to build the service catalogue from the IT ‘bottom up’ viewpoint. The inference is that in the past service has been driven by what is technically possible rather than what the business requires.
Having obtained a clear picture of the business services and high level IT services, it is now necessary to review the supporting environment to include current strategies, processes, roles, technologies and contracts. We need to map the IT sub systems to IT services and map components to the sub systems.
Reviewing processes will help identify applications and hardware used in the provision of those services. These individual technologies, physical products and platforms are the enablers of an IT service.
A good approach is to build a technical hierarchy of how each service is provided; in other words define the IT service ‘supply chain’. Define the technical layers and select services from the service catalogue to decompose into sub-services and components.
- Map the IT sub systems to IT services
- Map components to the sub systems
Document sub-service components so they can be combined and re-used to support multiple, higher-level, customer-facing services, but don’t publish these sub-service components. Customers don’t need to know what makes up the IT service, therefore keep this IT technical catalogue as a subset of the service catalogue that is invisible to the customer.
This step ensures that the dependent services, processes or vendor lead times are accounted for and an assessment made on IT’s ability to maintain business services. It provides the foundation for the development or review of Underpinning Contracts (UCs), Operational Level Agreements (OLAs) and Service Level Agreements (SLAs), plus planning the monitoring capabilities, e.g. tools and techniques.
Where OLAs are applicable but not yet in existence they can be established through the development of a clear picture of a given service and its interdependencies. Once the OLAs are established, internal metrics for a given service can be captured to establish SLAs.
This step also establishes the cost of services; vital if this was part of the ‘buy-in’ step and any business case reporting associated with the project. It establishes appropriate pricing for available services based on the level of service being delivered.
Finally, be careful about the level of detail you include on the technical specifics of the service. Think of describing the technical specification of the service to a person who does not have a very good understanding of IT.
The service catalogue will represent a change for some or be something completely new! For example, service names may have changed due to consensus reaching. It is important to handle these changes and feedback through engagement and not through edict to ensure buy-in and prevent barriers to the service catalogue implementation.
Build a service catalogue communication plan (who needs to be informed? what format? when?) and develop communication materials as appropriate (e.g. presentation, 1:1 notes, email, desk drop leaflets, Q&A).
Consider a ‘dry run’ or pilot distribution of the new service catalogue, perhaps internally within IT. Review it to ensure that it is clear and easy to understand. Close any gaps and eliminate ambiguities.
Publish to the business under Change Management control and solicit feedback about its contents. Use the exercise for engaging the business and demonstrating your commitment to meet their needs.
If not already established you will also be able to use your service catalogue as the starting point for formalising internal OLAs as well as SLAs with customers. You can also use your SLAs to drive vendor agreements and UCs.
Finalise roll-out and run the service catalogue process as part of Service Level Management, which should include definition of the roles involved, e.g. service catalogue owner, Business Relationship Manager and Service Owner.
Process ownership comes with the responsibility to mitigate the risks associated with the provision of the newly implemented and accurate service catalogue, such as:
- Inaccuracy of the data in the service catalogue and it not being under rigorous change control
- Poor acceptance of the service catalogue and its usage in all operational processes. The more active the catalogue is, the more likely it is to be accurate in its content
- Inaccuracy of information received from the business and IT with regard to service information
- The inadequacy of tools and/or resources required to maintain the information
- Poor access to accurate Change Management information and processes
- Poor access to, and support of, appropriate and up-to-date CMS and SKMS
- Circumvention of the use of the service catalogue
- Information being either too detailed to maintain accurately or at too high a level to be of any value.
Final implementation includes an ongoing (perhaps quarterly) process for validating the service catalogue services and a yearly process to validate service catalogue structure and attributes. It is worth noting that the relative importance of services and service offerings may change over time, as will the business requirements and the technology supporting the services.
Having initiated the service catalogue consider using technology for improved efficiency and to help the definition, population and its ongoing maintenance.
So there you have it, your initial IT service catalogue! It does not have to be complex or very large. As time goes on you will refine it, expand it, and change it to meet the new needs of the business.
The IT organisation has to decide what purpose it wants the service catalogue to serve, and this decision will depend upon the IT department knowing its customers. It should list the services being provided, a summary of their characteristics and details of the customers and maintainers of each.
Points to remember:
- Run it as a project:
- Set realistic objectives and timescales
- Don’t aim for perfection
- Don’t underestimate the “thinking” time required
- Develop a policy of what is a service and how it is defined
- Start with a reasonable number of services and by focusing on the things IT does for most customers
- Reflect the customer’s viewpoint in how the services are described; avoid details they do not understand or value
- Form the services into a logical hierarchy
- Identify stakeholders, and set up the basic format
- Assess IT’s ability to maintain the identified services using existing data
- Populate the catalogue
- Develop actions for closing gaps
- Finalise and roll out the catalogue process
- Make sure you know your requirements before investigating automation tools
- Communicate, communicate, communicate!
Straightaway you will find the service catalogue improves communications with users, customers and within IT. This is the starting point to think about IT services versus technology and an important step toward improving maturity and business alignment.
Without documenting the services IT provides, you cannot negotiate SLAs with customers and it is very difficult to establish OLAs and drive UCs. So the logical starting point is indeed the initial service catalogue.
Want to speak to a Fox IT consultant today? Contact us now →