How to appropriately balance project activities with support tasks

Question

I have a small team of experts (12 staff) who do great project work. Unfortunately, their expertise makes them the go-to individuals on support tasks as well. The inability to focus on projects affects their productivity and sometimes has a negative impact on morale.

Am I the only one who has this problem?

For those who manage small teams without the luxury of dedicated project staff versus support staff, what strategies have you implemented to ensure high morale and productivity and manage staff who feel like they are being pulled in a hundred different directions?

Answer 1

There is no easy answer to your question. You have to stand your ground and protect the team for unneeded interruptions.

This is a very common symptom of small companies making wrong decisions. Some of the tips below I have implemented myself in various scenarios with good success. Before I start, I have to say that perseverance is the key.

Now let's begin:

1. Set a rotation for the staff that will be available for support questions that day/week/month. All questions will be routed through them, no matter what, the rest of your team will be heads down and the only people able to interrupt is you, and the staff in support. Explain your entire team that they need to be team players for this to work. Try to be fair on the rotations for support.

2. Make early meetings, with the hottest tickets in the queue. Try to make sure, all the sales and client advocates are in these meetings, and do not bring the IT people. Remember that by virtue they will always want to be heroes.

3. If you have a ticketing system, try to set a support queue that everyone is able to see. If you have someone ahead of schedule in any given task, encourage them to take a ticket. You will probably need some kind of award system for this to work.

Morale is a hard thing to get back, keep trying and you will have success.

Answer 2

We implemented a single point of contact for support, and the job is rotated amongst staff every week. So they know they have to do support for one week, but after that they can focus on their project work until it's their turn again. Sometimes there is too much support so other team-members have to help as well, but most of the time this works fine. The devs are happy with this arrangement.

Answer 3

While support issues can be a distraction, it's very important that the development team personally handle these issues for the following reasons:

• The developers can fix the problem once and for all. See Joel's Article on Customer Service

• The developers will learn more about the users of the product and be able to improve the product so that they're actually building something that people will use!

In my answer to the question How to Get Management to Allow You to Deal With Technical Debt?, I mentioned that my boss at the time didn't want to be involved in it. He said that should just be considered part of the estimate.

As a project manager, you and your team are the experts. When you give your estimates and timelines to your managers, it's up to you to include support issues in your estimates, as they're a necessary part of not just learning how the software is being used, but also making sure the developers fix the problems once and for all.

Answer 4

You can use a few strategies here (possibly all at once as they address different issues):

1. Manage incoming stream of maintenance/support tasks. If support tasks are dealt over the team with no control they tend to ruin team's productivity. However you can mix them with other work to let people know where they can expect to work on a new project and when they will be supporting old stuff. If you work with a task board with small tasks you can put support tickets into todo column (or however you call it). This should work for every but critical issue. You can also let people set their own support time everyday, e.g. after lunch, and let them deal with support stuff then. Specific tools will depend on specifics of the situation but basically everything which organizes stream of support tasks better should help.

2. Isolate (significant) part of the team from interruptions. If possible allow people to be isolated from support buzz so they can focus on other work. It doesn't have to (and shouldn't have to) be full time isolation - people should be expected to share the pain. However it doesn't mean they have to be faced with random phones regarding some common piece of application. You can organize some kind of 1st line of support - a point of contact where every issue comes and is verified before people are interrupted. Also if you work with experts people working as 1st line of support can try to solve the issue even if they aren't the best option and ask for help only when they struggle.

3. Make the problem owned by the whole team, not just a few individuals. This one is about morale. If some people aren't involved in the support stuff at all you ask for some issues in the team. There will be roles considered as better and those which are considered worse. You can delegate a few people as your full-time, long-term support team but I believe some rotation helps much here. It can be either on task-by-task basis (see point 1) or some time-related approach (weekly/monthly/quarterly support duties). Either way make people aware everyone is expected to help.