ITIL Interview Questions and Answers

Introduction

Information security is one of the most important topics in the present business scenario. With increasing usage of Information Technology in the day to day affairs of life and also the increasing competition in the business scenario, every business strives to keep its assets and intellectual property secure. People expect to be always connected requiring a constant flow of information in all directions and from all directions; people expect that Technology will enable them to do things that they cannot otherwise do comfortably. While this is a great thing to happen, it also exposes businesses to threats like getting hacked or other forms of loss of confidential information via phishing etc.

Information Security Technology has grown manifold in the past few years. Information security has become a topic of national and political interest and many countries are implementing legislation around information security. Information security officers are in high demand and command very good pay packages – making it a lucrative career option.

1. Why is Information Security important? Is it something optional?

Every business wants to conduct its business securely. Conducting business securely means protecting the intellectual property, providing a secured working environment to the employees and ensuring that the partners do not divulge any information that they may have access to via signing non-disclosure agreements.

Now, all businesses rely on IT to varying extents, and the business security must be extended to IT as well. In ITIL®, the goal of the Information Security Management (ISM) process is to align the IT security with business security and ensure that information security is managed in service and service management activities. In modern businesses, ISM is an important part of corporate governance, and has therefore, strategic importance. As a result, all ISM objectives are aligned with the business objectives and vice versa, and the management of information security risks is overseen by the company leadership. Although we are exploring ISM in the context of ITIL, it is not just something that is related to IT, it is very much a key aspect of doing business. It is a must-have, and not optional.

2. What are the typical security objectives of an organisation?

The following are some of the security objectives of an organization:

• Information is available and usable when required
• However, the information should be only available to those who need it, and who have the privileges to access that information. In other words, confidentiality should be maintained.
• The IT systems that provide the above information are secured – i.e. they can resist attacks
• The IT systems should be able to prevent failures or recover from failures should there be one. The systems should be available.
• The information should be complete, accurate and protected against modification. If the information is modified in error or maliciously, an audit log of the modification should be available. This is referred to as the integrity of data.
• All business transactions and information exchange between the stakeholders must be trustworthy. Communication channels must be secured.
• Business processes will define the priority of the confidentiality, integrity and availability aspects; the business objectives will drive this.

3. What is a security framework? Who defines this?

A security framework is an essential component of the Information Security Management (ISM) process and will generally consist of the following:

• An overarching Information Security policy
• Specific security policies that derive from the above, but is more specific to strategies, controls and regulation
• A set of security controls to support the above policies
• The Information Security Management System (ISMS) – these will contain the standards, guidelines and procedures for managing them
• Security strategy – closely interlinked with the business objectives
• A security organization – with roles, responsibilities and people mentioned therein
• A repository of the security risks and how these will be managed
• A communications plan for how the security topics shall be disseminated in the organization, including training and awareness sessions
• Finally, a monitoring framework to keep a tab on the status of compliance and the effectiveness of the security controls and communication plan

Providing a security framework is the responsibility of the executive management. They hold the final accountability for protecting the information related to the organization. Once the policy is framed, the security organization is tasked with ensuring compliance, and become the ‘guardians’ of the policy.

4. Have you heard of ISMS? Can you tell more about it?

ISMS is an acronym for Information Security Management System. The ISMS will contain the standards and guidelines that support the information security policies. The ISMS also provides the procedures on how these will be managed.

As a management system, the ISMS is a continuous cycle of Planning, Implementing, Evaluating and Maintaining of the standards and the guidelines.

As a part of the planning process, the Service Level Agreements (SLA), Operational Level Agreements (OLA), Underpinning Contracts must contain references to the security policy of the organisation wherever applicable.

As a first step of implementation, Security awareness must be created within the organization. Security must be implemented for the staff, networks, applications, end user computing devices. All assets must be registered and classified as per their sensitivity, and access to these must be controlled and monitored. Any breaches, i.e. security incidents must be reported and dealt with as per the procedures laid in the ISMS.

The next step, evaluation, is realized through conducting of internal and external audits, self-assessments and performing the causal analysis of security incidents.

Learnings at every stage of this continuous cycle must be used to maintain the ISMS and plan for more effective upholding of the security policy. These should be reported back to the stakeholders.

5. Do you have an Information Security Officer? What are his duties?

An Information Security Officer is referred to as an Information Security Manager as per ITIL terminology. The main duties or responsibilities of this role are as follows:

• They will assist in developing and subsequently maintaining the Information Security Policy
• They will create information security awareness in the organization through appropriate means, including training of personnel
• Classify the configuration items (CI) in terms of the levels of protection and control
• Perform risk management activities – like identify potential security risks and work on creating mitigation and contingency plans
• Manage all the security breaches by taking remedial action
• Analyse the security breaches and create an improvement plan for reducing the volumes of such incidents in the future
• Participate in the change management process by performing the security impact analysis of changes and provide estimates for any information security related changes
• Perform self-assessment security tests, conduct internal and external security audits
• Uphold the security clauses in the Service Level Agreements and discuss any breaches or changes with the customer
• Uphold the security clauses in the Operational Level Agreements and discuss any breaches or changes with the suppliers
• Keep the executive management informed about the latest industry developments in the information security

6. You have joined a new company as an Information Security Officer. You realize that assets are not classified. What would you do next?

As the Information Security Officer my first step would be to understand the configuration items (CI) and how these are maintained in the organization, i.e. the configuration management database (CMDB). With an up to date CMDB in place, the next step is to organise the information assets as per ISO 27001 standards that directly apply in the ITIL context: Confidential (only senior management have access); Restricted (most employees have access, likely on a ‘need to know’ basis); Internal (all employees have access) and Public (everyone has access).

Depending on the nature of the business, there may be other levels that may need to be created, e.g. in a medical institution, doctors may have access to patient information, but not necessarily how the finances of the hospital work; on the other hand, the top management may not have access to the patient records. These levels must be discussed and agreed with the executive management – and must be in line with the business objectives and the information security policy.

Classification of the information provides buckets into which assets are logically arranged. The next step is to design the exceptions and the approval mechanisms for the exceptions. Once this is done, access rights must be provided as per the information security policy.

In a business scenario, new information assets are created regularly. Therefore, the next step is to educate the creators of the assets on how the newly created assets must be classified. This is achieved via training.

Once the above setup is complete, self-assessments and audits must be regularly scheduled to check for compliance to the classification policy, usually, these will be a part of the wider security audits.

7. Have you heard about the GDPR? Can you give some details?

GDPR is an acronym for General Data Protection Regulation and is hailed as the toughest privacy and security law in the world. It was enforced on 25-May 2018 by the European Union (EU). However, this law imposes obligations onto organizations anywhere, so long as they target or collect data related to people in the EU; e.g. if you are an Indian IT company doing a project that involves data related to people in EU - you become accountable for compliance!

