Building a service portfolio

Most IT service providers say they have a service catalogue and some even say that they have a service portfolio. But in reality, very few can actually tell the difference between the two.

This Case Study is a summary of the service portfolio implementation project at NNIT. The purpose of this is to give other IT organizations some practical tips on how to get started and also to describe some of the challenges, do’s and don’ts, and benefits accomplished during and after the project.

Background

NNIT was created as the internal IT department of Novo Nordisk, a multi-national pharmaceutical company, but it has grown to become one of Denmark’s leading IT service providers. It now provides a wide range of IT services to customers using fully integrated international delivery capabilities.

During a decade of rapid growth, new offices, customers, services, and technologies were regularly introduced into the business. In 2010 the management team of the IT operations division (ITOS) decided to prioritize a project named The Spinal Cord of Operations. The project charter included the implementation of a service portfolio and a service catalogue. The expected outcomes were:

• One central overview of services
• Minimum variation in services and agreements
• Anchoring of service ownership and responsibility
• Clear relations between services
• A transparent cost model
• Strategic development of services.

In 2010 the concept of a service portfolio was rather new and very unclear for everyone. NNIT hired ITSM consultants from a Danish ITSM consultancy company (CFN People) to help define the project scope and approach.

From 'Computer Geek' to Professional IT Service Partner

The transformation from being an internal IT department to being an external IT service provider was a huge change for many employees at NNIT, especially those who had been with the company for many years. NNIT’s customer portfolio had expanded heavily and most teams delivered services to multiple customers from various industries, all with different needs and expectations. The need for standardization, scalability, and transparency was bigger than ever. But implementing a service portfolio alone would not solve this. It also required a change of mindset: a new service-oriented culture.

As in most IT organizations the majority of the employees in ITOS were (and are) technical people. Have you ever tried to ask a technician what service they provide and what value it brings to the customer, or what outcomes it facilitates? If you have, then you probably also know the answer to these questions. Technicians can talk for hours about technology and IT components, and some of them might even be able to give you a full list of activities that they do in their department. But identifying the IT service and expressing the value created was a big challenge.

So it became very clear for the project team that organizational change management was a must and a prerequisite for the success of the project.

Before starting up the actual work in identifying, structuring, and describing the services for the service portfolio, several workshops were set up in order to train people in knowing the required terms: IT service, utility/warranty, service level objectives, service packages, service portfolio, service catalogue, etc. In short, we needed to implement a common service language! The ambition was that, when populating the service portfolio for the first time, we had the following mindset:

• We are IT professionals with knowledge of what our service does for our customer(s);
• We develop our services in alignment with customer needs and challenges; and
• At the same time we maintain our values and flexibility (something we knew our customers liked about us).

The Benefits of a Service Portfolio

Since inception, the NNIT service portfolio has expanded over the years to also include services managed by teams outside ITOS. The solutions division working with application management services also initiated a project to incorporate their services into the same framework. The lessons learned in ITOS made their implementation much easier, especially the part related to the standard service catalogue, where the templates had been continuously improved to fit the needs of both our internal and external target groups.

After looking back at the expected outcomes and evaluating the results, we can confirm that we did accomplish most of them.

The establishment of the service portfolio and thereby the single source of information on approved services and service descriptions combined with the transparent cost models has made the creation of new proposals and agreements much easier for presales, bid office, and account management. For ITOS on the other hand this has been a big step in the right direction towards scalability and standardization of services. Starting with the same foundation through the standard service catalogue has given us less variation between the agreements, even though the organization today serves more customers than ever.

Another area where NNIT has really benefited from the service portfolio is the integration with other corporate systems. The service portfolio has made cross-referencing much easier. The same service entity created in the service portfolio with a unique ID and name has been transferred across systems for sales, invoicing, time registration, KPI reporting, resource allocation, service support, etc. This has made it easier to obtain data and knowledge across the organization when measuring performance and efficiency. The service dimension is built into management reports used for several purposes within NNIT. So the aspiration of The Spinal Cord of Operations has been fulfilled.

