Working as Designed, IT Service Requests are a Dilemma

it service request(s), it project

IncidentsService Requests. In the world of IT support, what’s the difference?  

Well, since you asked…ITIL promotes dividing all IT work into two groups and differentiates by calling them Incidents (Break/Fix, Reactive, etc.) and Service Requests (everything else).  

ITIL defines an Incident as a network, system, or device that is not working as designed. In contrast, a Service Request is a network, system, or device that is working as designed.    

Priorities Further Define IT Service Request Characteristics 

While the PSA/IMS** software is capable of dividing the work into either Incidents or Service Requests, we use a single data field to further define the characteristics of the requests.  

You guessed it – Priorities. Since the work is divided at the top level between Incidents and Service Requests, it makes sense to discuss priorities for the two groups separately.   

Last article, we discussed Incidents at length. In this article, we will take an in-depth look at Service Requests.  

What Types of IT Service Requests are There?     

Service Requests are further defined by the Priority field into:   

  • Scheduled Events (Sch Event)   
  • Change Requests   
  • Net Admin Other Recurring services (NA/Recurring)  
  • Projects (Project)   

All Service Requests use the priority level of Scheduled Events (Sch Event) except the following, outlined in greater detail below. 

IT Change Requests   

A Change Request is a scheduled event by definition, because the network is working as designed, but the Customer or someone else wants a change to the network. This type of Scheduled Event usually requires a technical impact review and some level of authority approval.  

In the world of enterprise IT Support, a global Change Request approval process may be enough. In the world of Managed Service Providers (MSPs), Customer dependent configurations for the Change Request approval process is required.  

NA / Regularly Recurring Service Requests 

Service Requests are scheduled on a regularly recurring basis using a Recurring Master ticket to schedule, such as:  

  • Network Administration visits  
  • Staff Augmentation  
  • Back-up checks  
  • Internal Support (i.e. Sales Engineering, Standard Build Documentation, Training windows, etc.)  

IT Projects: 1 Word, 2 Meanings 

Before we jump into talking about Projects as a type of Customer Request, let’s talk about how the jargon trips us up. Project is a single word with two distinct meanings.   

First – Project is a mechanism for capturing time and tracking the work versus a Ticket. Here we are talking about modules or areas of the software in use.  

When to use the project module depends on the complexity of the work: 

  • If the request has a single phase and a single Resource, then a Ticket is the more efficient time capturing vehicle to use.  
  • If the Project Request has multiple phases or multiple Resources, using the Project module is the best way to go.  
  • Note that the estimated hours is not a determining factor.  

Rolling out 32 PC’s probably takes as much time as a Physical to Virtual migration. Rolling out 32 PC’s using the same image is not complicated enough to merit using the Project module.  

Second – Project is how we are using it in this context – it is a type of Customer Request versus an Install. An Install looks like a project in that it has been sold, but has less hours.  

Estimated Labor Hours Help Define What an IT Project Is 

The deciding factor of what is a Project vs. what is an Install is the estimated number of hours.     

The estimated hours threshold has several key characteristics:   

1) Is a specific labor hour number established for the Company 

2) Will be different for each company, depending on: 

  • Their project management capabilities   
  • Types of projects they are managing   
  • Is usually established somewhere in the range of 8 to 32 hours   

3) Triggers a different sales process and one that includes: 

  • Management approvals before submitting proposals to the Customer   
  • Some level of Engineering or Technical review   

*Note: this does not include incidents with estimated labor hours over the threshold; they are still incidents and should be addressed as such.   

What’s your take on this?  

Let me know if you disagree in the reply box, as I am always happy to discuss the confusion further.  

 

 

Example Based on ITIL’s Urgency and Impact Matrix  

 

Based on ITIL’s Urgency and Impact matrix 
   
Priority Levels  Example 
Critical  Network, Server, Core Application is down 
High  Latency, or other network degradation, key personnel/device 
High – Back Up  Any and All backups 
Medium  Single User with workaround 
Low  Aux equipment with backup 
Sch Event  Non-Incident (Non-Reactive, Non-Break/fix) 
NA/Recurring  Network Administration or other Recurring visit scheduling 
Projects  Uses the Sales Pipeline process 

 

Steve Buyze via LinkedIn 

For more about Stephen Buyze

To follow me, Stephen Buyze

For more information about MSP-Ignite Service Manager Peer Groups

For more  HDI “The Association for Technical Support Professionals.”

Leave a Reply