There are 6 principles of GDPR and a final accountability principle, making it a total of 7 principles:

1. Lawfulness, fairness and transparency — Processing must be lawful, fair, and transparent to the data subject.
2. Purpose limitation —You must process data for the legitimate purposes specified explicitly to the data subject when you collected it.
3. Data minimization —You should collect and process only as much data as necessary for the purposes specified.
4. Accuracy —You must keep personal data accurate and up to date.
5. Storage limitation —You may only store personally identifying data for as long as necessary for the specified purpose.
6. Integrity and confidentiality —Processing must be done in such a way as to ensure appropriate security, integrity, and confidentiality (e.g. by using encryption).
7. Accountability —The data controller is responsible for being able to demonstrate GDPRcompliance with all these principles.

An organization that violates the GDPR must cough up a lot of money as penalty. First, the data subjects are liable for being compensated for the damages as a result of the breach. Secondly, the data protection regulator in each EU country can slap a fine of up to 20 million euros or 4% of the global annual revenue of the organization in the previous financial year – whichever is higher. The amount varies with the severity of the breach.

Please visit the GDPR website for more details - https://gdpr.eu/what-is-gdpr/

8. Let me tell you 3 keywords – ‘Information Security’, ‘data protection’ and ‘privacy’? Are these same or different ?

'Privacy' and 'data protection' are very close in meaning, and the usage depends on the country. E.g. in the US, the term 'privacy' will be used in the context of the controls associated with the processing of personal data. In the European Union (EU), 'data protection' will mean the same thing. The difference may be ascribed to difficulty of making a translation to the multiple languages being used in the EU.

However, the situation with 'data protection' versus 'information security' is different. When an IT service provider or a website mentions about 'information security' being provided - it may mean that, e.g., they use encryption to transfer files so that only the sender and the recipient know the content being transmitted and no one else. But this may not protect the information related to the users themselves. E.g. to send a file, the sender needs to create a profile - how is the IT service provider dealing with the sender information? This is where data privacy (or data protection) comes in. It is a common wrong belief that an IT service provider promising 'information security' is also protecting the data of the users of the system. E.g. A few years back Yahoo declared that they were hacked in 2014 (a breach of 'information security') and user data for about half a billion users was stolen (a 'privacy' breach). This shows the difference between the two terms.

Note that 'privacy' and 'data protection' always refer to personal data, but 'information security' is different – it is more generic and ‘impersonal’.

9. What is the ISO:27001?

ISO 27001 (ISO/IEC 27001:2013) is a globally recognised information security standard that specifies how an organization can build a world-class information security management system (ISMS). It helps organisations manage their information security processes in line with best practice while controlling costs. Although it is related to information technology, it is technology agnostic and applies to all organisations - big or small. This universality has resulted in the standard being widely adopted across the globe.

ISO 27001 enables organisations to achieve accredited certification by an accredited certification body following the successful completion of an audit. It supports compliance with GDPR (General Data Protection Regulation) of the European Union.

Following are the controls that are offered by the standard:

• Information security policies
• Organisation of information security
• Human resources security
• Asset management
• Access control
• Cryptography
• Physical and environmental security
• Operational security
• Communications security
• System acquisition, development and maintenance
• Supplier relationships
• Information security incident management
• Information security aspects of business continuity management
• Compliance

10. Can a customer impose an SLA related to security? Can you give some examples?

Considering the nature of the business, the customer can always impose some service level agreements (SLA) related to Information Security. Examples include, but are not limited to:

• Restriction of physical access to the project area and server rooms
• Onboarding of a new project personnel happens only after Information Security training is completed and a Non-Disclosure Agreement (NDA) is signed
• Performing a background check on project personnel and submitting the report to the customer
• Periodically force reset of password, employ a strict password policy
• Scanning of the service provider’s networks and devices on an agreed schedule
• Restriction on the use of chat tools, mobile cameras
• Usage of customer provided proxy server for accessing the internet
• Installation of monitoring software on the project computers
• Keeping a record of all access requests
• Usage of a secure virtual private network and devices provided exclusively by the customer

Each of the above may be subject to audit periodically by the customer and any breach of the same may make the service provider liable to pay financial penalty. The amounts of the penalty and the conditions when it will be imposed are usually included in the contract along with other service level agreements, terms and conditions. With the introduction of strict security laws like the GDPR, customers are increasingly tightening the security requirements for the service providers.

Introduction

The supplier manager is a critical role in an IT services organisation. This is especially true because technology is advancing so fast that at any given point of time a service provider may not have enough technological capability to service a business, thereby necessitating an outsourcing scenario. A supplier manager has a mix of skills in an IT organisation - they must understand a bit of technology, possess good negotiation skills, and must have excellent interpersonal skills. Supplier managers must have high integrity and be able to do their work in the best interests of the organisation. While their job is to derive value from the amount spent on the supplier, they must also have the appropriate soft skills to ensure that suppliers engage as partners, as opposed to being pushed into a corner via hard negotiation.

1. What are the responsibilities of a Supplier Manager?

A supplier manager helps in the development and review of the contracts that the company has with suppliers. If there is more than one supplier for the company, the supplier manager must ensure that the supplier processes that are established with the suppliers are in line with organisational strategies. At any given point of time, the supplier manager maintains a supplier and contracts database; this could be a shared folder or a SharePoint location. Circumstances may require some of the supplier contracts to be modified – the supplier manager must ensure that all such changes are processed via the appropriate change control mechanism. One of the key things to change supplier contracts is the involvement of appropriate stakeholders, specifically senior management within the organisation as well as in the supplier organisation. As a part of the supplier and contracts database all the supplier information e.g. the names of the key persons, management representative for any escalations, contact details of all etc.are stored.

The most important job of the supplier manager is ensuring that the company gets the desired value from a supplier in terms of the deliverables that are expected of the supplier. From time to time, the supplier manager must also review the performance of the suppliers, document any changes required including a change of supplier, or at a minimum, issuing the supplier a warning. If a supply contract must be terminated, a process must be followed. E.g. adequate notice of termination must be provided, and any responsibilities of the supplier as a part of the termination process must be documented in the supplier contract. During the exit process, the supplier must be vigilant because an unhappy supplier could possibly leave behind loose ends that could result in the degradation of service afterwards.

2. As a supplier manager how would you deal with a multi-vendor situation?

A multi-vendor situation is always tricky.