Together with the consultants from CFN People the project team at NNIT established an overall project plan for the service portfolio implementation. The plan included four different tracks:

1. Design of the service portfolio framework
   • Establishment of a service portfolio structure
   • Establishment of templates, for example the service plan and service catalogue
2. Identifying, structuring, and describing IT services
   • Population of the service portfolio
   • Establishment of service catalogues
3. Service governance and processes
   • Service governance (establishment of roles and responsibilities)
   • Service portfolio management, including strategic development of IT services
   • Service catalogue management
   • Financial management of IT services
4. Organizational change management

As the project would have an impact on almost all delivery teams in ITOS it was decided to run a pilot in one department before going out to others, one service area at a time. This proved to be a very clever approach as the pre-defined design and structure of the service portfolio was challenged several times during the workshops. This meant that during the adoption, it gradually transformed into a service portfolio framework which was adjusted to fit the NNIT business and operating model.

The project was categorized as a must-win battle in the organization which meant high management attention and expectations. The adoption was planned to be over nine months, something we later realized was a very ambitious goal!

Before starting to collect all data into one single system, the project team had to assess what service information was needed and how it should be structured. An approach that is very similar to designing a configuration management database (CMDB). The overall design requirements included the following aspects:

• Service (name, ID, owner, functional area)
• The service lifecycle structure (idea, analysis, design, realization, retirement)
• The service type/data model (line of service, business service/infrastructure services, service package, supporting services, enhancing services)
• A service catalogue template
• A service plan template.

Tool selection

With the above requirements in mind we contacted several vendors of ITSM systems and other IT organizations in and outside Denmark. But every time, we were presented with tools to manage service request catalogues, which wasn’t what we were after. In 2010, no ITSM tool had functionalities to support the management of a service portfolio. Therefore, the quick decision was to start with a simple SharePoint repository and some Microsoft Word templates, and then later we could look for a tool.

However, we realized that we could build our own service portfolio system with our in-house SharePoint developers and very creative service portfolio managers.

Today, NNITs service portfolio system is still based on SharePoint functionalities.

The service catalogue(s) are produced in structured Word documents and stored inside the service portfolio system. For our customers, the catalogues are published through the customer portals and the request catalogues built into the ITSM system.

The Service Type/Data Model

Deciding on how to categorize and structure different levels of IT service was one of the most complicated activities for the project team. The initial model was built true to the ITIL® definition of service types and supported both bundling and unbundling of services in various ways. Services could be supporting, enhancing, enabling for other services and combined in service packages. The central component was the service package describing an actual delivery. This definition still holds true today, but the road to getting there was very different to what we imagined. The original concept of the service package was based on the ITIL definitions and centred around a capability of being able to build almost any kind of service a customer wanted through the use of standard service components.

As a theoretical exercise, this made a lot of sense and the workshops produced an enormous amount of services and packages. In the next chapter the experiences from identifying, structuring and describing the services goes into greater detail on the learnings we made. In the initial service model a service could look something like Figure 3.1.

Before starting to collect all data into one single system, the project team had to assess what service information was needed and how it should be structured. An approach that is very similar to designing a configuration management database (CMDB). The overall design requirements included the following aspects:

• Service (name, ID, owner, functional area)
• The service lifecycle structure (idea, analysis, design, realization, retirement)
• The service type/data model (line of service, business service/infrastructure services, service package, supporting services, enhancing services)
• A service catalogue template
• A service plan template.

Tool selection

With the above requirements in mind we contacted several vendors of ITSM systems and other IT organizations in and outside Denmark. But every time, we were presented with tools to manage service request catalogues, which wasn’t what we were after. In 2010, no ITSM tool had functionalities to support the management of a service portfolio. Therefore, the quick decision was to start with a simple SharePoint repository and some Microsoft Word templates, and then later we could look for a tool.

