One common challenge I have observed during ITIL service catalog implementations pertains to the handling of out-of-band requests. That is, how should one manage a request for a service that is not in the catalog?
Non-IT Analogy
I am an American of Italian descent who was raised in an Italian neighborhood in Brooklyn, NY. As such, I was accustomed to variety of authentic Italian foods. Years later, I relocated to Tampa, Florida, where there were few authentic Italian food stores. After some time, I found a local delicatessen where the owner had grown up in the same neighborhood as I had, and had everything I was accustomed to eating. We built a friendship and I became a good customer.
One day, I entered the store and asked for one of my favorite sandwiches - pepperoni and provolone. The counter person, a local who was not from the old neighborhood, looked at the sandwich board, which contained sandwiches named after famous American actors (e.g., The Bogart). Pepperoni and provolone was not an option. He proceeded to tell me that he could not provide me with that sandwich. I looked into the deli showcase and both pepperoni and provolone were available to be sold as sliced cold cuts. Therefore, I argued with him that he should provide me with my sandwich even though it was not on the sandwich board. He informed that he could not do so.
The argument grew loud and eventually the owner emerged from the backroom and asked me what the problem was. I explained our dilemma and he instructed his counter person, "Mr. Bucalo is a good customer. Make him his pepperoni and provolone sandwich and charge him the same as the "Bogart," which was made with salami and provolone. Thus, the conflict was resolved and a good customer was retained. A week later, I entered the store and looked up at the sandwich board to see a new entry - a pepperoni and provolone sandwich - aptly named "The Bucalo."
Applications to IT
So it is with providing IT services. It is highly unlikely that your service catalog is exhaustive in terms of services that your customers want. Even if it were, it is unlikely that you would not encounter the need for new services or the need for new service bundling options (as was the case with my sandwich) as technology evolves. Indeed, if you do not provide a mechanism for dealing with out-of-band requests, you might be perceived as a bottleneck to corporate and business agility. The derogatory phrase "You must be in the IT prevention department" comes to mind. Therefore, you should be prepared for dealing with out-of-band requests. Moreover, you should embrace them and consider them as opportunities to evolve your service offerings and please your customers.
Anti-Pattern Use Cases
We have seen two extremes for dealing with out-of-band requests that have proven to be ineffective or inefficient. The first is to "Just Say No," as was the case outlined in the aforementioned deli scenario. That was the case with the counter person above. You see that the "Just Say No" response is potentially detrimental to the customer relationship and may prove to be unreasonable. In your organization, "Just Say No" could bring the business to its knees, sapping productivity when non-standard but legitimate service requests are made. The second extreme is to take every out-of-band request and create a standard offering to satisfy it. Let's say that a customer needs a special bracket to secure their blade server but that is not in the catalog. Just imagine the time and effort required to define the service offering, update the catalog, fulfillment and other processes, and the documentation to incorporate what might be a once-off request. That clearly represents an inefficient use of human resources and will quickly clutter your catalog with a lot of "noise," making it a burden to use and maintain.
A Flexible Policy
A typical service lifecycle includes the service catalog definition as an ongoing effort, triggered by time events (e.g., quarterly review) and business events (e.g., acquiring new customers, renegotiation of service offerings for existing customers). I recommend adding out-of-band request events to the mix. Keep reading for specific suggestions.
An Abstract Process
You need an abstract process in place for managing out-of-band requests. By abstract, I mean that the process by its very nature needs to be vague (Who knows what they'll ask for?) and will probably be human intensive because humans are good at abstract processing. Machines are not. This is in contrast to standardized service offerings, where services need to be defined as concretely as possible in order to facilitate automation. However, keep in mind that out-of-band requests should be rare, and might prove to be one-off requests, so this abstract process should not prove to be inefficient.
The Process Described
The catalog should provide an offering called "Other Service," "Adhoc Service," or "Unlisted Service" so that service requesters can intuitively pursue their needs. That catalog offering should trigger a generic request form, where free form information can be captured along with the service requestor information. The request should then be routed to a service catalog request administrator for initial triage. They might discover that the request matches a standard offering or a combination of standard offering components. In the event that the request can be mapped to existing catalog entries, the administrator can collaborate with the requestor to formulate a standard request to replace the out-of-band request and the process ends. Otherwise, the request, enriched with specifics, might be routed to a customer service representative or a business service manager. Their job then becomes to contact their counterpart at the customer organization to negotiate the service instance.
For example, it might be decided that this request is close to other similar request items, so it can be satisfied using those items as a template. In the event the new service is large, expensive, or has other extenuating implications, it needs to be routed to executive level personnel who have sufficient decision making capabilities. Your policy should contain guidance on the individuals or groups involved and guidance on making routing decisions (e.g., cost thresholds). Similar abstract processes and policies would be required for service fulfillment and billing. Finally, after the out-of-band request is managed in real-time, the request should be routed to the standard service catalog definition process, where it can be determined if this request should be standardized or not.
Use Case 1: A request to install an instance of a non-standard commercial database due to a business preference.
This use case assumes that the company has standardized on commercial database "ABC" and the deployment of instances of database "ABC" is in the catalog. (This assumption will carry through the remaining use cases.) The request is to deploy an instance of commercial database "XYZ."
During triage, the catalog administrator discovers that the reason a non-standard commercial database has been requested is because the department making the request has hired a consultant to build an application and the consultant prefers to use that type of database. Deeper analysis discovers that the application has no need for any special or unique functionality that database "XYZ" provides. In this case, it makes perfect sense to politely say "no" while showing your customer that their needs are completely satisfied by database "ABC." Moreover, you might want to communicate to your customer that their costs will remain in check because you already have an enterprise license and expertise for database "ABC." Using this approach maintains customer satisfaction while at the same time enforcing your database governance.
Use Case 2: A request to install a non-standard commercial database due to security requirements.
This is a case I have recently encountered. This organization received a request for non-standard database "XYZ." But in this scenario, the reason for the request was because it had been discovered that database "ABC" had a security issue, and that the vendor refused to provide a patch - instead requiring the business to perform an expensive upgrade to resolve the issue. Further analysis found that this request is the "canary in the mine shaft" and this issue will soon pervade your organization. The correct response here would be to contact vendor "ABC" to let them know the cost of upgrading X hundred database instances will be severe, especially given the fact the change management processes for upgrades are very extensive as opposed to the application of a patch. You might review your contracts to determine if the database version in question is still supported and if patches are required as part of that support agreement. Based on the results of this analysis and discussions with the vendor, you might have to redefine your services. If you are entitled to the patch, then you might create a "Patch ABC Database" service (assuming that the service doesn't already exist). You might have to provide an "ABC" upgrade service. Or, in the event that you decide to phase out database "ABC" in favor of database "XYZ," you might have to create a set of parallel service offerings for database "XYZ" in preparation for the corporate change.
Use Case 3: A request to install an instance of a MySQL.
The request comes in for a Data Base Administrator (DBA) to install an instance of MySQL. Oh, by the way, this request is the result of the need to support a Commercial-Off-The-Shelf (COTS) package that the CEO has selected and it needs to be up and running by Tuesday! Analysis of this use case indicates there is not a large expense (since MySQL is freely available), there are huge political consequences for saying "No," and there are analogous catalog offerings that can be used as a template for billing an installation of the standard database or an hourly DBA rate, for example. Therefore, as a catalog administrator you might route this request to the database team with instructions to go ahead and perform this installation by Tuesday. There is no indication this will become a recurring request, especially since it conflicts with the enterprise architecture standard, so it would most likely not warrant the time and effort to make this a standard offering.
Use Case 4: A request for a temporary database instance with extensive storage requirements to be used for a short term, high volume, data cleansing effort.
The project needs to go forward quickly, but has limited funding. In this scenario it may be wise to consider the use of a database software-as-a-service (SaaS) option. An external vendor might be able to quickly provide the software as well as the Infrastructure-as-a-Service (IaaS) at a reasonable rate for the time period required. Because the project must go quickly, the catalog team would be wise to identify a vendor and negotiate a quick implementation with the database vendor. It is important that the vendor can guarantee, in the form of a service level agreement (SLA), sufficient security and sufficient performance to fit the project and data requirements. Given that the use of the cloud service model represents a growing service option, it might be wise to define a series of internal catalog offerings that correspond to the service offerings of the cloud vendor. It might also be wise to determine if providing the service internally is a cost effective option. Such a decision would clearly require the involvement of senior management.
Summary
Out-of-band service requests will happen. In fact, these events should be embraced since they provide valuable inputs to IT management processes and can provide an opportunity to enhance customer relationships. Ultimately, it is imperative that an effective and efficient process is put into place to manage them.