A supplier manager must take care that the suppliers do not end up competing against one another, eventually making it their primary motive. In an outsourcing situation, suppliers may try to grab a bigger share of the work, pushed by their organisation targets; sales representatives are usually rewarded for bringing in more business into their companies. Therefore, getting a bigger share of the work is always high on their agenda; under this pressure, they try competing with the other vendors who work for you. There can also be incidents of non-cooperation between the suppliers resulting in a lack of communication, and this makes the overall service provisioning to your customer challenging for you.

While competition is one side of the coin, the other side is‘colluding’. This means that the suppliers unite with each other and decide on a resolution, for e.g. they may decide that they will not provide resources below a certain rate card, which could be higher than the industry average. In such a situation you will end up spending more than you had planned for. This could finally mean that you either don't make the necessary profits, or you are selling your services at a loss to the company.

There are many other ways in which a multi-vendor situation can go wrong, and therefore the supplier manager must constantly ensure that they take care in terms of the supplier relationships and strike a balance between making them collaborate with each other verses keeping them aloof.

3. Have you heard of the Supplier and Contract database? What is it?

The Suppliers and Contracts Database (SCD) is established as an integrated element of a more comprehensive Configuration Management system (CMS). The SCD should have all the details of the suppliers and the contracts that exist with the suppliers together with details of the type of services or products that are provided by that supplier and how these relate to the configuration items.

E.g. provisioning of laptops for the employees of a company may be with supplier X. This information must be stored in the SCD. Furthermore, details of the quantity of laptops, manufacturer, configuration of the laptops, lead time to provide laptops, whether laptop bags should be provided along with the laptops etc. must also be included. Supplier details such as single point of contact in the supplier organization, escalation path and contact details of the supplier manager, technical skills of the personnel who shall be installing software on the laptops may also be included in the SCD.

The SCD should store all the information and act as a single source of truth for all the supplier information in the company. Apart from the contract details for all suppliers, there should also be a mechanism to categorize the suppliers; how the organization plans to evaluate new suppliers, new contracts and how new suppliers can be on-boarded.

The evaluation mechanism is crucial to ensure that poor quality does not come in; the process should be adaptable to the changing business priorities of the organization, e.g. in a period of lean business, the focus in supplier selection may be on cost, but in a period of good business the focus may shift to choosing suppliers with niche capabilities. Failure to adapt might misalign the suppliers from the company objectives. Regular evaluation should be carried out for all the suppliers and this information should also be stored in the SCD.

Contract renewal and termination criteria should also be included in the SCD.

The SCD is constantly in use across the ITIL® lifecycle, through service design, service transition and service operations.

4. In your opinion what is the objective of the Supplier Management process?

The objective of the Supplier Management process is to manage suppliers and the services these suppliers provide. This is necessary to provide seamless IT services to the business, the users and the customers. At any point of time focus should be to ensure that the users of the business derives value for the money that is spent on IT. The Supplier Management process ensures that suppliers and their provided services can support the overall service levels that the business expects from the IT organization. The process promotes awareness of the business context of working with the suppliers and partners.

All ITIL service lifecycle phases must consider the process of Supplier Management with due importance and that the supplier manager is involved in all the stages, from strategy through design through transition and operation and finally to improve.

In the modern business scenario Supplier Management should be able to ensure that it has full control on the suppliers and can quickly re-align and motivate the supplier to the changing business needs of the organization without going too much into contractual discussions. Supplier flexibility is key to the survival of any business as it helps to mitigate the risks of the business organization when not having certain skills or capabilities.

The primary goal of the Supplier Management process remains to continuously derive value from the suppliers and the partners, often through a reward and penalty mechanism. Value will also be derived through partnering, maintaining continuous communication with suppliers and agility is maintained through having a pool of ‘preferred’ suppliers with whom Master Service Agreements are already in place.

5. What do you understand by supply strategy?

Strategy for an organization is devised during the Service Strategy phase of the ITIL® lifecycle.

The first step in defining supplier strategy is whether the nature of the business allows certain services or products to be sourced from outside of the company. Due to reasons of confidentiality, this may be a very controlled process where every product or service that is being sourced externally must pass through stringent quality checks, e.g. procured laptops may need to undergo ‘hardening’ to prevent hacks. When services are being sourced from a supplier, confidentiality and data protection requirements may necessitate that the supplier provide services through a secured network or even from a physically isolated and secured location.

Supplier strategy must also define what kind of services and products may be sourced from the suppliers. E.g. certain businesses may not allow the procurement of software product licenses directly from the software vendor due to the higher license costs; in such cases the company must go through license resellers.

For sourcing manpower from external agencies restrictions may apply too. E.g. a business may not want to hire staff from a provider that already supplies manpower to its competitor. In some situations, such as a project that requires staff to operate in the night shift, there may be restrictions on hiring women in certain countries due to cultural reasons.

While supplier strategy can be more generic and overarching there should still be room for tweaks so that certain limitations of a prospective supplier may also be overcome, therefore ensuring that the business does not miss out on procuring products or services of better quality from a good supplier.

Cost consciousness is one of the primary factors for supplier selection. Many businesses follow a linear approach of choosing the least expensive supplier. However, the supplier strategies also allow flexibility in terms of choosing quality of deliverables over price when dealing with certain niche skills or services.

A good supplier strategy is beneficial to the business. The management must spend a good amount of time in formulating this and utilize the learnings from the past.

6. What is the most important factor of a good supplier relationship?

A good supplier relationship has a centrepiece called ‘Trust’. Trust is intangible and needs time to materialize within a relationship. A customer-supplier relationship starts with the exchange of goods or services against money. Commitments are made and must be fulfilled. These commitments are mostly contractual, and subject to scrutiny and legal jurisdiction and may result in financial reward or penalty.

However, businesses do not run linearly where there are only simple transactions; doing business would then be quite easy. There are numerous examples where businesses make commitment to their customers based on what suppliers have committed to the business. E.g. consider a case when delivering your project will require having a niche skill on-board. One of your staffing vendors has agreed to provide you with qualified resources in a stipulated amount of time. You will rely on this commitment from your supplier to commit to the business about delivering the software at a certain milestone. If the supplier is unable to provide you a quality resource on time, then you are in deep trouble. This is when you lose faith on your supplier and can no longer trust them. On the contrary, let us say that your supplier comes up with a unique plan, goes ahead and invests at their end in training to provide the resource to you. This enables you to deliver your software on time and with good quality to your business.

In the above situation the unique plan that your supplier executes is not a part of your contract with them, but it has enabled you to fulfill your committed business objectives. It’s a good example of when your supplier has built trust with you. When you deal with this supplier in the future, you will be always assured in your mind that they can deliver.

Look at the same example from another dimension. A supplier who can propose a unique solution outside of the contract probably understands your business needs very well. What they have demonstrated is ‘partnership’, which is well beyond a transactional relationship. Partnering is a very desirable state in the world of Supplier Management. If you are dealing with partners as opposed to vendors, you are more likely to succeed in your goals. For the supplier it is equally motivating to be considered a partner than just another vendor. It represents a growth in the value chain for them.