However, we realized that we could build our own service portfolio system with our in-house SharePoint developers and very creative service portfolio managers.

Today, NNITs service portfolio system is still based on SharePoint functionalities.

The service catalogue(s) are produced in structured Word documents and stored inside the service portfolio system. For our customers, the catalogues are published through the customer portals and the request catalogues built into the ITSM system.

The Service Type/Data Model

Deciding on how to categorize and structure different levels of IT service was one of the most complicated activities for the project team. The initial model was built true to the ITIL® definition of service types and supported both bundling and unbundling of services in various ways. Services could be supporting, enhancing, enabling for other services and combined in service packages. The central component was the service package describing an actual delivery. This definition still holds true today, but the road to getting there was very different to what we imagined. The original concept of the service package was based on the ITIL definitions and centred around a capability of being able to build almost any kind of service a customer wanted through the use of standard service components.

As a theoretical exercise, this made a lot of sense and the workshops produced an enormous amount of services and packages. In the next chapter the experiences from identifying, structuring and describing the services goes into greater detail on the learnings we made. In the initial service model a service could look something like Figure 3.1.

From the beginning we put a lot of effort into explaining the differences in the various service types to our stakeholders. We discussed warranty vs utility, business vs IT services, and supporting vs enabling services.

The ambition with the initial service model was to be able to describe the full end-to-end delivery of a service to customer, as mentioned before it was to be The Spinal Cord of Operations. Although we knew this was ambitious we didn’t realize just how ambitious this goal was. What we attempted, more or less consciously, was to do a bottom-up discovery exercise for identifying services in a company that pretty much delivered any kind of IT service that exists. The smallest unit of service was the different service types that could be bundled to constitute a service package, being a delivery to a customer, internal or external. The idea was to be able to take a business service and then track all the different service packages that made up the total delivery, including all dependencies in the form of supporting and enabling services. We later realized that this was not possible given the varying levels of maturity within the different service areas.

The Service Catalogue Templates

Initially, the template for describing services was a semi-structured Microsoft Word document on which to put content, whether business-related, service-related or technical. After the first couple of iterations of publishing service catalogues (see section 4.4), we gained more knowledge about the type of information our stakeholders required. What we ended up with was a very structured template with various tables of predefined columns and content. This came to be known as the service contract terms (SCTs) which now in NNIT is known by pretty much everybody from the technicians to sales. These SCT’s have evolved over time as we gained input from the presales team, customers and of course our own IT specialists. In essence what we created was a data model for a service, complete with different tables and entities.

The Service Plan Templates

The template for describing how a service should be developed was called a service plan. Initially this was designed as an outside-in oriented template in PowerPoint, in which the service owner had to think about the market they operated in, what barriers of entry there could be, what they could develop as competitive advantages, etc. Most of our technicians had been promoted to management and this theory-heavy approach didn’t suit them.

The purpose of creating the service plan was also to encourage our service owners to be more proactive when developing their service. They were asked to contact our sales department and to gather information from the account plans that were created for each customer.

A few service owners were able to start-up with preparing the service plan, but for many others it was just too complex an exercise. However, at the same time we introduced how to register development initiatives in the service portfolio. This seemed to be a better approach for the service owners. The focus here was to describe the single development initiative and the business case for implementing it, a much more tangible task for both service owners and architects.

A new revised template was designed with a simpler structure but still with the same outside-in focus (what do the business and/or market want). Furthermore, the service plan became an integrated part of the business plans of the specific areas. So the business plan included the strategic goals of the services within the business area and the service portfolio became the placeholder for all the service development initiatives underpinning the business plan.

Before the actual service portfolio work started a lot of time was spent on identifying what ITOS had in terms of services. The next chapter describes the three-step process involved in identifying what constituted service deliveries, how these could be structured into packages and how they, in turn, were to be described.

