ITIL ®as an inspiration for governing a small IT

consultancy’s support business

Luis Martin-Santos Garcia <lms30@student.london.ac.uk>
2018 Bsc Business Candidate, EMFSS Program.
University Of London International Programmes.
April 26, 2018

Abstract
This paper describes the evolution of one of our company’s operations
and processes in order to achieve a better support service for our cus-
tom software development customers. We transitiones from an unordered,

®
mixed scenario into a new process which were developed by extracting best
practices and structures from the ITIL guidelines, focusing on the spe-
cific interactions between our company and our customers. Although this
can be seen as a cherry picking scenario where we choose what was easy
for us to implement, in reality it turned out as a key achivement in order
to get the business back to profitability.

1 Introduction and Context

Webalianza TI is a small IT Consulting company located in northern Spain.
Founded in 1999, it has served customers in a wide range of industries different
company sizes. The evolution and criticallity of the systems that the company
has developed during this time turned change and incident management into
key processes.
During the first years, being a small company, those were non formal, man-
ageable processes that were executed without a well defined process, metrics or
roles, but after ten years of custom solutions deployed on customers, not having
a well defined process turned against the operation. The financial success of
the company was at stake. For attaining profitability it was needed that more
than 60% of the time of technicians was used on new projects, which were very
profitable because of discretionary pricing rather on supporting old ones that
usually get relationships messed up because of round after round of cost savings
negotiations.
On 2013, the work around supporting customers surpassed 50% of techni-
cian’s time and the financial year closed with loses.

1
2 Information Systems management issue
The issue being discussed in this essay is the implementation of an IT Gover-
nance mechanism, but insted of being seen from inside the organization, as an
issue of a company that services other companies. Chapter 6 of the IS2184[2]

®
course covers ICT governance and describes several ICT governance frameworks.

®
Information Technology Infrastructure Library (ITIL ) is one of them.
ITIL is short for “Information Technology Infrastructure Library”. It is
a compendium of concepts and best practices recorded by the Axelos Group
in the search of a reference model for IT service excellence, understood as the

®
ability of IT services of aligning with the needs of the business or mission of the
organization it serves and support its core processes. ITIL is widely recognized
as the best path to achieve full ISO 20000 compliance, as recognized by section

®
11 of this standard.
ITIL is made of of five core components:[1]
®
1. ITIL Service strategy that guides executives and team leaders in
order to generate service strategies for attaining business goals.

2. ITIL®Service design which provides a framework for the definition

and planning of robust IT services.
3. ITIL®Service transition which focuses on the issues of change and
transition of IT services and its impact on the organization and third
parties.

®
4. ITIL Service operation which highlights the best practices for deliv-
ering IT services with the desired service level agreed with the organiza-
tion.
®
5. ITIL Continual service improvement which leverages the needed
guidance for a continuous improvement practice and its peculiarities re-
garding IT services.

3 Discussion and Argument

As it has been already told, Webalianza is a small company. This allows quicker
decisions to be made at the cost of less time available for developing new ideas
and implementing them. Also the risk of personalizing ideas can lead to dif-
ficult implementation efforts where good communication is needed to convince
an estabilished team, usually in confortable positions, that a new direction is
needed.
After little work it was obvious, as foreseen by the Directors team, that
the financial problem emerged from the unavailability of time for new projects.
Having a simple and well defined cause made it easy to make the decission
of implementing an action plan to correct the trend. This way, the Directors
discussed two radically different approaches.

2
 The first called for the increase of workers and stabilishing a two-team com-
pany where one team would develop new projects that the second team would
maintain an support along time.

®
The second asked for formal processes to be put in place for maintenance
and support services, and the ITIL framework was quickly regarded as the
source of wise counsel if this approach was to be taken.

®
After considering pros and cons of each scenario, the implementation of a
formal process inspired upon ITIL won. It was cheaper to implement, and
was a long term solution. It was also devised that by selected the first option
the company would be a bigger, but will continue with the same fundamental
problem that would arise in a short period of time.
With the decision taken, a team of three people was appointed for research-
ing, planning and organizing the implementation of two processes for Incident
Management and Change Management.
Following the executive decision, the team followed a discovery process of
the current scenario and surveyed different approaches to the problem.
In the discovery process the team monitored the current non-formal process
by disecting and analyzing one hundred of tickets and tasks.
Tickets The ticketing system was a facility for appointed users to report prob-
lems regarding the deployed systems to the support team so incidents and
crashes could be reported and solved. It was found out that every technical
transaction that didn’t involve a purchase request was tunneled through
the ticketing system. This allowed several changes or enhacements to be
developed for free when there was no economic support for that work.
The Zendesk[3] SaaS software was used to capture tickets from an email
address, and process them through a very simple workflow.