7. Can you distinguish between a Service Level Agreement, an Operational Level Agreement and Underpinning Contract?

A Service Level Agreement (SLA) is an agreement between you as an IT service provider and the business as a consumer, to provide specific IT services at a certain level of fulfillment. E.g. you may have an SLA with the business to maintain the infrastructure at 99.97% uptime. SLAs will be referred to in Statements of Work and contracts and are legally enforceable. Failure to fulfill SLAs may result in financial penalty for the service provider.

An IT service provider may have limited capabilities and skills which may require that it source additional services externally from suppliers who have expertise in the same. To source these services externally the IT service provider may need to enter into another contractual agreement with the supplier, which is also legally enforceable between the IT service provider and the supplier. This agreement is also referred to as an Underpinning Contract (UC). UCs need to be created for procuring equipment or specialized services from third party for the supplier or vendor.

An IT service provider may be a large organization with different departments. E.g. the HR department is responsible for providing staff to the IT Service Manager so that they may fulfill the commitments made in the SLA. If the HR department is unable to provide good quality staff on time, the IT service commitments cannot be fulfilled. This is where the IT Manager may want to enforce Operational Level Agreements (OLA). So, OLAs are internal, and made within different departments of the same organization. In certain mergers and acquisition OLAs may be in force between the merged organizations.

8. Can you think of some suitable KPIs for Supplier Management?

One of the most basic KPIs for Supplier Management is the number of underpinning contracts (UC). SLAs exist between the business and the IT service provider, however, when the IT service provider is sourcing goods or services from a third-party or supplier UCs may be the key to the success of the IT service provider being able to meet the SLAs. Appropriate coverage of financial liability must exist in case the supplier fails to meet its objectives. The UC enables to transfer the liability partially or fully to the supplier. In other words, the UC acts as a safeguard or an insurance for the IT service provider when it fails to achieve its business objectives due to the poor performance of its supplier.

Another KPI is the number of contract reviews with the supplier. Contract reviews ensure couple of things. First it ensures that you keep having regular conversation with your supplier. Secondly, it also ensures that the discussion regarding the fulfillment of commitments as per the UC happens. This KPI measures the contact frequency and is therefore useful to determine healthy supplier management setup.

Yet another useful KPI is the number of identified contract breaches with respect to the UCs. Every shortfall of the supplier in fulfilling a contract will usually result in additional costs incurred by the service provider so that the agreed service levels can be provided to the customer. These additional costs will not be chargeable to the customer for the business. Contract breaches are usually identified during contractor reviews or for major breaches during the event itself. A supplier who breaches too many times may be liable to heavy penalty or delisting from the list of suppliers. The service provider may need to further identify another supplier as a suitable replacement.

9. What are the factors to consider when choosing a supplier?

A good supplier is likely to take accountability for quality issues and provide a plan to work forward to address these issues quickly. A supplier without accountability is more likely to deflect the responsibility and blame something else that they will try to pass off as something outside of their control. Good suppliers are usually open to having their processes and internal working audited whenever required. If the supplier is resistant to such audit, it may be a sign of trouble.

Another factor to consider while choosing a supplier is their ability to scale, e.g. as an IT service provider you want a supplier to provide you desktops. You may want to check if they will be able to supply in bulk when need it as well as supply a single piece when the demand is low. A supplier must be verified and possibly references regarding their skills be sought especially when dealing with niche content or skills. Experience of delivering technology solutions in the same domain e.g. banking, manufacturing, E-Commerce sector is also important.

As per the saying ‘culture eats strategy for breakfast’, the next check that you need to perform is whether the supplier’s culture is aligned to yours or whether they will be able to align to your culture. Culture is difficult to change and this fitment must be considered even before choosing the supplier. In international businesses the language barriers and the ability to maintain open and direct communication is important. It will also be the other way around, where as a service provider you may be doing business with an organization which is in a country that speaks a different language. In this case you may want to choose a supplier that also speaks the same language as the business you are serving.

The supplier must possess clear and comprehensive record keeping practices, e.g. they should record all the important decisions and honour the commitments that may have been made only verbally. A supplier must comply to ethical practices and also the regulatory practices whether it be the law of the land or the law under whose jurisdiction the underpinning contract is.

While all the above make a good supplier, what makes a supplier great is their focus on continual improvements e.g. does a supplier only care for the industry standards like ISO? Does it also care to continuously reduce waste and improve efficiency in their operations and possibly even commit to passing some of these cost savings to the customer as gain of productivity?

10. What are the typical contents of Underpinning Contract (UC)?

Underpinning contracts should contain the following information array minimum:

Service name supply information such as supplier name, address, contact person and contact details such as mobile number and email ID

Contract duration, i.e. not only start and end dates but also the terms and conditions under which renewal or termination may happen

Description of the service outcome - this is the scope of the service; what is the utility that is derived from consuming the service. Any warranty information should also so be included under the description of scope of services.

Communication channels and interfaces must be defined which should include not only the contact points and details for both the contractual parties but also a description of such interfaces e.g. how will these interactions happen – over phone, email or Skype. Any service reporting requirements including the content and the frequency must be described. Service reviews at periodic intervals must be included including the parties that will before forming review. Triggers to affect an escalation and the parties involved in the escalation should also be described in detail.

The window of service should be described in terms of hours of service availability as well as the exceptions e.g. weekends and local holidays

The types and levels of support must also be described e.g. remote support or onsite support or out-of-hour support

Service level requirements and targets should also be set in the UC and this would primarily be driven by the business Service Level Agreements and by those that the IT service provider has committed to the business. These could include availability targets, capacity / performance targets and any service continuity commitments including disaster recovery scenarios

If any standard has to be followed for example ISO or CMM this should be mentioned in the UC.

Roles and responsibilities, usage of subcontractors, pricing model including rules for penalties and chargebacks should also be included. The underpinning contract may also contain a glossary of terms and commonly used expressions so that the contracting parties are on the same page. References to other documentation for example master service agreement must be made.

Introduction

In the rapidly changing business environment, nothing is as constant as change itself. Any business that fails to change whether it be in terms of its strategy, products and services or fails to respond to the external environment – the market, regulations etc. is soon left behind and perishes in no time. This is enough motivation to have a Change Management process at the centre of the business – this process is owned by the Change Manager.

Businesses and IT are linked closely. That is why ITIL® defines the Change Manager role and the Change Management process around him.

