Request Fulfillment Ticket – Should It Be Reopened Or Incident Ticket Raised?

In my various interactions with my customers and fellow professionals, I have come across many queries where people ask me “If Request Fulfillment Ticket is not correctly fulfilled, should one reopen the ticket or raise another request fulfillment or Incident ticket?”

Service request is a request for any service or standard change. Some examples are password reset, software installation, hardware request, access/authorization requests, location movement, etc.

Let us consider some examples when service requests are inadequately or unsatisfactorily provisioned:

• Reset password does not work
• Software installation was not proper or wrong version was installed
• Hardware provided was faulty or of different configuration
• Others

Let us first understand the Ticket Closure part of Request Fulfillment process. After the ticket has been fulfilled or provisioned, the resolver group has to seek confirmation from the user before one can assign ‘Resolved’ status to the ticket. This is one of the instances where user can ask for a proper or satisfactory resolution.

In cases where due to whatever reason (e.g. 3-Contact Process), ticket has been assigned ‘Resolved’ status, user can reopen the ticket citing reasons for the same. Reopening of the ticket can happen ‘n’ number of times.

What happens when ticket is reopened?

When a ticket is reopened, the SLA clock starts ticking again. Please note that the SLA clock does not restart. Thus, the chances of SLA breach for the resolver group increases. Also, ticket is escalated after n^th time it is reopened (‘n’ depends on the process defined in an organization,).

How does ticket reopen affect the KPIs?

When a ticket is reopened, two major KPIs that would be impacted are:

• %age and number of tickets reopened (measurement of how effectively the resolver groups are able to fulfill or provision service requests)
• %age and number of tickets that breach the SLA (another measurement of effectiveness of resolver groups)

Analysis of these two KPIs and the factors that drive up the number/percentage would lead to SIPs related to ‘People’ or the ‘Process’ itself depending on the analyzed root cause.

Why not create an Incident Ticket?

Incident is defined as an unplanned interruption to IT service or degradation of the quality of IT service (or a CI).

When any request is incorrectly provisioned, it is not an instance of service disruption. The particular user does not have access to that service itself and thus needs the access to the same. This is a service request and not an incident.

Please note that when any process is defined, as part of the process definition itself measures have to be put in place to monitor and measure process performance besides the aspects that would drive continual improvement of the process.

3-Contact Process or 3-Strike Rule

I got a query from one of my readers - 

Situation: 

“We are at times faced with the challenge of SLA violation due to client unavailability. Our staff then requests that we increase the SLA because they don’t want to be held accountable for something that was out of their control”  

Query: 

“Is this a proper practice to adjust the SLA? This SLA increase then becomes open for people to take chances to avoid violation. How does other organization handle such a matter?” 

Providing such options would always lead to malpractices and results in bypassing the process. This is not a good practice. 

A typical situation in which one could face such a situation could be a ticket has been raised which need either of the following: 

1. Clarification or additional information required from the user 
2. Availability of the user to fulfill the request or provide resolution (access to users laptop/device might be required) 
3. Confirmation needed from the user that the ticket can be assigned ‘Resolved’ status 

In all these situations if the user is unavailable and the clock is ticking then it might lead to a SLA breach. For all such cases the status ‘Pending For User Clarification’ should be used. Moment a ticket is assigned this status, the SLA clock stops (In case one does not have this status in their tool or the clock still keeps ticking, a customization would be required. Please note all standard ITSM tools have this functionality out-of-box.). There are instances when the user has gone on vacation or is not responding. In all such cases 3-Contact process, also known as 3-strike rule, is applied. 

3-Contact Process or 3-Strike Rule 

When a user does not respond within a stipulated time then this process/rule is applicable. User is contacted 3 times typically on 3 alternate business days (or agreed with customers). If the user does not respond then the ticket is automatically moved to cancelled or resolved status as applicable. Generally cancelled status is applicable if some additional information or clarification is required from the user while resolved status is applicable if confirmation of satisfactory resolution is required from the user. If user is on vacation then the first contact is applicable when he or she returns back to office. In many cases this rule is not applicable for VIP users. All such instances should be captured as part of the process document.

Interpreting OGC-Capita Joint Venture

26^th April 2013, the date which could possible go down into Service Management History as capitalization of ITIL framework. This very day OGC entered into a joint venture agreement with Capita, an IT outsourcing provider of UK, to form a new company that has not yet been named. With this the ITIL, PRINCE2 and other IP of OGC would be owned by this new company which would take the responsibility of commercially developing these IPs. The new company would be launched in January 2014. The commercial and other details regarding this venture are available at:

https://www.gov.uk/government/news/new-deal-will-market-government-professional-qualifications

http://www.capita.co.uk/news-and-opinion/news/2013/capita-selected-to-form-jv-ip-business-with-cabinet-office.aspx

http://www.telegraph.co.uk/finance/newsbysector/industry/10019090/Government-forms-IT-joint-venture-with-Capita.html

It is interesting that such a major news for Service Management industry got minimal news coverage outside UK. Also, I am a bit surprised why other IT giants or organizations like EXIN have not won this bid because they have a potential to pay much more than Capita did. Was it that these organizations felt that there would not be a significant RoI from this deal or was it something else which prevented, barred or disqualified them from this bid. Only OGC would have an answer to my question. My opinion is that definitely it is not a case where these organizations were not interested. Owning IPs from OGC with the likes of PRINCE2 and ITIL surely make a great business proposition especially when you get to own the IP, which would take an organization into a different playing field all together. So RoI and business sense is definitely there. Then how come Capita, comparatively an unknown company outside of UK, has won this bid?

My opinion is that this being an election year in UK could have had an influence on decision making. EXIN was a Dutch company. IBM, Accenture, TCS and the likes are neither British as well. So though it might have had made more business sense for UK government to go with these Giants yet it would have had a political fallout on the ruling party.

How Service Management Industry Would Transform Post The Joint Venture

Only future will unfold the eventual impact of this joint venture. But I believe as far as adoption of ITIL V3 framework is concerned, there would not be any significant impact till a time the new venture does not come out with a policy to charge royalty for using the framework, a decision which could possibly lead to the death of ITIL. We might see some new Service Management framework being released from Open Source networks.

ITIL has grown not simply because OGC owned and developed it. It happened because many professionals across the globe, irrespective of their corporate boundaries have contributed to its evolution into a de-facto framework for IT Service Management.

Now post joint venture era, would the same level of contribution happen to further evolve ITIL? I do not think so. On the other hand the new company might hire professionals to write the new version of ITIL or develop supporting peripheral materials. In both the cases the acceptance level which ITIL as a framework enjoys today would not remain the same.

Other factors which could be interesting would be:

Firstly, the IT service providers who have a major contribution towards using the certification scheme may decide not to accept the ITIL certifications. This could happen because the money they would spend on getting their resources trained or certified would indirectly be funding their potential competitor.

Secondly, IT service providers and ITIL Consulting companies would start facing a severe competition from Capita in the ITIL consulting/implementation space since Capita would go to customers and claim that they own ITIL and no one can provide a better consulting/implementation solution than them. This again could be deterrent for such companies to accept ITIL’s evolution and thus contribute towards an open source Service Management framework.

Thirdly, the certification bodies like EXIN, APMG, etc. or ITIL Consulting Companies like Pink Elephant, Quint, QAI, etc. may decide to come out with their own certification scheme which could be based on an open source or their proprietary Service Management framework.

With all possibilities I see a major decrease in the revenue from ITIL certification and evolution of ITIL framework. Thus, this joint venture might possible fail on a long term and OGC would have a stiff competition from a new open source service management framework.