The project was initiated by introducing every team in ITOS to the framework, terminology and the expected assignments. Technicians were appointed as service architects and given the responsibility of eventually populating the service portfolio. Service packages needed to be identified, structured and described.

In theory, populating a service portfolio has to be done through an ‘outside-in’ approach. Find out what your customers want, how you can add value to their business, and then identify and define the services you provide. This was definitely the aim with the NNIT service portfolio and the purpose of implementing the new service portfolio management (SPM) process in the organization; to ensure that our services were aligned with customer needs and expectations. However, one of the primary goals for the implementation project was also to create a single overview of all services provided. As NNIT already provided IT services to several customers and had done so for over a decade, the initial population of the service portfolio needed to be an internal scanning of our current business. We needed to involve every single department in ITOS to be able to capture and log every piece of a service. The intention was initially to identify all the minor building blocks and afterwards put them together in different shapes that in the end would correspond to the service packages, in line with the service model that had been designed. This bottom-up approach was phased into:

• identifying service components
• structuring them into service packages and services
• describing them through a set of templates.

Identify services

The identification of services and service packages was done through simple workshops with the different teams. Each participant was given a pad of post-it notes and asked to write down what they would identify as a service in their area. The facilitator started to group the notes as they were presented, until we were able to identify the scope of the potential service packages. One of the primary observations from these workshops was that very often activities conducted as part of a service were confused with the service packages. To give an example: in several workshops related to the operation of servers and databases, patch management was often identified as an independent service package. It is not a service package. It is an activity required for the operation of a server, an activity that can be identified and used as a cost driver when identifying the cost of a given service package (see section 5.4 Financial management of services).

As more and more workshops were held, the number of service packages started to grow. It soon became apparent that we were building more than just a portfolio overview of services and that the lack of a common understanding of what a service was made of, made it hard to clearly define service packages of a similar nature. This became evident when we asked the technicians to describe the utility and warranty of the services they had identified through the workshops, which is explained in more detail in the next two sections.

Structure services

Once service packages within a given area had been identified, the next step for the appointed service architect was to register the service and service packages in the service portfolio repository, and to start describing the details by using the predefined templates.

With all the new services being logged in the service portfolio, the need for grouping these on a higher level became evident. The lines of service slowly evolved as a categorization of NNITs services into outcome-based and business logical groups. These groupings are today used both in terms of easing the usage and communication of the portfolio and service catalogue for NNIT employees, and more importantly to ensure that services within a line of service are developed coherently and in line with how the market for these types of IT services are evolving.

The figure below gives an overview of NNIT’s lines of service. The horizontal blocks are part of what we call the service stack, whereas services in the vertical blocks are where you find the supporting services.

However, in the process of structuring services yet another time-consuming activity had been initiated. When describing and scoping a service package, the relations (or more importantly the dependencies) to other services suddenly became more significant than ever. Now that services were being described, included in service catalogues, and subsequently should be able to be used directly in customer contracts, it became very important to validate the promises (service warranties) to the customers.

The architects started making demands of each other. They challenged the already defined service packages from other areas, both in terms of their structure and their utility and warranty. Some departments initiated the development of operational level agreements (OLAs) between different teams, a positive side effect that had not been part of the project plan. Looking back, more emphasis should have been placed on the OLA concept as the maturity of the different teams was very different. This led to a lot of different types of service packages being defined, each at a different level of maturity. It made it hard to get teams to agree on the content and the conditions under which deliveries were to be made. This would have been easier to capture in an OLA instead of a standardized service template.

The below figure is a real example from the database team. They had defined a service package named MS-SQL Database Pool which could be included as a predefined building block to any business service. The figure shows the complexity for the service architect. In order to provide a database pool, the team were depending on others for the operation of a server to host the database hotel (a shared infrastructure for hosting databases), which again was dependent on storage and network services.

The task of structuring and relating services began to be a serious threat to the project timeline.

