Request Process Guidelines

Take this survey to find out if you can benefit from adding requests to the catalog.

What is an IT Service Request?

An IT Service Request is a generic description for many varying types of demands that are placed upon the IT Department by the users.  A request can be a need for more information or a request for an item or service. Typically the request begins with statements such as:

“I need…” or “How do I...”

Also defined as Transactional requests to provide a user with an IT commodity, access to an IT service or ask a question.

Some requests are "standard" (frequently occurring with a defined process for managing) and can easily be planned for. Other requests are "ad hoc" and/or difficult to plan for. The Incident application has been helpful in allowing us the ability to log and have visibility into both types of these requests. While the Incident application is effective for capturing ad hoc requests, the standard requests would be better managed through the use of the Request application in ServiceNow.

General Guidelines

Requests that can be planned for, that are frequently made are candidates for the Request Catalog. Not all requests will move out of the Incident module as there is little value in creating a generic request record when Incident has the current capabilities to route these quickly to the appropriate groups.

Requests that make good candidates for standardization in the Request Catalog

  • Those with proven and documented procedures
  • The requests that the team spends the most time on, utilizing the Pareto principle when 20% of your work takes 80% of your time
  • The request that frequently comes in with missing information required for fulfillment

Automating the workflow for a request and putting it in the catalog will not fix a broken process/procedure; if the request doesn’t work manually today or is not successfully managed as part of Incident/type request it will not work any better as part of the Request Catalog.

Criteria for Use

To find ServiceNow useful the following criteria has been defined. The absence of one of these is a roadblock that will have to be overcome for ServiceNow to be the best solution:

  • Fulfillment group is on-boarded and adhering to the ServiceNow Participation Agreement
  • Fulfillment teams must agree and be committed to a delivery time for request items and associated tasks
  • Fulfillment teams must identify/appoint a request champion that is dedicated to the success of the request fulfillment process

Additional Guidelines

Additional guidelines are in place and must be adhered to maintain the quality of the Request Catalog including:

  • Requirements for request items must be captured using the Request Fulfillment template
  • All request must have standard and approved categorization
  • Request models should be used whenever possible to streamline development and maintenance of the requested item
  • Adherence to the change process for requests:
    • All changes require a two-step approval process and walk through by an individual who does not execute the process on a regular basis
    • Updates to request items should be infrequent (e.g. No more than two times per year without additional wait time)
  • Service Owners with request items in the catalog and assignment group managers with associated catalog tasks must be willing to designate testers at a maximum of 3 times a year to support ServiceNow releases that could impact fulfillment activities
  • Request utilization will be monitored and if a request item is not used frequently the Service Owner must provide feedback if this request should still remain active

Request Types

There are various types of demands made by customers for services. All of these demands are types of request; however, the work to complete such request will vary and may not be within the scope of request fulfillment.  The request catalog might be the right vehicle to link a user to the proper request form through the use of record generators (items that produce a record other than REQ such as an INC record, Change record, Backlog record, project request, etc).

The following details these various types of requests:

 Service RequestChange RequestBacklog RequestProject Request
DescriptionEnd user requesting an IT commodityAdd, Modification or Removal of infrastructure in production which risk must be reviewed and optimizedA requested feature or enhancement that must be reviewed, prioritized, built and tested based on specified priorityA request for a new service, a major upgrade, or significant change involving the cooperation of multiple teams and stakeholders
CharacteristicsTrivial effort, transaction-likeNon-trivial effort but does not require full Project ManagementRepresents a new requirement for a system or service already in production that may or may not be implementedStrategic in nature, effort is significant, cost are capitalized (expenditure over $20,000 or more than 80 hours)
Examples

- Tangible items (desktop, phone, etc.)

- Intangible items (access, software, etc.)

- Application enhancement

- Maintenance activities

- Feature request

- Bug fix

- Technical work

- New application

- PeopleSoft upgrades

- Phone system migration

MeasurementHours or small number of daysHours or small number of daysDefined development cyclesWeeks, months or quarters
Application/Module used in ServiceNowRequestorIncident with Record Type of Service RequestChangeProduct BacklogProject Portfolio Management (PPM)
In scope of Request Fulfillment?YesNoNoNo

Fulfillment Types

  1. Centralized, such as requests for exchange room/calendars, distribution lists, digitization of content, or a new listserv would all be fulfilled by individual specialized groups
  2. Decentralized, such as laptop requests that are fulfilled by multiple teams across campus

For a decentralized request, it will serve us best to pull together a cross-functional group to build a standard request model and supporting the workflow that can be shared and optimized by all.

Sample Request Models

Tangible Request

Task DescriptionStage
ApprovalApproved
ProcurementProcure or Fulfillment
ConfiguredConfigure or Fulfillment
DeliveredDelivery or Fulfillment
InstallDelivery or Fulfillment
Closure

Intangible Request Model

Task DescriptionStage                            
ApprovalApproved
FulfillmentFulfillment
Closure

Workflows

Workflows are often defined as part of Standard Operating Procedures. Operating Level agreements can help define expectations across fulfillment teams when more than one group is required to do work. While workflow is typically illustrated using Visio diagrams a list view would look something like this:

Simple

Step #Detail                                                                                                        
1Auto approval
2Fulfillment task open for Assignment Group A
3Closure

Complex

Step #Detail
1User approval
2Group approval when if condition met (e.g. if $ exceeds "x")
3Fulfillment task 1 open for Assignment Group A
4Fulfillment task 2 open for Assignment Group B
5Upon completion of task 1,custom notification sent to the customer
6Upon completion of task 2, another approval sent to the manager
7If approval rejected, workflow rolls back and reopens task 2
8When task 2 is completed and approval granted, delivery task 3 opens
9Closure

How to Become a Request Champion

Get started today, join us by becoming a request champion.  Any group on-boarded in ServiceNow is eligible.  Email REQ-IT@listserv.cc.emory.edu.