Challenges and Lessons Learned Implementing ITIL, Part 2

The Emirates National Oil Company embarked on an initiative to realize value out of IT assets through Information Technology Infrastructure Library (ITIL) process implementation. This process started initially with a high-level restructuring of the IT department, which was followed by integrating relevant COBIT and ITIL processes for business and IT alignment. This article presents the subsequent challenges that they faced, the value realized, and lessons learned in this transition to the dynamic phase of managing and distilling business value from IT.

Identifying Challenges

In the existing manual IT service system, the organization faced major issues due to the lack of proper processes, procedures, systems and policies, which necessitated a move toward implementing an automated ITIL solution encompassing IT service management (ITSM) best practices. The challenges faced during the planning phase were manual processes for access provisioning; manual/ad hoc change management processes; a lack of transparency in recharge; using a nonscalable small application to log incidents; an inability to track service level agreement (SLA) compliance; manual tracking of desktop license usage; manual generation of reports and statistics; manual inventory of assets; and person-dependent, rather than process-dependent, IT services. Implementation phase challenges were integration with the Oracle fixed assets, bugs in the old license metering software and discrepancies in the financial data regarding assets.

Manual Process for Access Provisioning

The organization has locations throughout the UAE and the Gulf Co-operation Council (GCC) region, and in Southeast Asia. The head office houses 35 percent of the workforce; the other 65 percent is located in different physical locations. Some of the divisions are quite volatile, with high employee turnover, especially on the retail side, which gives rise to numerous instances of access provisioning and deprovisioning. Prior to 2009, the organization had a manual process with a manual form for access provisioning and deprovisioning. In this respect, IT requests went to the line manager, who, after approving the requests, scanned and sent them by email or faxed them. Most of the time, the process took a lot of time, and line managers were not sure where to send requisitions. On numerous occasions, the IT department, due to time constraints, gave provisional access pending the receipt of the signed request form, and there were instances of nonarrival of those documents.

This issue was highlighted during the audit exercise when the auditor questioned the process of giving access. When the auditor requested the list of new employees and the approval documentation for providing access, the company had to employ a full-time IT person whose job was to locate these access documents for the new employees from the boxed files, with only a general idea of the date the request for access was made. If that person did not find the requested documents, there would be exceptions to the audit process, leading to further questions. Therefore, the entire manual process took a lot of effort and generated numerous instances of noncompliance to audit, which was a major issue.

Manual/Ad hoc Change Management Process

The second challenge was in the realm of change management. The company had a substantial number of IT assets, which required a lot of procedural effort to change, upgrade and modify. For example, if one user wanted to upgrade her/his system from Java 1.4 to 1.6, the IT support personnel looked at it purely as an upgrade, without looking at dependency, due to the lack of documentation of the asset, thus proceeding with the update. There were cases of dependency with applications, where some applications that were working with the old version may not work with the new change. Hence, doing things in an unstructured way gave rise to reduced effectiveness of the system, which, ultimately, led to a very unstable system environment prone to frequent outages.

Lack of Transparency in Recharge

The IT department was functioning like a center for providing IT services, while all the other operating units were functioning like profit and cost centers. They were charging costs to the operating units based on an arbitrary fixed percentage, without looking at the actual usage, due to the lack of a proper system for measuring IT services. For example, if there were four operating units serviced, irrespective of the IT service provided, each of them would be charged 25 percent on an equal basis. This led to misunderstanding and customer complaints regarding overcharging, lack of transparency in recharge, lack of effectiveness in measuring service provisions, and mistrust, which led to the IT service department being viewed as a nonvalue-added partner.

Incident Management

Regarding IT-related incidents, the organization lacked any processes or documentation to analyze the root cause of reported incidents. Moreover, outages were not recorded effectively due to the lack of documentation, and the IT services provided in response were person-dependent, rather than process-dependent. From a technical perspective, the entire back-end incident management process was handled through a small commercial off-the-shelf (COTS) application, which was doing the job of taking the call, booking it and closing it, showing only the number of calls that remain open and the time the calls were recorded. This application did not have any functionality to report how incidents were solved, breaches in the service level agreements (SLAs), assigning/reassigning calls to IT service personnel, or any workflow or approval mechanisms. If a call had to be reassigned, the incident would have to be closed and a new incident created and assigned to IT service personnel. This was a simple software that was appropriate for five to 20 users, but not for a large multinational organization with 39 subsidiaries.