What we had started to build was, in essence, a paper configuration management database (we tried to build relationships between services through Word documents rather than using a relational system) for all technical components and with no tool support other than SharePoint lists. The service model had become so complex that it only made sense to the technicians that had built them, and then only for their own part. With only two months to go-live, the project team had to change strategy. Our management did not only expect the internal service portfolio described and modelled, they also expected the launch of a service catalogue. It was time for the outside-in approach.

Describe services

The focus changed for the service owners and architects to less effort on internal details and clearer deadlines for handing in descriptions for the service catalogue. However, the attention on service packages was still very high as these were in scope for both the subsequent costing of services and also for the description of the different variants of a service in the service catalogue.

The service descriptions started rolling in to the project team. An iterative process of describing, reviewing, and updating began to take place. The predefined templates ensured some consistency throughout the catalogue in terms of layout, naming conventions and high-level structure and it helped the service architects to fulfil the task in a structured way.

The challenge for the project team was to find the resources for reviewing the documents. As most descriptions were prepared by technicians, the first draft included too many technical terms and too little information about why and how the service added value to the customer’s business.

Representatives for the customers were found in the sales organization – account managers, presales people and our bid office team were contacted to review the descriptions according to the below criteria:

• Is the text understandable and relevant for customers?
• Have we captured all the required information?
• Do the descriptions fit in to the context of our contracts?

Finally, our service catalogue (version one) was published with a delay of three months. It included a total of 600 pages; with descriptions of over 60 business service descriptions and several hundreds of predefined service packages. Our management team was satisfied and our colleagues outside the ITOS division were impressed. The application management teams copied the framework and initiated a similar project.

Only a few weeks after go-live an important finding emerged: one-size does not fit all! A 600-page catalogue is something you put on your book shelf but it is not simple to use and definitely not operational, a true dust-collector!

Despite our revised outside-in strategy, we had been too busy launching our service catalogue and forgot to ask the simple questions: who, why and what. Who will read our service catalogue (target group), why do they need the service descriptions (purpose), and what information is relevant for them (structure).

When the project was initiated, ITIL was still at Version 3 and the concept of different types of service catalogues had not been introduced. One service definition challenge that emerged early was the fact that service owners were providing highly technical IT services to customers, and as such they were in fact delivering a business service. This added to the complexity of the service model and introduced the requirement for different types of service catalogues in different contexts, but also helped in the understanding of what a service actually was in NNIT.

We knew we had the foundation of something good, but we still needed to focus even more on the service part of the IT deliveries. To do this we went back and looked at all the descriptions we had gathered and put in our catalogue. The template for the service descriptions had been pretty loose, composed more or less of a business description (which was always very technical), a service description (which was also very technical) and some package descriptions (which were highly technical). So we had ended up with a lot of technical descriptions, describing everything from activities, utility, warranty, restrictions, prerequisites, dependencies, metrics and targets, service requests and more. All more or less randomly thrown into the documents depending on who wrote it.

A service catalogue re-design initiative was needed!

The new service catalogue structure

The first edition of our service catalogue clearly showed us that we needed to work with different levels of service descriptions. To make the catalogue as relevant as possible for each target group we needed to break it down into comprehensive entities.

In 2012, the new service catalogue re-design project was initiated. Through workshops and meetings with stakeholders we started to collect the answers to the who, why and what. Please see Table 4.1.

The revised structure of the service catalogue is shown below:

.The service delivery model

Already during the establishment of the first edition of the service catalogue the project team had identified information that was frequently repeated from one service description to the other. Most often the recurring text was related to general information about NNIT and the standards that were followed when entering an agreement with us. Here are some examples:

• The interaction levels with the customer (functions, roles, communication structure, etc.)
• Basic supporting services: service desk, service monitoring, access management, security services, service reporting, etc.
• Standard ‘high-level’ description on some basic ITSM processes (for example how do we manage incidents, service requests, changes?)

All these elements were excluded from the individual service description and instead presented in one single document that served as introduction to the service catalogues: ‘The Standard Service Delivery Model’.

 

