Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic



Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL®, IT Governance & Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.


The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronyms like ITIL, Lean, Agile, DevOps, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."

Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams


Troy On Twitter

Recent Entries



Other Blogs


Service Request vs. Request for Information

In the spirit of recent posts related to ITSM implementation considerations I would like to toss another practical topic into the ring that goes slightly beyond but does not break the good practices documented in ITIL.  Many of the readers of this blog may be aware that ITIL v3 has acknowledged that Service Requests as handled by the process of “Request Fulfillment” and found in the Service Operation book has been acknowledge in ITIL v3 as its own process and is not tied to Incident Management as some would espouse. 

I for one never saw eye-to-eye with this view and found myself on the side of the debate that preferred to think of a Service Request as a low risk change focused on the request for something that a user did not have or a modification of something they already did.

E.g.: I want a laptop, a new user account, or access to a report that is beyond my access rights

With Request Fulfillment being acknowledged as its own process outside both the domain of Incident and Change Management this effectively silences the ITIL geeks such as myself on this topic and forces us to find some other minor issue to debate as we down our recreational beverages.

The challenge that still remains however is whether there is a difference between a request for service and a request for information. The general description of a Service Request covers both.

From the ITIL v3 glossary we can find the following definitions:

Service Request: A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See Request Fulfillment.

However in practice when implementing an ITSM tool or setting up a Service Desk it has always been my advice to create a different classification for each of the following:

  • Service Request: Standard / Pre-approved Change
  • Request for Information: Advice, information, on the phone training
  • Password Reset: Not an incident since the service is still there ready and waiting, more like a request to let me back in

Note: All of these record types are different from an Incident ticket that supports the restoration of service.

It is my view that a distinction has to be made by the service desk between each of these different types of records both from a management information and process workflow perspective. Regardless of the question of ITIL v2 or v3 this distinction has always been needed when implementing these practices.

Troy’s thoughts what are yours?

Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning. ~Sir Winston Churchill