Tasks Every actionable issue that was given to the technicians was a task,
which was funneled to them via the OnTime[4] project management ap-
plication. Tasks also contained the actions needed to give solution to
tickets reported by users, so fundamentally, the assigned task list repre-
sented the complete list of work items that a technician would have to act
on.

Movement between Tickets and Tasks was performed manually by administra-

tive personell that copy-pasted information between the systems. This required
technicians to try to adapt their language to the customer’s. This didn’t add
any value to the operation and was more often prone to problems because of
misunderstandings about the nature or solution of problems.
On the timing and service level side, it was impossible to determine the
urgency of issues. Often a less urgent issue was attended when a high priority
one was reported. It was clear soon in the process of discovery that this should

®
be separated in processes with clear objetives and roles.

®
Having gone through the finding process and after revising the ITIL handbook,
our team started the work to extract the best practices from the ITIL processes

3
and adapt them to the reality of the company. This way, we scraped our pre-
vious definition of work types and generated four new issue types with their
corresponding workflows.
®
Requests Generated following the best practices of the ITIL Request full-
filment process The mission of this process is to comply with service
requests that are in form of interactions between customers and the com-
pany for the solicitation of a service of different nature. Requests are
communicative interactions between the customer and the company. This
way, the team’s mission is to gather all the required information about
the request and communicate back the results to the customer. It is also
a duty in the request management process to analyze if the requester is
authorized to generate those requests.
®
Incidents As defined by the ITIL Incident Management process, a re-
quest can be transformed into an incident if it describes an event where
a system has stopped working as expected. Also emerging events can be
regarded as Incidents if they describe a degradation or unplanned inter-
ruption of a system. Incidents must be analyzed in a short period of time
in order to determine its urgency category, impact and get a prompt di-
agnosis of what is happening to the malfunctioning system. After this, it
would be ranked among existing incidents in order to determine its assig-
nation to technicians. This can lead to five different scenarios: First it
can be that the system is working as expected and the incident is innex-
istent, which can happen by misunderstanding of the user or problems in
other systems. This will lead to the incident being closed as “Rejected”.
Second, it can be diagnosed that the system needs urgent intervention for
resolution. In this case the incident will be marked as “Accepted” and
works would start for resolution. Third, the incident can be identified as
a veiled change request, in which case it will also be marked as “Rejected”
and instructed to follow the Change Request path. Finally, the incident
can be marked as a Problem, meaning that there is no able urgent inter-
vention that can fix the incident and further action is required. In this
case, the incident must be accompained by a working plan and a estimated
time frame for resolution. Incident resolution are usually covered by sup-
port contracts, so work on them is automatically authorized. Finally and
incident can be regarded as existent but not urgent, so it would be logged
into the support team backlog and wait for available time for resolution.

® ®
Changes A clear distinction between Change Requests and Incidents is per-
formed in all the ITIL literature. The ITIL Change Management
process clearly puts this process in charge of minizing risks regarded to
improvement of systems, but our concerns were based in the fact that
working software gets too many request for changes during their lifetime
and those have to be analyzed, budgetted and executed. Work on change
requests is not automatically authorized. First, the change request must
pass a director’s authorization regarding budget. This is so because this

4
 kind of requests entail a certain degree of friction with customers by the
fact that they are often identified as incidents because a common percep-
tion that a missing feature that was not in the contract is regarded usually
as an incident instead of a not covered change request that must entail a
further contract.
®
Problems Modeled after the ITIL Problem Management process, when
an incident cannot be totally solved in a short period of time, it is forked
into two issues. One continues to be an incident and will focus on minimiz-
ing the impact of the incident on the service in the short term. The second
issue is labelled as a Problem and its mission is to find the root cause of
the incident, propose a solution and time frame for implementation and
escalate to the service manager for a decission to be taken.