Change Manager roles may not exist in isolation. With IT rapidly moving into a DevOps model, the Change manager role has been blended in with other roles, and a lot of tools are available to make the change management process stronger. This means that a lot more roles in the organization need to be knowledgeable about change management, and not just the manager. In an Agile world, change is welcome (refer to the Agile Manifesto), however, the principles of change management are still intact.

The Q&A in the next section should be understood in the context of the change manager role and not in the context of an individual. With the increasing importance of organizations being able to adapt to change, these questions are significant across the board – developers, scrum master, product owner, project managers, and portfolio owners; and not just change managers. The questions focus on ITIL, so, are specific to the IT industry. Managing business changes is out-of-scope.

There is limited understanding of the change management process, as what we see on the ground (in most cases) is always an ‘adapted’ version, that suits the business model. This leads us to comparing processes followed ‘here’ versus those followed ‘there’. Through the Q&A in the next section, I have tried to bring up the often missed out fine print in an ITIL context.

1. What is your understanding of the Change Management process?

Organizations establish a Change Management process to be able to manage the situations that their businesses face – this could be competing products or solutions, changes in regulations e.g. safety standards and laws, changing demographics, consumer preferences, attempting to enter new markets or exit existing markets, changing technology and so on. The list can be enormous.

Any of the situations presented above could pose significant risks to the business objectives – that could be making profits, increasing market share and revenues or even serving a market segment. No business owner would want any disruption to meeting any of the objectives above. Even if a disruption is inevitable, they would want to minimise the impact, so that it remains transparent to the consumers of the products or services and they keep getting the same quality or service levels.

Therefore, it is essential for the businesses to put in place a mechanism to manage whatever is not in its control and at the same time be able to fulfil its business objectives, nevertheless. This mechanism is Change Management.

In ITIL, Change Management is a Service Transition process because it bridges the transition between the old and the new. The old is the baseline and the new is the modified services or added services.

2. What are the steps in the Change Management process?3. What are the major responsibilities of a Change Manager?

The role of the Change Manager is key in the Change Management process. All RFCs should be directed, in the first place, to the Change Manager. He will then review the RFC documentation and check that all the needed information is present. If not, he needs to get back to the requestor to seek more information. He may also consult with the CAB members or any other member in the organization who can provide more information.

Once the change is recorded, the Change Manager is accountable for prioritizing it in line with the business goals and categorizing it appropriately. The categorization helps in the selection of the CAB (or the ECAB) members, and then he chairs the CAB (or ECAB) meetings. During the CAB meeting, he will seek the advice of the members of the advisory committee to be able to assess, authorize and schedule the changes.

When the change is being worked on, the Change Manager helps in removing impediments, especially when these are related to the impact or newly identified stakeholders.

Finally, once the change is implemented, he will evaluate that the business objectives have been met and the Return-on-Investment (ROI) has been achieved. He shall be analysing the change trends – like success rate, earned value, incident metrics etc. and regularly reports these and the progress of all the changes to the management.

In the capacity of the Change Management Process Owner, he should retrospectively monitor the effectiveness of the process and plan to introduce improvements whenever necessary.

4. How is the life of a Change Manager – easy or hard?

A Change Manager is one of the central roles in the IT landscape. He must make a fine balance between stability of a running system and introducing changes to it for improvement, fixing broken stuff etc.

The most important factor is the knowledge of the change manager – functional, system and operational. Knowledge is acquired through experience and self-education.

A Change Manager also must balance the needs and risks to the various stakeholders who are impacted by the change. He needs to ensure the converse as well – those that should not be impacted must be left alone. Different stakeholders will have different interests in the implementation (or the non-implementation) of the change. Sometimes these interests may go beyond the business and technical realms.

The Change Manager must continuously ask the question – “What if …?” This is not an easy question for the one who needs to answer. When the stakes are high, such questions may not just be unwelcome, but may cause a change of direction if there is no good answer. Imagine a critical change not being implemented because one of the impacted stakeholders hasn’t prepared a ‘rollback plan’.

The job of a Change Manager is tough – one not for the faint-hearted.

5. What exactly is a ‘rollback plan’? Why do we need it?

All changes made to the baseline code and configuration pass through stringent quality gates. Such changes may have been made based on the impact analysis done in as a part of the change management process. However, as one of the US Presidents mentioned in the 1950s – ‘Plans are useless, but planning is everything’, it is quite possible that the reality after the change is implemented turns out to be something very different from what was envisaged earlier. The question is – have we planned for this ‘possible different reality’? Enter the ‘rollback plan’.

The terminology is self-explanatory. Every change that needs to be implemented must have a rollback plan, i.e. what are the steps that need to be followed if the changes cannot be implemented as planned, or the system becomes unstable post-implementation. The changes would need to be backed out with a sequence of activities, that would have people responsible for carrying them out. The rigor is the same as when implementing the change – the only difference is the intention – you are taking the system back to the baseline. Because you are backing out from an implemented change, this is also called the ‘backout plan’.

Some rollbacks may need to happen as an emergency, e.g. implementation of a new firewall hardware results in cutting off the system from the supplier network, stalling the supply chain. Such a rollback may need to be handled via the ECAB.

Remember – for every implementation plan there needs to be a ‘backout plan’.

6. What is a CAB? What does it do?

The ‘CAB’ is an acronym for the ‘Change Advisory Board’. Many people think that it is ‘Change Approval Board’ – that is not right. It comprises of many members and the membership will typically be defined in the Change Management Policy. Since the CAB is an advisory board, the main purpose of having this organization is to get the right advice on matters related to changes – so membership must be chosen wisely as per the priorities of the organization. The chosen members must also be knowledgeable in their respective areas, so that accurate inputs can be provided in the form of the right advice.

The Change Manager chairs the CAB meetings and is obviously a permanent member of the CAB. Also mandatory is the Configuration and Release Manager. Other members may include – Service Desk Manager, Operations Manager, Applications Manager, Information Security officer, Incident Manager. In real life, most of these roles will participate in the CAB meetings like permanent and may only excuse themselves if there is no agenda pertaining to their role. However, such a situation is unlikely. Sometimes specific support analysts having deep knowledge on a particular topic, incident or functionality may participate upon invitation – with the sole purpose of providing the right advice.

The CAB is concerned only with changes, so most of the discussions may be around future changes – i.e. the Requests-for-Change (RFCs), what risks may be introduced as a result of these RFCs and also prioritizing these. Other topics may also include the past changes that are implemented, rolled back or cancelled. If any implemented change causes the system to be unstable and results in incidents, then these incidents also need to be discussed in the CAB.

7. Your colleague tells you that a change manager is the ‘change agent’ of the organisation. What would be your reaction?

The Change Manager may be a ‘change agent’ of the organization, but that is not his primary job.