There was no mechanism to categorize the calls based on the severity and criticality of the functions, nor any processes to track compliance to controls, which led to inappropriate allocation of IT service.

Manual Tracking and Inventory

The company has around 2,200 desktops for which it paid an annual license fee of approximately US $1 million. Most of the time, the IT department was unaware of modifications, purchases or retirements of these PCs because there was no formal procedure to communicate this information. Without any metering system, the organization did not have the capability to figure out how many licenses it was actually using, resulting in the addition of more licenses. Sometimes the organization would estimate based on predictions or new assets added, which resulted in underreporting or overreporting. In all the cases investigated while implementing ITSM, overreporting was the issue, causing the company to pay more than the actual license fee owed.

The organization also did not have a CMDB system to track its IT assets. The current system did not maintain, in a single database, complete information (such as vendor, date of purchase, current depreciation value and expected life) about configuration assets such as PCs, servers or network equipment. This made it difficult to plan for replacement or make buying decisions. Moreover, as the IT service manager noted, in a manual inventory system, there are no automated processes to identify inventory, so if one person goes on leave, then everything comes to a stop.

People, Processes and Responsibilities

The IT services of the company were person-dependent rather than process-dependent, such that there was no control mechanism or process that ensured that everybody followed the same methodology in approaching an issue. For example, in change management, the lack of written procedures meant that different IT personnel followed different procedures to address the same problem. Since, during the audit process the auditors have to get the information from the person rather than the position, this resulted in information retrieval being person-dependent.

The organization did not have a responsibility assignment matrix, which states who is responsible, accountable, consulted or informed (RACI). The roles of the various functions were neither defined nor allocated to IT positions, so incident resolution lacked accountability.

Transitioning Process

Transitioning from the development phase to service deployment (go-live) was a challenge. Since deliverables and the quality check at each stage of the software development life cycle (SDLC) were not done precisely, they went through the deployment stage with numerous inherent deficiencies. Subsequently, this led to redevelopment and retesting, which meant extended service deployment timelines and cost overruns.

Lessons Learned for Continuous Improvement

IT service improvement is not a project, but an ongoing journey. An organization needs to streamline the policies and processes and educate people for effective adoption before moving into the actual implementation. As the IT landscape is changing continuously, the initiative should also be a continuous process broken into manageable and controllable smaller initiatives to ensure focus and effective adoption. This section outlines the lessons the enterprise learned from this journey.

IT Service Management—A Marathon Consisting of Small Steps and Victories

When the organization started the ITSM process, the desire and intent was to implement everything in one phase. Subsequently, once the visioning was completed, it became clear that some of the service domains had very low maturity and would require a lot of effort to climb up the maturity ladder.

It is better to keep the policies, processes and procedures simple and moving, taking one step at a time while looking at areas of improvement as each process matures. It took two years to reach the current level of maturity, achieved in 2014. Stakeholders observed that it is advisable to focus on the easily implemented services where quick-wins can be realized. Initially focusing on the quick-wins nets results because they are easy to implement.

Any visible improvements due to ITSM implementation, whether minor or major, need to be documented, accounted for, communicated and celebrated. For example, making even minor improvements in an ITSM domain, such as reducing open incidents from 10 percent to 2 percent or keeping uptime to 99.95 percent, is a victory. These represent changes made in the production environment achieved through proper approval processes. They need to be communicated to stakeholders to get people motivated.

The Right Policies/Procedures and the Right Tools, in the Right Order

The ITSM tool provides only an open-ended kind of framework, which the organization needs to tailor to its environment by populating it with data corresponding to customized and well-defined policies and procedures for the tool to generate outputs based on the built-in database. The organization’s manager of planning and performance management noted the importance of having predefined and agreed terminologies to ensure everyone understood the terms the same way and knew how to respond to them, thus generating the required outputs. Customization of the policies and procedures ensures that the full benefit of the tool is being realized.

Since the main engine for the smooth running of ITSM is the automated tool that embeds the IT service domains, it becomes imperative for the organization to have robust hardware, user-friendly and secure technology, and commonly used tools. Moreover, since the information repository forms part of the core IT service management, it requires a solid database. The strong database (the company in this case study used the Oracle database), along with reliable hardware, ensures availability of the system all the time. In addition, user friendliness can be enhanced through the use of mobile-enabled tools.

Ensuring Everyone Is on Board