Service Governance Model

Anchoring of service ownership and responsibility was not only one of the expected outcomes from the SPM implementation project. It was also a prerequisite for bringing the service portfolio to life. Roles and responsibilities had to be defined, described and assigned to specific employees.

These employees were the key resources during the implementation and were allocated to the project from the beginning.

Up until 2010, being a manager in ITOS included responsibilities required for managing and developing a department: its employees, business plans and financials. With the service portfolio implementation, some of the managers also had the service dimension added to their job description. Appointing service owners for each service in the portfolio ensured clear accountability for development, design, operation, and costing of the service as well as providing a single point of contact for commercial/contractual escalations.

The responsibilities of a service owner at NNIT are defined throughout different ITSM processes covering the entire service lifecycle, including:

• Strategic development with focus on customer demands, service optimization and standardization
• Design of reliable and cost effective services
• Operation and support of services according to customer expectations
• Ensuring adequately allocated resources and capabilities for the provisioning of the service.

Table 5.1 describes the responsibilities related to service portfolio and catalogue management processes.

The key roles defined for the service portfolio and catalogue processes are:

The Service Portfolio Management Process

Once the service portfolio framework and the roles and responsibilities were established, it was time to define the process for managing the services through the portfolio. Over the years, the portfolio managers have updated the process to be aligned with the current NNIT business model, based on their experience from working and developing the portfolio and from interacting with the service owners, architects and senior management.

5.2.1 The Service Development and Lifecycle Management model

Today, the NNIT service portfolio management process includes a step-by-step description of how to move services through the service development and lifecycle management model (see Figure 5.1 below).

For each phase in the service development and lifecycle management model, the process describes:

• What activities needs to be performed before entering the next gate
• Who is responsible for performing the activities
• What are the gate criteria (required documentation)
• What needs to be approved and by whom.

The approval of investments related to service development also changed during the years. Before the implementation of the service portfolio in 2010, services were being developed locally in the different business areas and the management team in ITOS had no overview of investments made across the organization. Therefore, it was decided that every service development initiative should be logged in the service portfolio and presented with a detailed business case at a quarterly management review meeting. The initiatives were evaluated and prioritized by ITOS management and the approved cases were granted funding to proceed with the service development activities.

Today, the management review and prioritization is made through the ITOS Business Development Board, a board that consists of representatives from ITOS management, marketing and the technology office. Having representatives outside the ITOS division ensures prioritization and development of innovative services that are aligned with the NNIT corporate strategy and market/customer demands.

However, the approval rules now also allow service development initiatives with a total estimate of up to 150 hours to be approved by the local Vice President responsible for the functional area.

Everything above the 150 hours has to go through the ITOS Business Development Board.

The yearly service portfolio management review

Once a year, the service portfolio management function initiates a general review of the entire service portfolio. All service owners are contacted and asked to review and ensure that all portfolio data related to their service(s) is relevant and up-to-date. This is performed at the same time as the yearly review of the descriptions in the standard service catalogue.

Service Catalogue Management Process

The service catalogue management process describes the different levels of service catalogues in NNIT:

• The standard service catalogue
• The customer service catalogue(s)
• The service request catalogue(s).

The ownership of the standard service catalogue is anchored in the service portfolio management function, which includes responsibility for ensuring that no new service is published unless it has passed the gate to the design phase of the service development and lifecycle management model.

The customer service catalogue and the service request catalogue are owned and managed by the service catalogue manager. This is often a role within the service delivery management function where the responsibility of end-to-end service provisioning toward a specific customer lies. However, as with the standard service catalogue, the service descriptions are subject to internal sign-off from the service owner before being communicated or published to the customers.

The service catalogue management process defines the activities related to the implementation and maintenance of the service catalogue contents at all three levels. It includes guidelines for how to describe the services and how to maintain and communicate the information to the relevant target group.

Financial Management Services