The Change Manager is responsible for authorizing and approving changes with advice from the Change Advisory Board (CAB). The Change Manager is the sole authority who can put his stamp of approval for a change to be implemented (or not to be implemented). Because of this responsibility, he will chair the CAB meetings.

Making the decision about a change to be implemented is not trivial, therefore, the person must be knowledgeable about the system, architecture landscape and the stakeholders. That is a broad spectrum. This also means that this person can also actually be a change agent for the organization. Help is at hand, in the form if the Change Advisory Board – which advises the Change Manager in matters related to changes.

The Change Manager is also the process owner for the Change Management process. Since processes may need to change themselves, the Change Manager must continuously validate the efficiency and the effectiveness of the steps in the change process. E.g. for standard changes, he may want to create a Standard Operating Procedure so that this stands pre-approved and the cycle time for change implementation reduces as the CAB is no longer required.

While changes may lead to disruption, the objective of the Change Manager is to minimise the disruption – through the effective use of process, expertise and tools. He should be approving only changes that are beneficial to the organisation and aligned to the business goals and the objectives.

8. What is the first step of dealing with a change? Is this mandatory?

A change is usually received in the format of a ‘Request for Change’ (RFC). Whenever an RFC is requested by the business, the first step is to ‘record the change’. This is primarily the job of the ‘initiator’ – the person who is requesting the change. This recording results in a document, that could be on paper, as well as in electronic media or even in an online collaborative tool (e.g. JIRA).

Recording, or documenting the change is an important and mandatory step, as this document is then passed onto the Change Management organization. The Change Management organization is headed by the Change Manager, who may request further information on the RFC if the documentation is inadequate, incomplete or ambiguous. If this is back-and-forth communication is done multiple times, it results in a loss of valuable lead time for change implementation – therefore, the documentation must be accurate. There will always be some back-and-forth communication, but the objective of properly recording the change is to minimise these transactions.

The Change Manager is accountable and responsible for reviewing the change record and ensuring that it contains enough information.

9. You are the Change Manager. You return from a 2-week vacation and realise that a few changes have been implemented 'informally'. Things are normal post-implementation. Should you care?

Unfortunately, there is nothing called an ‘informal change management’. Changes, no matter if they are small or large, have less impact or more, must pass through the change management process.

‘Standard’ changes follow time-tested and time-trusted steps and the outcome is known – however this does not mean that the steps are bypassed. It only means that efforts need not be spent for analysis and the approval, as these are pre-approved.

‘Emergency’ changes that require immediate implementation must still pass through the Emergency-CAB (ECAB) – a subset of the CAB. It does not mean that the immediate changes can be implemented ‘at will’ or ‘as per management decision’. These are common excuses.

So, as a Change Manager, once you hear about the above situation, you should be very alarmed and take action to ensure that the change management process is followed in retrospect, and the necessary documentation created for future reference. In the longer term, you should aim to make changes and strengthen the Change Management process in the organization. The situation also indicates there may be a lack of awareness regarding Change Management in the organization, so some trainings may also be useful to educate people regarding this topic and the perils of not following it.

10. As a Change Manager, how will you ensure that the RFC documentation has all the relevant information?

For every change raised, the Change Manager must do a thorough review together with the CAB. During this review he must verify that the RFC documentation provides the following information at a bare minimum:

1. Who RAISED the change? – it must be clear who is raising the change. In an organization, this would be a department or a role. Note that this role may or may not be an ITIL role, it could well be the business, e.g. the Web Marketing department.
2. What is the REASON for raising the change? – almost all changes are raised for a business reason. Obviously, the person who raises the change knows the reason best. Sometimes changes may be raised for fixing earlier failed changes.
3. What is the RETURN required for the change? – after the change is implemented, it must be useful to the business, there must be some benefit coming out of the implementation. E.g. increased revenue, more hits on a webpage, faster checkout times at a retail supermarket or increased stability of a system.
4. What are the RISKS involved in the change? – while implementing changes result is some benefits, there is always a chance that something else will break. Proper impact analysis for the change must be done – a rollback plan must be created, and enough regression testing must be factored in.
5. What RESOURCES are required to deliver the change? – this is about who and what will be required to implement the change. This may include people with the right skills, hardware, software and even facilities. E.g. to deliver a large IT upgrade program, you may need software engineers, devices, servers, licenses and new office space.
6. Who is RESPONSIBLE for the build, test and implementation? – these are the people who would be working to implement the change – typically many of the other ITIL roles will be involved together with the project organization for larger projects. Developers, support analysts, project leads, and managers are included.
7. What is the RELATIONSHIP with other changes? – this is about the cross impact of changes that are work-in-progress. E.g. a change that is about migrating Active Directory services may have an impact on another change related to corporate email software upgrade.

The above are also called the 7 R’s of Change Management.

11. What is the role of the CAB in an emergency change?

In the context of an emergency change, we have a special CAB – called the Emergency CAB (ECAB). The ECAB membership is a subset of the more general CAB, and depends on the nature and impact of the emergency change. Because we are in a emergency, time is of the essence, and therefore a pre-defined delegation mechanism may have to be followed if certain members are not present. This definition must be included in the Change Management policy of the organization.

To explain the need for this delegation with an example – suppose an emergency change needs a new IP to be whitelisted for changes to take effect, but the approver is unavailable, let us say that he is on a plane from Sydney to Dubai (that takes about 15 hours). A wrong approval may mean endangering the security of the infrastructure. To avoid such a situation, a delegate for the approving authority may have been defined, who can make this approval on behalf of the main person.

Note that not all emergency changes require an ECAB. There may be emergency changes where a ‘temporary’ operating procedure may have been set till a known issue is fixed (which may be underway and will be addressed via CAB). In this case the relevant parties will execute the temporary operating procedure. E.g., the operations team kills a process daemon consuming too much memory.

To keep the ECAB process lean, some documentation may be done retrospectively.

12. If there are too many emergency CRs coming, what may have possibly gone wrong?

Too many emergency changes may mean that in the recent past, some changes have been implemented without proper impact analysis. This, in turn, could mean there is a shortage of knowledge in the CAB. Either the right people have not been invited, or the Change Manager may not have the right skills.

Sometimes emergency CRs are a result of poorly defined processes – perhaps incidents are being pushed down as changes in the absence of a robust incident management process and without any defined problem management process. It is also possible that the configuration items (hardware, services etc.) are not assigned severities – this is the job of the configuration manager and should ideally be in the Configuration Management Database (CMDB). This lack of definition means that no one understands whether the impacted system is critical and is introducing a change just to mitigate the unknown risk. E.g. malfunction of a service that produces a monthly report may not need to be handled via emergency change process simply because you have enough time to make a permanent fix. Just raise an incident and move on for now.

Emergency changes may also be the result of wrongly prioritizing less important changes and missing on implementing the critical ones.

