Your responses to a terrible service delivery example
In my June 21 post titled, “Responsiveness and Service Delivery: A Terrible Example,” I turned to you for help on how to address a persistent issue that all IT leaders face — managing work queue requests in a timely yet responsible manner.
For those of you who didn’t read the article, here’s the e-mail that sparked the discussion — it’s a response a client received from a business partner (vendor) after trying to get information about whether a certain project could be done and, if so, by what date.
Dear Jack:
After some discussions with our IT department, it has been decided that I need to submit a formal “Business Request” (BR).
What this means to us is that IT will need to size the change and submit a price and time estimate. It also means that the process has been taken out of my control and therefore I can no longer guarantee that I can get as timely a response.
The normal process for our IT department is to meet once per month and gather the BRs they have received and talk through the pricing estimates. If the business decides that they are willing to pay the price IT has given us, then the work goes into the queue to be scheduled.
The project is placed in the queue based on a point system, which weighs importance, level of complexity, and the resources required to work on the project and their availability.
At this time I cannot guarantee that I can meet your timeline.
Tim Braverman
Director – Customer Analytics and Reporting
XYZ Corp.
I asked for your comments and in particular your recommendations on what might be done to improve the service delivery process used by Tim and XYZ Corp.
Where we all agreed
Everyone recognized that Tim’s response was far from ideal. At the same time, there was a strong consensus that a request management process is necessary; that without a standardized method for estimating, approving, and scheduling work, things just don’t go well. Clearly, IT organizations need to have a process in place to prioritize service requests from the business.
So we’re left with the question — “What can be done to improve XYZ Corp.’s service delivery process?” Here are the best of your ideas.
Suggestion #1: Leave the process alone, but give Tim an attitude adjustment.
In short, it’s Tim’s communication skills that need addressing, not the process. One reader commented, “It’s the response that sucks, not the message.” Had the request been handled more gracefully and openly, the issue probably would have never made it to my attention. (Personally, I’m not convinced, but I hear ya.)
Suggestion #2: Establish an informal process to go alongside the formal one.
To address this type of important request, it was suggested that XYZ create an informal estimation process to exist alongside the more formal one. The main purpose would be to allow for a more “human” and “natural” response to a high-value customer.
The idea here is not to supplant or subvert the “official” process as it moves along, but rather to make sure the right people who care about these types of big requests are aware of what’s going on and can lend a helping hand to the official process.
One reader commented that Tim should have gotten out of his chair and walked over to some of his colleagues to briefly discuss a rough estimate for Jack. If he had, Jack would have walked away from the situation with the information he needed, and more importantly, felt like the IT group was on his side because Tim short-circuited the process, just a little bit, on his behalf. (Now this idea I really like!)
Some of you even recommended creating a back channel for senior business folks to escalate the most pressing requests. In other words, a VP-to-VP request process. This would allow critical service delivery requests to sail through (or over) the more formal parts of the process.
Allowing an informal process is not to suggest consistently circumventing the formal process, rather it’s about enabling the IT personnel to bend the rules, not break them.
Suggestion #3: Beef up the current process.
How could a request from an important customer get handled so poorly? One logical answer: No one in IT realized that was the case. I know it’s hard to believe, but it does happen, quite often in fact, especially in large organizations. And it seems like more than a few of you have seen this as well, because the most common suggestion I received was to beef up the current process through improved information collection and presentation.
In other words: put a very strong form on the front end of the process that would force the requesters and IT to see the request for what it really is — a high-value customer project. Then, based on the early visibility into the project’s importance, the request would automatically be handled appropriately. (This, of course, assumes the creation of a rapid handling process for high-value requests, but that’s not too big of an assumption to make.)
One reader correctly pointed out that an additional benefit of a strong front-end information collection phase will, over time, make the users “better at thinking about project requests the same way IT does. Before long, the users will be pros at articulating needs, budget constraints, and timelines, and the process will flow a lot smoother.”
Suggestion #4: Supercharge the current process.
The last major suggestion: Change the process and accelerate throughput. Following a comprehensive triage, on items such as customer type, revenue opportunity, complexity, time, and so on, the request might either be assigned to a specialized individual or dispatched to a SWAT team that can process it more rapidly and more specifically than the general IT project request team. Similarly, some recommended an escalation process where specific requests can be tagged as high-priority and moved right to the top of the stack.
Best of all
All the ideas above are good ones. But frankly, the best part of this little exercise was that no one recommended the implementation of a system for work queue management, but instead everyone stayed focused on a business solution through process changes or alterations — a welcome change to the way us techies usually approach a problem.
