Changing How We Address Web Projects And Help Desk Tickets

If you know me then you know I'm always looking for ways to do things better. Sometimes, that search allows me to go forward and then other times it's a step backwards. At work, it's no different. Although, I wonder if the people around me ever get tired of my incremental changes.

What am I talking about today? you ask. Today, I'd like to share my latest plan. First, a little context.

Historical Context About The Job
During the day, I serve an institution of higher learning as their IT Manager for Web Services. I have a team of three developers for the entire campus. Yes, you read that correctly.

For much of my career in web development, the amount of resources always seems less than what is actually needed to achieve maximum results. Although, that doesn't stop me from trying. I just make do with that we have and keep things moving.

To the disappointment of many, especially those with caviar dreams, living on a shoestring budget allows for very few luxuries. One has to carefully consider where, and how, to invest the resources in order to get things done. Frivolous requests often fall on deaf ears.

In higher education, my team constantly manages the fine balance between wants and needs. If departments could have their way, each one would have an entirely different web page design with beautiful glossy pictures, custom video, flash, and millions of visitors. Unfortunately, the reality is far less glamorous. Without resources (people, time, money, etc.), difficult decisions are required and concessions made. It comes with the job and I love the challenge.

Problems With The Current Process
At present, I'm finding a slight problem with how we're handling new web projects and happy-to-glad changes. Currently, all requests come to us in the form of a ticket. As a result, my team often reviews the help desk for requests to build new applications, update content, improve designs, and everything in between. At the end of each request, we close the ticket and move on to the next item in the list.

While it sounds easy enough, closing a ticket is often a multi-step process that can easily spiral out of control. Let me explain.

With each new ticket, someone has to review the request and determine if it can, or should, be done. Assuming the task is approved, resources are then aligned to execute the assignment. Once complete, the developer reviews the finished product with the client and closes the ticket. However, we find that many tickets are not clear or lack enough information to complete the request, which can lead to a game of cat and mouse. "Where's my website? Where's my content?"

Additionally, during the review session, either the developer failed to complete the task according to instructions or the client realized what they received is not what they wanted. That leads to a spiraling process of "moving furniture." That's where you move it an inch to realize it's not right. Then, in an effort to fix the problem, you move it to another place. Rinse and repeat as many times as necessary.

At the end of it all, you realize that no two tickets are the same and it's extremely difficult to estimate how long one ticket will stay open. We do our best.

As manager of the team, I find myself focused on enhancing quality of work, timeliness of tasks, relevance to the university's mission, and effectiveness of suggested solutions. It's important to fulfill the request but it's equally important to do it right.

As of this post, we probably have around 40 something tickets in our queue. In the past, we've had as many as 200+ tickets awaiting our attention. While I don't like having our customers waiting, we can only do what we can with what we have.

Changing The Help Desk Process 
As I look at the growing number of tickets, I'm asking myself how might I improve the process? How can I balance quality, efficiency, effectiveness, relevance, and still be on top of it all?

My latest plan is to adjust our current strategy to include more delegation and client vetting. It also involves separating new creative projects from the happy-to-glad content changes.

As manager, I don't need to sit in on every request. Some of the happy-to-glad tickets can be vetted by the client. A job's not done until they're happy with it and for simple content changes and updates, I'm fine with that. However, for the more creative and solution based projects, my attention is required. At least during the early strategy planning stages.

So, during our last few hours at work, the team and I adjusted our current production strategy to include the following:

• Management will review all incoming help desk tickets and project requests.
• Depending upon the nature of the request, management will either schedule a meeting to discuss the project or assign happy-to-glad changes to the team.
• For projects, management will stay engaged until the plan of action has been established and executed.
• For happy to glad changes, management will yield control over ticket and allow team and client to work it out until closed.
• Management will schedule initial workload of project tasks and happy-to-glad requests, but the team will manage their own calendars to determine review sessions with client.

We believe this small change will allow me to navigate the more variable projects and tasks by applying best practices with relevant strategies. At the same time, the team can be more timely and effective with the day-to-day, run of the mill, tasks.

As with most changes, I don't know how effective it will be, but I'm willing to give it a try. If you are currently doing this, or have done something like this in the past, I'd love to hear about your experiences. If you get the chance, leave me a comment below.