Emergency changes causes alarm bells and draws much attention, just like a major or a Severity one incident. Therefore, the Change Manager must educate the organization about it and when to invoke this and resist the misuse of this process.

13. How can you judge whether the Change Management process is robust and effective?

A good Change Management process will ensure that the percentage of successful changes are high. A robust process requires rigor, but that should not slow down the speed of implementing the change requests. The throughput of change requests being implemented should be high. E.g. too much of discussion and delays in decision making at the CAB may result in piling up of RFCs waiting to be implemented – this should not happen if a good Change Management process in place. Suitable delegates must be available for situations where time is of the essence, e.g. for ECAB.

In terms of changes implemented, there should be very few that require any backing out or even remediation. Both processes consume valuable resources and sometimes specialised skills that will be charged at a premium because of the tight situation. Additional incident management capacity will usually be planned and budgeted when critical changes are implemented or a big release happens – however, a good Change Management process will ensure that the incident volumes remain well under control.

Most importantly, changes should either deliver value by implementing improvements, or by preventing and removing the negative effects of some existing bug. This value can be measured in dollar value – increase of revenues, increasing market size, reducing downtime etc.

14. What is a Remediation Plan?

We discuss about the ‘backout’ or the ‘rollback’ plan in another question. That was about having a step-by-step guidance of how to return the system to its baseline configuration.

Now, consider the situation where an implemented change has caused some records in the database to be corrupted with unescaped special characters. This has been reported as an incident after about ten thousand transactions have already happened. You can roll back the changes, but then some essential desired functionality will be lost, and the already corrupted records still need to be taken care of.

To manage such situations, you will need to have a detailed plan on the adverse effects of each of the impacts. You will need to possibly assign extra temporary incident management capacity, so that a larger volume of incidents may be handled, and the lights remain on. Some scripts may have to be written to rectify the corrupt records directly, and for this you may need someone skilled at scripting. All this and many other things that you would possibly need to ‘douse the fire’ is what is called the remediation plan.

Remediation plans have well-defined triggers that should be agreed at the CAB. Unlike backout or rollback plans, remediation plans are not about returning to the baseline, but about ‘containing’ the damages that occur due to change implementation. There may be situations where backouts are impossible – like automatic installation of faulty security software in a hundred thousand strong software company. The best solution would be to create and push a patch to remediate the faulty installation.

Introduction

Service Transition is one of the process groups of the ITIL® Lifecycle that contains processes required to take a service from the design board into regular operations. Hence this process group contains processes such as change evaluation and management, application development, validation and testing, asset management and knowledge management.

The Transition Manager is not a role that is defined by ITIL but is nevertheless a very important role that is usually found in organizations that are committed to changing for the better.

People in the IT industry who want to focus on implementing change in their organizations may find the role of the transition manager to be exciting. Also, people who are already a part of the change organization (typically – a change manager), may find the transition manager role the next step they can step up to. Vendor or Supplier managers are closely linked with most of the transitions, so that is another parallel role from which people may consider switching over to the transition manager role. The term ‘transition’ is generic, but the role of transition manager is more specific to transitions of a service across the ITIL phases, across suppliers and between the business and the IT service providers.

Often, a transition manager will span across multiple roles such as change manager, supplier manager and now, DevOps. This role is more suited for experienced professionals, typically with ten plus years of experience.

1. What is a Transition Manager supposed to do?

A transition manager is a key role in the IT services organization.

His primary job is to ensure that the implemented and validated services are handed over to the service operations teams – which could be the Application Management team and / or the Technical team. While it sounds simplistic, this handover is critical to the success of the service provisioning. The criticality increases depending on the importance of the system to the business and also the organizations that have designed / developed the services and that which will be responsible for the operations. Since the dynamics of designing a service are different from developing it and different from operating it, the transition manager plays a vital role in ensuring that there are no gaps as the system transitions from a concept stage to something that can provide a service.

The transition manager achieves this by working with his stakeholders on building up the right levels of knowledge in the team – both technical know-how and system-specific knowledge. He would then put in place a development methodology and/or a delivery model for the services to be delivered. Such a framework ensures that a boundary is set for the party transitioned to. The boundaries may be quantified using service level agreements (SLAs) and/or key performance indicators (KPIs). While the transition manager may not calibrate this himself, his main contribution is to ensure these are in place before handover.

2. Who are the primary stakeholders for the Transition Manager?

In the ITIL lifecycle, the Transition phase sits between the Service Design and the Service Operations phases. This means that the transition manager will have stakeholders that are process owners and process managers of both these phases, in addition to the stakeholders that are a part of the transition phase itself. Fig 8.1 depicts the stakeholders for the Transition Manager across the other phases of the ITIL lifecycle; shorter distances representing more involvement and longer distances imply lesser involvement. Across all the interactions, the transition manager endeavours to ensure that the transition process is smooth.

3. What are the possible transitions in the industry?

In the IT services industry, various kinds of transition happen for various reasons. The most common is the ‘lift-and-shift’ model, where the IT services experience a change of provider, e.g. an organization X may no longer want to use the data storage services being provided by vendor A and decide to switch over to vendor B.

There can also be a situation where the organization develops capability over a period of time, and in-sources the services. E.g. organization X develops capability in a new technology T over a year and no longer requires the services of vendor C in the next financial year. The reverse may also happen. E.g. the organization X uses legacy technology as on date and wants to move to a new-age technology, for which it outsources the upgrade activity, followed by warranty support of a few months.

The last one also leads us to another possibility – that of a ‘fix & mix’ model. E.g. older systems that are built on evolving technology tend to accumulate technical debt. E.g. organization X has a system S that needs to be rid of technical debt. They may float an open tender to which a service provider may respond with a proposal for ‘supporting and fixing the technical debt’.

4. Why are transitions necessary in the first place?

There are many motivations for effecting a transition.

One of the most common reasons is to reduce the total cost of ownership for IT services. After an

IT system is commissioned into service (i.e. system ‘goes live’), the service consumer would expect the system to stabilise over a period and therefore the costs for managing the services the system provides should also reduce. However, this may not be the reality in many cases due to a poor design, technical debt etc. and therefore the business may look at on-boarding a different service provider. Sometimes, this could mean only a change of personnel, or also include infrastructure as well. E.g. Organization X decides to change its provider of data backup services from provider A to service provider B – this will involve a transition of the infrastructure as well as the support personnel. Or, Organization X decides to change sourcing of server administration services from vendor M to vendor N for its on-premise server farm – this is an example of change in personnel only. IT service providers compete fiercely for reducing costs in order to get business.

