Saying No (Even To The Business)

Many of the posts on this blog have focused on enabling the business and keeping the business in mind as we carry out Support tasks. So, you might find it strange that I'm dedicating a post to saying "no" to the same business users we purportedly help. Let me provide an example where I've directed my teams to say no to the business. But note how we did it and whether you agree or disagree.

One of the managers that reports to me brought up a concern. His team, for historical reasons, had been helping the business with even the most menial of requests. He was trying to determine how to stop these types of requests as they were robbing his team of valuable bandwidth that could best be utilized for more value-added tasks. For example, they would get calls from business users asking them why their printer wasn't working or asking them to reset their LAN id. There is a helpdesk that manages these requests, yet they were reaching out to Support to work on these tasks.

I asked him to put a meeting together with the business department head so we could talk about these requests. Ahead of the meeting, we prepared a couple of slides identifying Support Effort and where it was going. We determined that about 10% of our total Support bandwidth was dedicated to servicing menial requests that the business users should have been able to handle. We also identified various areas for improvement that we would otherwise be able to accomplish, were we not spending time, say, fixing printers.

The meeting came and we presented our case to the business partner. He was in total agreement that we should be spending our time doing things like automating manual tasks or adding better monitoring, rather than resetting passwords or clearing out blockages in a printer. We asked if he could send us an e-mail with his expectations around which items we would no longer be servicing.

When the next request came around, we responded to the business user that they should contact the help desk and we provided instructions on how to do so. We also attached the e-mail from the business head explaining that we would no longer be working on such requests. Some of the users were less than thrilled, of course. However, they eventually understood the reasons behind our inability to service those requests. Eventually, the requests stopped.

In servicing the business, we have to realize that our bandwidth comes at a premium. And it's actually in the business' best interest to have us focus on value added tasks. It's important to maintain our posture as a group and not become a dumping ground for issues that people would just not rather deal with. In this scenario, we made our case, and actually showed the business that they were better off by us not spending time on these requests. As paradoxical as this sounds, this actually helped us support them better.

Who's issue is this?

One of the things I try to challenge my teams with is following through on issues and user inquiries. There are many times when issues come our way, just to find out that it's really within the scope of another team to correct or address it. This can happen for several reasons. For example, from experience, a business user has determined that your team provides the best turnaround time on issues. It could also be that the documentation on whom to contact might be unclear and the business users goes knocking on the first door she finds.

In many cases, I see teams simply forward the e-mail or ticket along to another group. A lot of times, the e-mail or ticket won't have full documentation on timeline, impact, history, etc. The team receiving the e-mail or ticket might not react with the right level of urgency. In fact, I've seen issues go on for days like this; being passed from one team to another. In the meantime the business user just waits in frustration.

A better approach to prevent long running e-mail threads that lead nowhere, is for the receiving team to follow through on the issue, as if it were their own. In my opinion, if the business user sends an issue your way, you should own it to completion. Instead of forwarding the e-mail or ticket, get the right team(s) on a call, and ask the right questions. Communicate the right level of urgency on that call as well. Just choosing the right forum (phone call versus e-mail) can help significantly cut down on the turnaround time.

Once you have an answer, personally deliver it to the business user. Don't expect other teams to do it. They might not have the same finesse and level of service that you have. Remember, you always want to keep those business users delighted.

Many teams will complain that they don't have enough staffing to personally handle each of these types of issues or inquiries. I would challenge that assumption. Many times, we spent more time fighting fires and explaining bad results than it would have taken to just manage the issue to completion. Guess who the business user will complain about if the issue doesn't get addressed on time?

So skip that coffee or tea break if you have to. Challenge yourself to provide your users the best service possible. They'll thank you for it and your organizational growth will, indeed, reflect it (so will your bottom line).

Be a Part of the Solution: Be a Hero

Remember the purpose of Production Support? There are several things that we should consider doing, as individuals, in order to accomplish our purpose as a Production Support team:

1. Being flexible. I once knew a Production Support manager who's contention was that Production Support teams are "gatekeepers" of Production. This is a true statement. What wasn't true was his contention that any release that went into Production had to follow the Production Support procedures to a tee and that if the Development team didn't follow them, the Prod Support team should push back and delay the release. Does this meet the goal? The answer is no. Though we all want a perfect world, sometimes we need to be flexible in order to get to the goal. If the business needs a new feature urgently, to take advantage of a market opportunity, is it reasonable to expect them not to make money because Production Support didn't have all the documentation checked off? I don't think so. As with many things, finding the right balance between due diligence and meeting business objectives is an art.
2. Raising our hands. In all companies there are two types of people: those who do and those who don't. You've seen the ones who don't. They have an opinion about everyting in meetings. They're experts at letting you know what shouldn't be done and not what should be done. They're great at telling you that your approach won't work, despite evidence to the contrary. But when it comes time to do the actual work, they vanish. I always encourage Production Support team members to be the doers. All that stuff that no one wants to do, but which is important should be something that we should be willing to do. If our aim is to meet our purpose as a Production Support team: do that break-fix even though your stated SLA says you only do Level 2 Support, manage that special project which really should be done a different group, answer the call when someone asks in a meeting who will do the work and you hear silence. Remember not to argue over who's going to do it, as that takes more time, energy and money sometimes, than actually doing the work.
3. Doing the right thing. Many times it's difficult to do the right thing, especially when the number of issues has been high and you feel mentally and physically fatigued. At times, some of the most rewarding work can come when you push yourself a little and you do those things everyone hates doing. For example: clean up that monitoring system and find a way to remove that false-positive alert instead of just clearing it; create that ticket in the system even though the issue is already fixed; run that report and evaluate trends to make sure that the system won't run into issues. The more disciplined you are at doing those little things everyone hates doing, the easier the work will become for you and your teammates.

So be daring. Be a part of the solution, not the problem. Enable your business. In short, don't be afraid to be a hero.

Follow The Sun Success: Handovers

According to Wikipedia, Follow-the-Sun, is a type of global workflow in which tasks are passed around daily between work site that are many time zones apart. The idea behind follow-the-sun is that work will never stop.

Though evidence suggests that Follow-the-Sun Software Development doesn't work, this is not the case for Production Support. Follow-the-Sun can and does work, if Prod Support teams are willing to implement a few best practices to enable collaboration.

In the shops where I've worked, the most common setup is to cover 12 hours out of AMRS and 12 hours from India. Typically each region has an early (8:00 AM - 5:00 PM) and a late (11:00 PM - 8:00 PM) shift. The shifts are modified for Daylight Saving Time adjustments. Another common setup is to cover 8 hours out of AMRS, 8 hours out of APAC and 8 hours out of EMEA (where there is overalp between the shifts).

The most important process that teams need to implement, is likely the Handover process. During the handover, the accountability for the work transitions from one region to the next. There are two items that make handovers successful, in my experience:

1. Handover E-mails: Handover e-mails should contain information about open Incidents and Service Requests. They should also contain a recap of significant issues that occured during the shift, for example: Major Incidents or preventive restarts of running processes. Handover e-mails ensure that a snapshot of the work being handed off is captured, which provides better insight into accountability.
2. Handover Calls: Handover calls should be short (about 30 minutes) and should be utilized to cover the open tickets being handed off. It is a forum to allow for clarification of what needs to be done. It is NOT a forum that should be used to work on the tickets. Handover calls should start and end on time and should have enough representation for each ticket being handed off. During the handover call, tickets should be reassigned to people in the upcoming shift. At no point should a ticket remained assigned to people in the shift handing off, as accountability is lost and the work won't continue on it until the following day.

Another best practice that enables follow-the-sun success for Prod Support is that of implementing Start and End of Day Healthchecks. At the beginning of the week, a start-of-day check should be carried out to ensure systems are ready to perform business transactions. Then, at the end of each shift, the team receiving the system should carry out health checks to ensure that everything will run smoothly during their time. I find that doing it this way works better (than the team handing over doing them) for two reasons: 1) The team just starting is freshly rested (and isn't ready to run out the door) and 2) The team just starting will have the accountability for any issues (thus they are more invested in things not going wrong).

Start and End of Day Healthchecks should be documented. A summary of the checks performed and the results (perhaps with a Red/Amber/Green status) should be sent out to interested stakeholders to ensure that everyone is aware the system is ready. It's worth noting that healthchecks can be automated. If they are, the team receiving the handover would be responsible for correcting any anomalies the healthchecks might reveal.
Following these simple guidelines is easy and will work wonders in ensuring your Follow-the-Sun success!