Until 2010, the budgeting and costing of IT services in ITOS was done locally in each business area. Every department had their own ‘cigar box’ (ring-fenced budget) and their own spreadsheets for managing their cost. Our presales department, who was responsible for pricing new agreements, was challenged by the missing transparency across services. If a contract included more than one service area (which most of them did), the ability to get commitment or sign-off for the total cost was very difficult. Therefore, every single new agreement (small or large) ended up at ITOS management for final approval.

Financial management of services was considered a very important aspect of the service portfolio implementation project. However, it was never the intention that the financial information should be part of the portfolio itself, instead output from the portfolio in the form of the approved service packages should be the input to the activity-based costing process.

The ITSM project team stepped aside and a team of controllers from the NNIT finance department took over the dialogue with the service owners when the services had to be costed. The basic task was to identify the activities and resources that went into the delivery of each service package and match these to a set of predefined cost drivers. Initially this seemed like a straightforward assignment. All financial calculations were to be logged into one single system that was managed by finance. As a result, both management and presales should be able to get the information to look at the whole picture when costing new agreements or when creating the budgets for the following year.

Running two projects around the same concept of a service proved to be a much greater challenge than we could imagine. It turned out the language around services evolved into two different dialects, one for IT services and one for the financial aspects. Service and service package meant one thing for the service portfolio team and another for the financial team. Looking back this was a result of the finance team trying to figure out the cost of service packages, always trying to break down the package into its cost drivers, while the ITSM team was busy trying to convert and merge service packages into something meaningful in terms of utility and warranty.

In addition to the finance team and the ITSM team trying to agree on the notion of a service package that could be described in terms of cost drivers, the presales team need a combination of both cost drivers and price drivers. In short they needed to know both what cost elements went into a service and how these should be translated into an actual offer to a client. This introduced an additional level of complexity into how the services were described, valued, and ultimately priced. In the end the service contract terms were modified to contain the price drivers of a service while the financial costing system contained the cost drivers. The common denominator for both systems was the service and the service package.

Having the concept of a service transferred to multiple corporate systems was a major challenge when working with services from both an ITSM and a cost perspective.

In order to get meaningful numbers around the financial drivers concerning the development and delivery of services, both the main financial system, the sales system, and the system for time registration had to adopt the notion of a service as a unit of measure in some shape or form. This was done in various stages, leading to different definitions of what constituted a service. Besides the obvious technical issues of aligning systems, the challenge also turned out to be how to find the correct level of what constituted a service, e.g. making a service specific enough so that it makes sense for all stakeholders. In essence you need to find a one-size-fits-all in terms of how you define a service in each system and for each business process. The benefit of doing this was that everybody started talking about the same thing, a service in one system was also a service of the same type in another system, so presale could talk to finance who could talk to the service owners and they all discussed the same thing. This was the first sign that the spinal cord concept was actually a reality.

In the end, we believe the required integration to other systems helped in defining what a service was and that it was actually a requirement in order for the service concept to be fully adopted in the organization. Without the integration requirements, we would most likely have found a different definition of what constitutes a service, leading them to either being too specific or too generic and most definitely the service would not have been tightly integrated into the everyday life of the people who sold or delivered the service.

Ensure management commitment and dedicated resource

The cost of implementing and managing the service portfolio in NNIT has been enormous. Over the years, thousands of hours have been spent not only on defining, describing, and developing services but also on managing, improving, and expanding the framework. The provisioning of IT services is the core business for NNIT and working with the service portfolio in a growing IT business environment is not only a necessity, it is an investment in business development. A discipline similar to what manufacturing companies would spend on product development (R&D).

Having dedicated roles and functions in-house is a must for the viability of the service portfolio. External consultants can facilitate the implementation and help you get started but bringing the service portfolio to life, keeping it alive, and enforcing the sense of ownership for continuously improving IT services requires allocation of people within the organization. It is much more than just the implementation project.

Accept the fact that it takes time and resources to implement and maintain a service portfolio!