Often the business will also look at factors like providing customer experience – e.g. sourcing IT Service Desk services from vendors with good credentials in customer satisfaction. In a multi-vendor outsourcing setup, the business may want to consolidate all its IT services from a single provider, to enjoy economies of scale and reduce complexities of managing inter-company service level agreements. The reverse is also true, where the business may want to reduce the risk of depending on a single provider and outsource it to multiple vendors.

Some IT services may require niche skills, that may not be present in-house. This may require the transition of services to a provider who has the skills and expertise. In other cases, the business criticality of the system may be the reason for a transition.

5. What are the usual returns on investment (ROI) for a transition?

A transition is often treated as a project. It has a definite objective and must be completed in a finite amount of time. Like any other project, a transition project also represents an investment by the business, and therefore, must provide a return on this investment (ROI). The ROI will be measured most often, in monetary terms – e.g. a transition that costs $ 100K will have a ROI of 5 months if it results in a monthly monetary savings of $ 20K per month post-transition, provided the service levels do not degrade.

While that was straightforward, there are times when the primary objective is not saving costs. It may be to de-risk system stability – if a new system turns out to be highly unstable, the business may want to bring in a different vendor for supporting it as they want the system to stabilise sooner. Here, the increased stability (and consequently down-time reduction) would be the return that the business is looking for.

Critical systems that deal with business sensitive information, e.g. Business Intelligence systems, financial reporting etc., are less prone to be outsourced to external IT service providers. As a system matures, IT service provisioning may tend to be brought in-house – the return in this case being confidentiality.

Global businesses will also need the capability to scale on demand – this may require choosing of IT service providers that can serve the entire span – the most common example of this being the adoption of the cloud platforms such as AWS and Azure.

6. A new service associated with huge revenue and impacting thousands of users is being rolled out into operations, however, this is within the same organization. Do we need a transition manager or even have a transition process?

Yes.

Unfortunately, most of our organisations tend to operate in silos. This means that there is no common language and practices across departments within the same organization. Organizations that aspire to operate on ITIL best practices, realize that the leap from developing an IT service to when the service is being consumed by the end users is a big one. No matter how robust the design is and how skilled the developers were, there is always the potential of the services not producing the desired outcome and customer experience.

Because the development and support organisations represented in the ITIL life-cycle by the service design and the service operations phases do not necessarily operate as a single unit, there has to be a middle layer, an interface, that understands the process aspects of both sides and acts a glue to provide the necessary rationalization so that when the ownership of the service changes hands, nothing falls through the cracks.

The reputation of a service provider organisation rests on the ‘quality of service’ that the system provides, and therefore, utmost care must be taken to ensure that the service design and operations organisations work in a closed loop (much like the DevOps closed loop representation) so that no loose ends reach the service consumer.

7. What are the factors for consideration during an IT outsourcing transition?

There are many possible reasons behind a business taking a decision to outsource its IT services provisioning to an external vendor over doing it in-house. One of the primary reasons is to continue focusing on the core competence of the business. E.g. a traditional advertising agency that aspires to enter the digital advertising domain may still consider creative designing as its core competence. Therefore, it may outsource the technology aspects of digital such as Google Ad-words, site analytics etc. to an IT service provider that specialises in this.

Another reason could be to utilise the specialist services of an external IT service provider in a new domain, e.g. if a company has recently implemented an ERP solution, it may not have sufficient skills to service the ERP system internally, and this can be grown over a period, till when the business needs to have someone better skilled at it do it for them.

Sometimes, due the costs of labour in the country where the business exists, they may want to outsource the IT services provisioning to a vendor who is in another region where labour costs are lower. Businesses will also do this to derive time zone benefits, e.g. a longer window of support cover for an e-commerce platform that must be available 24X7. India has been in the forefront of the IT outsourcing industry for almost 2 decades now.

Finally, the total cost of ownership is another factor that drives outsourcing. E.g. countless companies have outsourced their infrastructure and platforms to cloud-based service providers such as Amazon, Google and Microsoft. This has reduced the IT capital investment and provides the flexibility to scale on demand.

8. How important is an assets database for a transition?

One of the key factors in achieving a great transition is a comprehensive transfer of knowledge. Knowledge is intangible and therefore, measuring the ‘levels of knowledge’ is always a difficult task. However, assets are tangible – code repositories, configuration files, technical and functional documentation, service level reports, monitoring dashboards are tangible items that are key to providing IT services. Infrastructure, code repositories, documentation and reports are all assets for the service – and a list of these are maintained in the assets database. 

Every transition must include the transfer of the assets at a detailed level – not just the existence of the asset, but also the interfaces (as a part of the Configuration Management Database – CMDB), the associated documentation, known errors and workarounds implemented, changes in progress (which means that there are assets being created or modified) and the service levels associated with the assets or groups of assets. This means that the assets database is critical to the completion of an effective transition.

9. What are the key activities during a transition?

Once the scope of a transition has been decided, there would typically a period when the receiving organisation would understand the services at a high-level. During this time, the receiver of the transition will understand the business objectives of the services, the expected business and IT service levels, assess the system stability and perform an estimation of the manpower required to service the system, functional and technical skills required, interfaces to the other systems and stakeholders involved. This initial phase is called the due diligence phase and information gathered will be used in the next phase – planning.

In the planning phase, the knowledge transfer activities will be planned, and handover dates finalised. Topics for the knowledge transfer, the subject matter experts to deliver it, the timings – all will be decided during the planning phase.

The next 2 phases often carried on in parallel are the knowledge transfer and the shadow phases. During these phases, knowledge will be transferred systematically to the receiving organization, and the latter will successively be able to demonstrate autonomy in being able to provide the services independently. Together, these two phases represent the maximum efforts being spent in making the transition.

The final phase is that of handover – where the incoming organization formally accepts the accountability for providing the IT services. Identified stakeholders will be informed and new communication channels will be ironed out.

10. Can you start a transition without the availability of the design documentation?

One of the most common risk issues highlighted during a transition is the absence of documentation, especially in an Agile setup where one of the values lays more importance on working software over comprehensive documentation. Under documentation, the most outdated is the design document, as subsequent iterations during service development have outdated what was written at the beginning, which means that the working software, or the ‘as-built’ system varies from what it was supposed to be, technically.

While this may sound alarming, we need to accept that evolution is a key to survival in today’s world, so this variation is reasonable, and in the best interests of the business. Therefore, we may need to start a transition even though the design documentation is outdated or absent. Of course there are ways to work around this apparent difficulty – by referring to the conversations in the user stories, having more dialogue with the development team, the testing and validation teams that have worked on building the service – and documenting them for future reference, or updating anything that exists. Establishing a traceability between the business objectives (that have not changed) and the working software is essential. This is a like reengineering the design document from the system that has been built, i.e. going from left-to-right in Fig.