Forums

My team provides technical support for internal clients – basically an in-house legal department. Tasks flow into the team from a variety of different internal clients.

My team has developed a reputation for going above and beyond. We want to keep that reputation. Team members do not like to say no. They enjoy being experts.

But we are becoming victims of our own success. The workload is increasing dramatically. Burn out and turn-over are likely. I must find a way to manage our response to the inflow of work.

Each of our internal clients sees only their own tasks and naturally believes them to be most important. Some clients try to take advantage of our expertise and have my team do their jobs for them. Some tasks are important to the requestor, but not so important to the overall mission of the organization. My boss appreciates the team’s contribution, but she came from a different area – no “gut” feel. No additional resources are immediately forthcoming.

How can we decline requests and maintain good relations with our clients? How can we get our clients to request only important tasks? How can we get our clients to support our requests for additional resources? Please share techniques you have found effective.

[Assume that I’ve done everything possible to manage within the team. We are as productive and efficient as possible. I’m sure that’s not true – but I want to focus the question.]

Thanks!

danstratton's picture

I don't think you want to say "No", but instead "Yes" with a timeline. A valve at the beginning of the cycle allows you to control the flow into the process and lets things collect in the hopper.

In other words, someone on your team needs to take the responsibility (usually the manager?) of regulating the order in which the work is done. You have to stop the flow from many different sources into your people and instead of it flow from one place so people feel comfortable and controlled.

Have all the requests come to one person and have them sketch out the requirements and give an estimate. At that point, the customer knows the "cost" and a potential start date. Perhaps from there a priority needs to be assigned so that it can be evaluated against the other requests. At that point, there is a queue waiting for the team in priority order so they are working on things that are most important first. The customers have an estimate of when work will start and when to expect it. Conflicts in priority can be settled by calling the two parties together to discuss and resolve.

Does that make sense?

PierG's picture

bapeters,
I live in the same condition: our backlog is growing no matter our effort.
We use to always track requests and ask, in periodic meetings, to keep this backlog in priority order. And then we attack high priorities tasks first giving very precise scheduling.
Do we succeede in making them totally happy? Probably not, but at least we communicate a lot with them sharing as much as we can.
In the agile space we say: customer collaboration over contract negotiation ... that what we are looking for.
Hope this helps.
PierG

mauzenne's picture
Admin Role Badge

PierG is correct; communication is key.

Dan is also correct in that prioritization is critical. In my experience (running a large PMO), the service provider (YOU) shouldn't be the one doing the prioritization.

Why?

1) You don't know their business (at least THEY think you don't) and any value you place on their request will most likely be perceived as wrong.
2) If you prioritize, you end up being the bad guy -- the person that says "no". Not fun.

Let the "users" set the priority. Of course, you have a number of different customers ... form a prioritization forum, invite the key stakeholders, develop a methodology/protocol for setting priorities, and then let them argue *amongst themselves* on what the priorities for your group ought to be. Then, based on those priorities and your organizational capacity, you commit to deliverables. [By the way, it's pretty cool when the other stakeholders (not YOU) refuse to even add the request to the list because the requirements aren't clear or the business case solid. That's when you know you truly have arrived. ;-) ] In the end, you own the process for setting priorities, but not the priority setting itself. A subtle distinction that makes a night-and-day difference.

Of course, the next argument becomes one of what your capacity should be, but that's another discussion ... ;-)

regards,
Mike

PierG's picture

Mark,
I agree 100%! It's a key that's the 'user' to put things in priority!
PierG

bapeters's picture

Excellent feedback, friends.

My clients are my peers and their employees. Our boss pays my “bill.” In this arrangement, each client is used to getting "unlimited" service for "free." It may be a challenge to convince them now to "pay" for the service, even if that payment is simply to participate in a prioritization forum.

The idea of involving my clients in the management of our intake is great. It would be a radical change for them acknowledge that the resources of my group are finite. (It’s hard for us, too – we’re lawyers, and lawyers don't like to admit to any limits.)

We have maintained a task list, and prioritized it. However, up to now, we've had no way to schedule the projected time these tasks will take to complete against the theoretical time available to complete them. Conceptually, this task/priority matrix sounds like it could be effective, but it will be a challenge to implement. Our tasks range from simple 15- minute helpdesk questions to multi-hour projects that extend over several weeks. We may need a software application to do all the scheduling and communicating – any suggestions?

Johnnywmt's picture

bapeters,

Apparently we both started a thread about setting priorities within minutes of each other last Saturday -
[url]http://www.manager-tools.com/forums/viewtopic.php?t=578[/url]
- as we're both from North Carolina, I can only guess there's something in the water.

Anyhow, as far as software goes, you may be looking for more, but I use MS Project for planning/prioritizing projects and have also been successful with a free (as in beer) alternative - Open Workbench.

Johnny

PierG's picture

For sure software can help and in my opinion is NEVER a problem of tools.

I'll tell you what we do:
. we track everything,
. we cut everything into something that is easier (because smaller) to estimate (for us, it's onw week: we never estimate things bigger then 1 week)
. we estimate as if we were full time on that task
. we measure the actual effort
. we define our scale factors: how many 'pure' effort we do in a real day
. we use this factor for next estimante

I hope the process is clear.
PierG
P.S. And yes ... you need at least a spreadsheet to do that but the hard thing is the envolvment of the team