Follow us

Request Fulfillment: Keep It Simple

By | March 20, 2013 in ITIL

ITIL Request Fulfillment

So you've read the ITIL book, been on the course, copied and tweaked the diagrams in PowerPoint/Visio and you have a bunch of things you can loosely term as service requests or standard changes.

Surely translating that into a singing, dancing process is comparatively easy?


But the book says….

Well I am not going to spout out what the good book says here—people are capable of reading for themselves.

But what I will say is that the key to any process implementation is your adoption of the guidelines to suit your requirements.

But the tool can do…

I am a very strong advocate of the need to really understand what the requirements are before you even tackle process, tool, organisation and who is in charge of the coffee.

In fact I would go as far as to say—the tool does not even matter at this point.

But we have ALWAYS done it this way

The reason an organisation is looking to implement (or improve) an existing process has a business rationale attached to it—more often than not to save money.

That may be through outsourcing, it may be through more automation to free up skilled staff to help meet other business drivers, but rest assured there is almost certainly a [/insert currency of choice] value behind it.

How It Works in the REAL World

I am sure many of us have seen issues when trying to implement Request Fulfillment.

  • Over-complex steps involving too many people
  • Single point of failure in some steps where only one person knows how things are done
  • Approval process involving too many people
  • A desire to constantly add things to the service catalogue so that the latest "must have" is available, regardless of whether it can be supported (yes, I know, this is a whole OTHER debate)

There are several approaches that ITSM consultants Ali Hirji and and Jennifer Gianfrancesco have found to help, and they have been kind enough to share them with us.

Ali Hirji: ITSM Consultant

His Background:

Part of a consultancy group to put together processes and procedures required in dealing with requests from large projects to routine day to day requests.

This activity eventually led to the development of a technical request catalogue, used to formalise routine activities.

The client was unhappy in the way in which requests were made, and the time being taken to deliver them.

IT personnel had little control over the time spent dealing with request activity, and the management did not have enough data to help structure and plan their teams more effectively.

They also did not have sufficient information on customers/requesters in order to re-bill the costs of their efforts.

His Approach:

  • Understand the difference between the small everyday requests and the larger project requirements.

    Ali explained:

    "There was no structure at all.

    "As and when people wanted things, they were requesting them via telephone/email.

    "The delivery teams had little control over what came their way and therefore were not able to plan accordingly."

    His team's approach was to classify activities that were Business-As-Usual maintenance tasks, and determine which were the small requests–those that take less than 50 man-days to execute.

    The small requests were further divided into standard and non-standard requests.

  • Standard requests were something that the delivery team would be doing on an on-going basis, and were quite common.

    The execution scenarios would be quite standard, formalised and could be quite easily documented, if they had not already been written up, along with a defined set of parameters.

    As a result, the lead time and effort required to execute the request would be fixed and provided as part of the catalogue.

  • For the non-standard requests, the support teams were asked to list what they did, and they examined which of those could be documented formally and which parameters were collectable from the user.

    Ali said:

    "The aim was to have as many standard requests as possible so for non-standard requests , we would try and identify what factor was stopping them from considering it as standard.

    "We could then estimate effort and turnaround time based on that factor as a differentiator, for example the size of a database, therefore helping us provide a range of standard requests."

    Their first iteration of the catalogue was very simple with free text fields and a very basic workflow, to encourage use with the intention of further maturing the tool as it was more widely adopted.

His Challenges:

  • Changing the informal culture of the environment and formalising the process
  • Some groups were better than others at documenting
  • Sometimes thinking on too large a scale—needed to dissect into smaller activities and then break down how to execute and document on a smaller scale

Jennifer Gianfrancesco: ITSM Consultant & ITIL v3 Expert

Her Background:

Jennifer offered an insight to her experiences and also advice on Request Fulfillment process implementation.

Jennifer said:

"Set-up really depends on what customers are looking for and could be around two weeks.

"It depends on if there are a lot of customisations required."

Jennifer has also found that higher management of customers feel comfortable with additional consultancy to help extend their use of the system, when they are ready to use more advanced features of the tool.

Her Approach

  • A design workshop is a key exercise
  • Really understand how requests come in, what happens and what the dependencies are
  • Get them to understand the value of meaningful statistics—it is worth developing a set of "canned KPIs" as you gain more experience
  • The idea is to improve the process and identify gaps
  • Play "devil's advocate" in the initial sessions: How would the customer handle x if y happens?
  • Remember it is not just about the request activity involved; none of them work all by themselves: How are they touching other processes?

Her Challenges

  • When working with managed service providers, there is the added complication of additional SLAs and routing

    Jennifer explains:

    "Outsourcers look at it from a different perspective.

    "KPIs and metrics may be different for them than for in-house service management."

  • Balance the theory with the practice

    "Too many people get hung up on what ITIL says."

My Final Thoughts

Here are my key takeaways:

  • Regardless of whether the implementation is in-house or as part of a managed service, a pragmatic approach is key.
  • Work must go in to defining your starting point catalogue and focusing on what works well/needs no tweaking, and then look to where automation improvements can be made.
  • No single process works in isolation, so therefore workflows cannot be built in isolation of the support teams, who are involved in the steps.
  • Have someone involved who can almost act as a conduit between the “pure” process side, and the tool configuration side; if they understand the business rationale behind all this, then so much the better.
  • Do not be afraid to evolve from your starting point—that is really the whole point of ITIL deployments—to adapt, adopt and then to improve.
  • Once you have some of your basics right, then start to build your service portfolio.

The overriding sentiment from practitioners is: Keep It Simple.


Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.

Ros Satar

About Ros Satar

Ros Satar started out her life in ITSM tackling Configuration Management head on in 2005. Ros worked as an ITSM Solution Architect and Process Consultant before deciding to combine a career in IT with journalism, now working as a freelance ITSM Analyst and Consultant.
 

Leave a Reply

Your email address will not be published.

*

Subscribe now