4 Conclusion
The overall migration, from the finding to the final customer implementation
took four months, starting January 1st 2015 and ending on April 30th 2015.
1. The finding tasks were executed during the first month of the year by the
Directors team.
2. Definition and alteration of processes followed on february and took 3
weeks to complete.
3. The process of implementing the changes started with a all-hands training
where all members of the support team received training about the process
to be implemented. The training was veiled as a decission taking process
where Directors used a directed-thinking approach in order to make the
team reach the same conclusions they had reached in the finding and def-
inition of processes. This simplified implementation by making the team
take ownership of their respective decisions. Along the way, new software
tools were implemented for assisting in this transition. Both Zendesk and
OnTime were replaced with the Jira application from Atlassian. This
process of training and software adaptation took three weeks.
4. After training was imparted to the team, communication efforts started in
order to make customers aware of the new processes, changes in behaviours
and people resposibilities. During the months of march and april the
company representatives called, explained and migrated customers one by
one to the new processes.
5. In the following two months, some processes were polished and extra effort
was needed in order to make the team to adhere to the new processes.
In the third month, performance indicators showed that time spent on
support activities started to shrink. In Q4 this reduction amounted to
more than 50% going down to 23% of the time available to technicians
and stayed below 30% for the next three quarters.

5
The project was not an inmediatte success, but allowed the company as a whole
to recover sovereignty over its work schedule in a very short period of time. It
took two quarters to stabilize the indicators and start making an impact in the
accounts, but its effects were durable. This also made it easy for administrative
and sales personell to make clear the budgetary support of any work being
done, incrementing sales and operations that before went unseen due to missing
controls now implemented.
It should also be noted that he team underwent heavy pressure for the pro-
cesses to be implemented and two people ended being replaced, one by resig-
nation and other by an end of contract. We will never know if the change of
people or the change in processes was what really effected change, but it is clear
that the new people embraced the process and without the effort of this project,
neither would have ocurred.
The company recovered primary profitability on Q2 2015 and this project
was regarded as the key change made for getting this result.

5 Critical Reflection
We have approached the discussion of the case through the ICT governance
perspective. This was chosen as an ICT governance issue since the nearest
process that could be mapped to the issue being covered by the company was
governing processes that once were non formal.
If we had taken the same issue from the perspective of the customer, we
would have been discussing Chapter 5, where outsourcing operations are dis-
cussed. It would have been a mistake to regard the company as an outsourcing
company. By means of its size and focus, it cannot provide a full service, not
only because of no desire of doing so, but because of specialization of the de-
velopments made. Since only special and single projects, which usually are not
under the umbrella of outsourcing contracts, are contracted with our company,
we cannot talk about Outsourcing. It should also be noted that the process

®
of developing the new map was not ease though. By having researched into
ITIL and it’s process map and recommendations, it was soon evident that it
would be possible to implement it in a full service and outsourcing company,

®
but it was not suitable for a direct implementation on our company.
The team agreed very soon in the process that the spirit of ITIL is to

®
provide a framework of best practices, not a bible that has to be rightfully
followed[6]. Also, the disparity of scope of ITIL , which angle of vision tends
to focus on the enterprise-out rather on a services company, forced us to adapt
roles and map clear incentives for each side of the relationship.
We could have also focused on the issues described as being part of the
Project Management process, which Chapter 4 of the course focuses on, but it
would have failed to realise that the issue being analyzed arises from the need
of having services after a project has been completed and put into production.
With our current understanding of Project management areas, we couldn’t
find one that covers this continued operation, where cost, quality and resources

6
are constantly changing and communication is regarded as crucial for managing
expectations of service and the fitting into service level agreements and con-
tract terms. Also, company managers tried several times to find an integration
of Project management and Service management activities, but always failed.
Visible remnants of this were the broad definition of “Task” as a work item that
was also used in Incident Management requests.
On the other side, Webalianza as a company is commited to using Project
management methodologies for Software Development Projects and is currently
undergoing the second revision of its methodology which is currently based on
the Scrum[5] framework. This effort has also given us great rewards in terms of
customer satisfaction, less software defects being shipped.
Mixed together, both the implementation of Change Request, Incident Man-
agement and the embracement of Scrum as our Project Management method-
ology can be regarded as the enhacements that made 2016 a great year for
Webalianza, having doubled net income and multiplied profitability by three,
with the added value of a happier workplace.

References
®
[1] ITIL - IT Service Management - Axelos Corporate web page -
https://www.axelos.com/best-practice-solutions/itil/what-is-itil

[2] IS2184 Subject guide - EMFSS VLE -

https://emfss.elearning.london.ac.uk/pluginfile.php/115649/mod label/intro/IS2184 SG.pdf
[3] Zendesk Helpdesk management software - https://www.zendesk.com
[4] AxoSoft Scrum management software for Agile teams -
https://www.axosoft.com/. Previously known as “On Time”
[5] What is Scrum? - https://www.scrum.org/resources/what-is-scrum
®
[6] ITIL Best Practices: Top 5 Insider Secrets - BMC Corporation
Blog - http://www.bmc.com/blogs/itil-insider-secrets-and-5-best-practices-
to-make-it-work-for-you/