Failure to respond is not an option!

Have you ever worked with, or depended on, a IS/IT group that simply did not live up to your expectations completing routine, and in some cases important, work requests. Well I can relate as I’ve assumed leadership responsibility for two such teams throughout my 25+ years as an IT leader and have found an interesting solution that I would like to share with you here today.

The story begins with a group of Oracle/SQL Server database administrators, four of each, that were constantly being bombarded with work requests from all angles – ticketing system requests, emails, walk-ins, phone calls, text messages, etcetera. Normally this would not be a problem, but when you factor in that the team is part of a matrix managed organization with infrastructure support responsibilities, project work, break/fix, and special projects, then failure to respond to routine and important work requests quickly becomes the norm.

Confronted with the reality that routine and important work requests were continually falling through the cracks, I solicited feedback from the team on how to solve this vexing problem. The idea the team came up with, while somewhat simplistic, addressed the issue and then some, without costing the organization any money.

The team’s idea – leverage Microsoft Outlook resource calendars and allow internal/external customers to schedule work requests for specific dates/times and establish a weekly on-duty schedule for one database administrator per platform (Oracle/SQL Server) to complete all scheduled work requests without any infrastructure support, project work, or break/fix interruptions.

I liked the team’s idea, decided to give it a try, and before I knew it routine and important work requests were being completed on-schedule and incomplete work request complaints became a thing of the past.

An overview of the “Scheduled Work Request” process follows –

1) Create generic Microsoft Outlook mailboxes (e.g.: PSTORA1, PSTSQL1).

2) Assign delegate rights for generic mailboxes to DBA team members/manager.

3) Create auto-forward email rule for generic mailboxes to forward requests to entire team.

4) Establish weekly (rotating) on-duty schedule for DBA team members.

5) Inform organization to schedule work requests as meetings and invite generic resource (PSTORA1, PSTSQL1) as needed.

That’s it. Once the five items above have been completed, then routine and important work requests start flowing in as scheduled events on a dedicated Microsoft Outlook calendar and the remainder of the “Scheduled Work Request” process flows like this –

1) On-duty DBA accepts scheduled work request (meeting invitation) in Outlook calendar.

2) Requester automatically receives an email and knows who will complete the request.

3) On-duty DBA completes the request on the specified date/time and notifies requester.

The “Scheduled Work Request” process occurs seamlessly in a closed loop and provides full auditing/tracking of all work requests with a permanent record of who requested the work be performed, who completed the work, when the work was completed, and how long the process took.

The end result is a satisfied customer and a happy DBA team who no longer have to worry about overlooking routine or important work requests. And, as a side benefit, each DBA gets the opportunity to be on-duty once per month with exposure to all work requests while the remaining three DBAs get to focus on infrastructure projects, project work, and break/fix without any interruptions.

The “Scheduled Work Request” process may seem over simplistic, and it is by design, but it works. Give the approach a try where you work if you are confronted with a similar work request management dilemma and let me know how it goes.

Join the conversation.

-Tech Talker