Thursday, January 13, 2011

Turnaround Toolbox - Set Scope and Accountability for the team

Having explored what everybody thinks we should do - Expectations - and getting control of how folks engage us - Inputs - it's time to set the scope for the team.  

Scope includes all the tasks we do, products we deliver, and also what we're accountable for.

Tasks and Deliverables:  
For each task your team does and deliverable you produce, you need to know the Who, What, Where, When, Why, and How.  

Who on the team does the work?  If the task is one-deep, who would provide secondary, and tertiary coverage?  A lot of times you find these little one off items that one person knows about and knows how to do.  If it's going to stay in your box, you must be able to support it through vacations, resignations, etc.  Counting on a single person is an unacceptable risk.

What is the task?  Is it an operational procedure, document creation, external communication?  Categorizing the What of items makes it easier to organize them for documentation and assignment.

Where does the activity occur?  What you want to understand here is whether it's location specific.  Manning a teller window in a bank is location specific.  Creating a spreadsheet from a report can probably be done anywhere.

When and with what frequency does the activity happen - or need to happen?  You might find that you have tasks at a frequency that you're not staffed for.  For instance 24/7 operational monitoring without 24/7 staffing.  It might still stay in your scope, but with a different How component.     

Why do you do it?  Everything must be supported by a compelling reason - everything you do comes at a price.  Arriving at the cost can be difficult when nobody has to write a discrete check for the item, but it's important to get some idea.  Is it a good value?  Does it mitigate a risk?  Does it meet a contractual or regulatory requirement?

How is it done?  If we don't have documentation we'll need it - either to keep the task, or to transition it to a more appropriate home.   

A few words about accountability.  If it's in your box, you are accountable for it.  Given that, you want to make sure that you have control over everything in your box.  This means you must push out stuff where you're just the middle man.  Being the middle man is fine if you add some value and you limit your accountability to your performance as the middle man.  

The most important thing is that you do not want to end up accountable for things you cannot control.  So if your job is to predict or report on the sunrise - that's fine - if somebody expects you to control the sunrise - well that's a recipe for disappointment.

So, figure out what your team should do, make sure you can perform, and limit your accountability to things that you can control.

Thanks for reading - Mike

Tuesday, January 4, 2011

Turnaround Toolbox - Define, Limit, and Enforce your inputs

In the last post I talked about Expectations.  Today I want to talk about getting control of the inputs.  It's really hard to provide good customer service if you take requests via multiple, uncontrolled channels.  Think about trying to grocery shop to a budget with random people throwing stuff in your buggy at random times - you could probably keep track of most of it, but that ipod touch from the electronics department would be a painful miss when you got to the register.

We've all had experience with a lot of input channels - email, IM, telephone, one or more ticketing system, scheduled tasks, etc.  Any or even all of these together can work if you have a process in place to manage and track them.  Some organizations even take tweets now.  The key is getting control so that nothing falls through the cracks.

Define your inputs:

If you take email does it go to individual in-boxes, an organizational in-box, or a distribution list?  Who is responsible for keeping track of the requests?  How are items assigned?  Do responses come from individuals or from an organizational sending address?  What happens when somebody goes on vacation?  I am not a fan of taking requests via email because there are just so many cracks for things to fall into.  I get hundreds of emails a day and the signal to noise ratio is not very good.  But it might be a different story for you so if email works use it; you still must define how you are going to handle email requests.

Instant messaging  would seem to be an even harder nut to crack than email, in my experience IM provides a natural indicator for immediate requests - if I don't respond to your IM you can be pretty sure I am not working on your issue.  IMs don't work as well for problems that require more time or coordination.  Much like a phone call, once we quit talking, I am on to something else and your issue is a fast fading memory.

Phone calls - see IMs.  Good for immediate stuff but once we hang up it is over.

I like some sort of ticketing system something like Fogbugz that is easy to use like email but keeps track of ownership, history and related artifacts is nice.  Salesforce works as well as a lot of others.  It does not matter so much which system you use as long as you use one.  Ticketing systems give the issue a unique handle that people can refer back to, use as a license to work, and do reporting on.  Try to avoid multiple disconnected systems though.

Limit your inputs:


Only take requests via inputs you have defined and can manage.  This should be obvious but I can tell you from experience that it is not.  People that want stuff from you will use any path they can, but they will crucify you when their request falls into the Grand Canyon sized crack in the "interupt an ongoing hallway conversation to mention this little item" method of request input.  If you have a process for managing requests via Tweets, Email, Tickets, and Phone Calls then go ahead and takes requests through those channels - just don't take requests through Facebook Wall Posts until you figure out how to manage them to completion and get that defined for your customers and staff.

Enforce your inputs:


This is both the most difficult and most important, especially if the team has historically taken requests however they come in.  When you first start enforcing your inputs with customers it can seem like they're getting the run-around.  You want to avoid this by gradually moving from taking the requests as you always have to only accepting requests through the defined channels.  It's a journey.

At first I will start with some canned language that tells the requester how to get the best results along with a personal note that I have opened the request for them and here's the number for tracking purposes.  Say I get a request from a Sales Rep asking why Customer x was charged for Product y.

I'll send back something like:

Mary,

I have opened request xxxxx for you.  You can track it's status here [link to the ticket].  In the future please open a request by going to [some URL] and filling out the request form.  This will allow us to assign your request to the best resource and track it to completion.

Thanks,

On the next two or three requests from Mary I would send:

Mary,

For best results please open a request by going to [some URL] and filling out the request form.  This will allow us to assign your request to the best resource and track it to completion.

Thanks,

Finally, I would move to:

Mary,

What's the ticket number?

Thanks,

This is not really a science and I might also have a lot of phone calls and chat sessions extolling the virtues of the defined system.  It does work over time.

That's one half of the battle - the other half is getting your staff on board.  It going to feel like they are being unhelpful and wasting time because it's easier, quicker, and all around better to just dispatch the request then and there.

They're right of course for the ones they know about - the problem is the ones they don't notice and come back to you two weeks later as a "your whole team sucks" escalation.

I expend a lot of effort in the beginning trying to see what people are working on and how it came to them.  When I see somebody working on a proper request, I praise them.  When I see somebody working from a non-sanctioned request, I reiterate the need for using the defined inputs, and make them put the request in process.  It's a huge pain in the ass for both of us, but I know it will pay off quicker than expected.

A few words about ticketing systems.  Once you have a request in process it's fine to do some out-of-band communication to move the request along.  IM the requester for a clarification, pick up the phone, host a conference call.  Whatever works to help get the job done.  What you should definitely not do or tolerate is the deal where your customer puts in a request and then your team updates the request with something like "Need more information" and does not reach out to the requester.

Most people do not live in the ticketing system and will not continue to check status.  They will check on the day of the deadline and be pissed off that the work is not done - leading to a well deserved "your whole team sucks" escalation.

Defining, Limiting, and Enforcing your inputs will go a long way toward helping you meet the organizations expectations for your team.  It takes work, time, and discipline but the payoff is a smoother flow of work and many fewer complaints.

Thanks for Reading - Mike