How to appropriately balance project activities with support tasks

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.

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 http://www.joelonsoftware.com/articles/customerservice.html 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 http://programmers.stackexchange.com/questions/43948/how-to-convince-management-to-deal-with-technical-debt/43967#43967, 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.

You can use a few strategies here (possibly all at once as they address different issues): 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. 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. 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.