Create a common service language

Do not underestimate the need for organizational change management when implementing a service portfolio and catalogue. Very often ITSM adoption projects are conducted by trained ITSM professionals who are familiar with the terms and phrases used in ITIL. Do not expect the same maturity level in the rest of the organization. As services were to be defined, structured, and described by appointed service owners and architects from different areas in ITOS, a common service language was needed. A vocabulary of terms was created including an explanation of the terms service, service package, utility and warranty, service level objective, etc. One of the most complicated issues was to explain the difference between the service portfolio and the catalogue.

The ITIL framework acts as a very good starting point for creating your language around services, but it needs to be adapted and modified to reflect the culture in your organization as well as the clients you have, being internal, external or both. Just try asking around in your own organization what an IT service is, you will most likely be surprised at the diversity of responses you will get.

Start simple and make it relevant

One of the initial mistakes made by the project team was starting with a high level of complexity in the initial service portfolio design. As service types/data model, lifecycle phases, service catalogue and service plan templates were prepared with inspiration from ITIL or other frameworks, methodologies or philosophies found through Best Practice frameworks the approach sometimes became very academic for our colleagues. During the implementation the design was gradually scoped down and made simple, for example by evaluating what information was needed or what structure made sense. If we had made this evaluation from the beginning we would have saved lots of time. So limit your requirements to a minimum, as the ITIL Practitioner guiding principle keep it simple recommends (ensure everyone can understand and relate to the concept) and once you have the basics in place, then start planning for improving and expanding.

Nelli Serifovski has more than 15 years of experience working within different fields of IT service management. Her career as an ITSM professional and passion for ITIL Best Practice started in 2002 with the responsibility of preparing service level agreements and service catalogues for a major client at NNIT. In 2009 she became a certified ITIL Expert.

Since 2010 Nelli has been a part of the Process Design team at NNIT: a centralized function with the responsibility of implementing and developing service management processes across the company.

She was the process owner for the service portfolio and catalogue management processes at NNIT during the implementation, and has since been the driving force behind building service request catalogues. Nelli Serifovski participates very often as speaker at different conferences and other ITSM events. Her presentations are based on practical experience from different ITSM implementation projects.

Niels Skytte works with building IT performance measurements solutions centred around the ITSM domain as a partner in Venzo Analytics, working with making sense of all the data from the major ITSM vendors and translating it into meaningful metrics. He has worked in the intersection of IT Operation and service management for over ten years as both an operation specialist in various server technologies as well as an ITSM process specialist, drawing from experiences with ITIL, COBIT and various maturity frameworks.

He worked at NNIT from 2010 to 2014 as one of the two service portfolio managers tasked with implementing the service portfolio. His main focus area was the development of the service contract terms framework and he was the main architect and developer on the SharePoint-based service portfolio solution.

Niels is a member of the publications committee of itSMF Denmark.

IT advisory, development and outsourcing We are passionate people building winning teams with our customers. With deep roots in the pharmaceutical industry, we supply services that meet the highest requirements for quality, security and standardization.

NNIT is one of Denmark’s leading consultancies in IT development, implementation and operations. For over a decade, we have applied the latest advances in technology to make software development, business processes and communication significantly more effective.

NNIT’s services include advising, building, implementing, managing and supporting IT solutions and operating IT systems for customers.

Today, NNIT has more than 2,500 employees, with around 900 of them based outside Denmark, in China, the Czech Republic, the Philippines, Switzerland, and in the US.

For more information please visit www.nnit.com.

The IT Service Management Forum is the only truly independent and internationally recognized forum for IT Service Management professionals worldwide.

This not-for-profit organization is a prominent player in the on-going development and promotion of IT Service Management Best Practice, standards and qualifications and has been since 1991. The Danish chapter was established in 2003 and is today amongst the most active chapters both locally and in an international context involved in activities with Axelos, ISO and other stakeholders within ITSM.