Because the ITSM tool affects all those users who use a system in the organization, all users should be aware of the subsequent process of fully utilizing the ITSM concepts. Users should be motivated to use the ITSM predefined channels and format of communication to report an incident. Likewise, the IT support personnel should be encouraged to enter incidents into the system instead of using other channels. Similarly, the incident manager should be motivated to understand that if he does not respond within a specified time, this will lead to an SLA breach, resulting in not meeting the service-level contract. Hence, the organization should instill a sense of ITSM culture into employees at all levels so they understand the benefit of the system and their expected responsibilities, supported by continuous education and training.

Undertaking Ongoing Assessments

The organization has regular operational assessments performed on an annual basis by an independent entity appointed by the government. The assessment reveals the strengths and weaknesses of each ITSM domain and provides information on the areas where the organization needs to focus. Hence, this assessment functions as a feedback mechanism with the information fed back into the plan-do-check-act continuous cycle system for the identified processes, which are then improved during subsequent cycles.

The company also undergoes an annual operational audit of service operational processes and an every-other-year IT governance maturity assessment (which includes ITSM), at which time they revisit the domains of improvement in ITIL and COBIT. These provide the information for continuous improvement of the existing processes.

Training

Training has been given utmost importance by management. Since people constitute one of the pillars of ITSM, the organization followed a three-pronged strategy (figure 1) covering change management training, assisting employees with achieving various levels of ITIL certifications and building a knowledge repository for quick reference.

Role Clarity

Prior to and during the initial phases of the ITSM journey, there used to be an overlap of roles, leading to issues in responsibility and accountability. While the maturity level went up during each stage of the ITSM implementation and improvement process, duties were adequately segregated where new roles were created (e.g., quality assurance manager and release manager), leading to proper checks and balances.

Value Realization

Implementing ITIL can provide users with a huge range of benefits that include reduced costs and improvements in IT services, customer satisfaction, productivity, use of skills and experience, and delivery of third-party service.¹ The three major domains in which customers saw significant service improvements within the case study organization are transparency, communication and turnaround time (figure 2). The IT service catalog ensured transparency in service recharge, which, in turn, created goodwill among IT service users.

Communication with end users improved considerably with this process, especially the ability to publish information related to incidents and service breaches gathered as part of the business analytics of ITSM application. This improvement enabled stakeholders to keep end-user management up to date with the service operational performance.

The implementation of the structured approach to deliver IT service management enabled the organization to align itself with the business strategies and tailor its services to meet those expectations. It was evidenced by the consistent customer satisfaction scores the organization received from customers. The annual customer feedback surveys conducted over the three-year period show gradual improvement (figure 3). During 2014, the sample size for the survey was 519, where 87 percent of staff were satisfied with the IT services and support (agree + strongly agree = 87 percent; figure 4).

Since 2015, the satisfaction rate decreased and reached a plateau (figure 5). While the organization has realized value out of ITIL implementation, multiple factors affected this low score. First, the initial implementation during the first two implementation phases drastically improved the score from 2009 to 2014. Subsequently, the expectations of the users increased with each phase of ITIL implementation. Third, each successive implementation of ITIL processes introduced new controls, which led to some user dissatisfaction. Fourth, from 2014 to 2016, a major ERP transition process was executed in parallel to ITIL, which created multiple integration issues. Other than that, management was pleased with the score.

Conclusion

This article describes the organization’s transition from viewing IT as a cost to perceiving it as value-creating asset, assisted by the deployment of IT governance concepts, integrated with ITSM best practices (using the ITIL framework) and COBIT. The implementation journey has proved that a marathon approach, taking simple steps one at a time and improving as the organization matures in each process, ensures success and commitment among employees. Creating operational business/IT alignment is a challenge as it involves fostering cross-domain communication and knowledge flows among staff in different departments.² Therefore, a strong case can be made that the practices and lessons learned at this organization can be applied by other organizations planning to implement ITSM best practices, integrated with IT governance concepts, to realize value from their IT investments.

Endnotes

¹ Rasa, G.; S. J. Kumar; R. W. Banu; “Release and Deployment Management Using ITIL,” Global Journal of Computer Science and Technology, vol. 10, 2010
² Wagner, H. T.; T. Weitzel; “How to Achieve Operational Business-IT Alignment: Insights From a Global Aerospace Firm,” MIS Quarterly Executive, vol. 11, 2012