Posted by Troy DuMoulin on 06/19 at 04:29 PM
  1. Troy,

    Does the request for a brand new service or a new appplication fall within the domain of Service Management? If so should these requests be recorded on the Service Request Log?


    Posted by .(JavaScript must be enabled to view this email address)  on  08/13  at  08:41 AM
  2. Hello Roger

    You are right in your assumption. This is even more so now with the release of ITILV3’s introduction of the Portfolio Management process described in the Service Strategy and Design books. The request for the new service could be potentially submitted to a role in Service Management “The Service Manager”

    The way I understand the Service Manager role is that he or she owns a super set of services from a strategic perspective. A service owner owns each Service but you could refer to the head of ERP Applications as the ERP Service Manager in that he or she has ownership for all of the application services in that category. Or alternatively the head of Infrastructure has the ownership of all of the back office infrastructure services.

    We documented this role in the service catalog book but called it a Service Delivery Manager (Pre-ITIL v3)

    Service Delivery Manager:

    However the Service Delivery Manager is accountable for the strategic view of overall IT service offerings as described by the catalog is responsible for the tuning and improvement of those services in order to ensure they continue to meet business needs. It is not uncommon to find a Service Delivery Manager as a direct report to the CIO. In some organizations this role is referred to as a Product Manager.
    Service cut across silos, they cross different functions—it is the service delivery managers role to assemble them into bundles that make sense to IT’s customer.  The service delivery manager both leads and collaborates in defining, supervising and enhancing services to achieve the needed levels of customer satisfaction, regulatory compliance, and operational effectiveness.  Outsourcers and most high-tech companies have this role already. 
    This role is responsible with coordinating defining both the specific services to be provided as well as the roadmap of future IT services. This is done in conjunction with both the service level managers, IT executive management and service owners. To do this the product managers must own the definition the SLA’s, measures, bundles, resources, pricing, cost allocation. 
    They are the ones who design the options between quality and cost which the customer can then select. Because of this, they are responsible for the strategic roadmap for improving service quality and cost—they do this in conjunction with the IT planning function.
    SDM’s are responsible for the competitiveness of their offer in their marketplace. That means benchmarking their offers against external providers, leaders in their industry, the important metrics.

    Service Owner

    The Service owner role is accountable for a specific service within an organization regardless of where the technology components or professional capabilities reside which build it. Service ownership is as critical to service management as establishing ownership for processes which crosses multiple silos or departments.
    To ensure that a service is managed with a business focus the definition of a single point of accountability is absolutely essential to provide the level of attention and focus required for its delivery.
    Much like a process owner the service owner is responsible for continuous improvement and the management of change affecting the service under their care. However in both cases these horizontal roles are as effective or not according to the level of empowerment provided to the role by the executive of the IT organization. The Service owner is a primary stakeholder in all of the IT processes which enable or support it.

    Hope this helps


    Posted by Troy DuMoulin  on  08/16  at  12:00 PM
  3. Hi Troy
    We are working on Service Requests and getting ‘stuck’ on some verbage we have inherited. The terms are “Standard Service Delivery Request” and “Simple Request”. In trying to classify our services we first need to understand the difference. Have you heard of this before?

    Posted by .(JavaScript must be enabled to view this email address)  on  08/29  at  05:33 PM
  4. Hello Michelle

    While I have not seen the term Simple Request before I can guess what this is.

    One of the key deliverables for both Change Mgmt. and Request Fulfillment is the development of classification models (Big to Small) that indicate how much assessment, paperwork or what level approval is required.

    See my post called Its Classified

    A Standard Request or Change usually means that these are low risk, cost requests that have been documented and are repeatable.

    In most cases these types of requests are either pre-approved or only need the cost center approver to give their blessing for the request to be fulfilled.

    My guess is that a Standard versus Simply request refers to two levels of authorization. Perhaps a standard request requires a line manager or cost center approver and a simply request (eg: buy a mouse, a password reset) is a pre-approved activity.



    Posted by Troy DuMoulin  on  08/30  at  09:30 AM
  5. Hi Troy,

    Do you have any suggestions for differentiating between standard operating procedures (SOPs), service requests and standard/pre-approved changes? The organization I work for has done a lot of work to develop an SOP process and now I am attempting to map these SOPs to IT Services but finding many of these SOPs could be classified into service requests, standard changes, or even Incident diagnosis procedures.

    Posted by .(JavaScript must be enabled to view this email address)  on  10/31  at  02:06 PM
  6. Hello Lee

    If you consider that a standard operating procedure (SOP) refers to a documented and consistent way of doing things then it can be understood that the term SOP refers to a way of doing things as opposed to what you are doing.

    I can create a SOP for emptying my dishwasher, changing my oil or handling a standard service request.

    Standard Operating procedures are great when you have a highly repetitive task that is complex, regulated, or resources lack training or do not execute the procedure frequently.

    So in short you can have defined SOP’s for the following processes to ensure consistency in execution.

    Incident Management: fix something that is not working

    Request Fulfillment: Ask for something you don’t have or a modification of something you do that are defined as requestable services within your published catalog.

    Change Management: Gain approval to modify the status or attributes of a service or one of its components.

    Hope this helps


    Posted by Troy DuMoulin  on  11/01  at  04:46 PM
  7. Thanks Troy. Your insights are very helpful, since I am trying to re-organize/structure our incident management process (according to ITILv2) towards ITIL v3 and have to take-out the Service Request part into the Request Fulfillment process. The Information Request calltype has proven to be necessary in our organization. So although the ITIL v3 definition tells me it is a Fulfillment Request item, I rather see it as a separate category in our tooling.


    Posted by Robert-Jan  on  10/09  at  05:25 AM
  8. Hi Troy,

    We are using BMC Remedy and it allows ‘service requests’ to take the route of incident management process. However, for ‘standard change’ we need to follow a change module. This has brought us to a discussion on how are these two different? We wish to do small request liking issuing mouse or laptop to new users as service request. However, as they impact our CMDB, change management team wants us to follow standard change module.

    Posted by .(JavaScript must be enabled to view this email address)  on  08/31  at  02:52 AM
  9. Hello Sunny, you are hitting on a debate the people who care about these things have been having for many years.

    For me in the days before ITIL v3 the Service Request was always a kind of baby change (standard change). This was further enforced in that Service Requests like on boarding a new employee usually required many parallel or sequential tasks to complete the full order / provisioning process. Several years ago the tasking engines were to be found in the Change Management module and not usually in the Incident Module of the tool.

    However, as time progressed several tools developed a shared tasking engine for all of the ITSM processes so this became less of a deciding factor.  The key is that your Request Workflow will have a pre-defined set of steps, activities, approvals, etc. and that they will usually result in updating some element of the CMDB or person record.

    Most tools today will have a separate Service Request module which is fed off some sort of Portal or Request Catalog.

    There is no right or wrong to your question but you could look at it like this. If the request impacts something that by your policy is stored in the CMDB then it can trigger a standard change from the Request Form. If the request is not going to impact something in your CMDB. EG. A mouse then it stays within the Request module or record for provisioning.

    Posted by .(JavaScript must be enabled to view this email address)  on  08/31  at  04:37 PM
  10. Page 1 of 1 pages






Remember my personal information

Notify me of follow-up comments?

Please answer the question asked below:

A, B, C, D, E, _, G, H. What letter is missing?