i have one question:

what kine of the pain drive of the human……….

Our main objective is Customer Satisfaction, which is a lagging indicator.
Backlog is something we actively look out, as it constitutes a leading indicator, however we don’t put objectives on it, more or less for the reasons mentioned above : not all of the backlog is in our control.

In the past, we used to have objectives only on the part of the backlog that we control (i.e. active cases, not in development). Cases that were at the customers (proposed solutions etc.) have sometimes been considered as within our control, i.e. we can in fact chase up the customer to make sure that we the case is not fogotten. The objective ran out as a comparison to past quarter, i.e. need to reduce backlog by say 5, 10, or 15%.

The problem with doing objective on the backlog is that you can never control the incoming volume. The “lean Factor” suggestion on the thread above is interesting, but I beleive has a caveat : if the colume explodes (for instance a new version of a siftware), then the backlog will augment and perhaps in such a way that people los productiviy – basically because they’re swamped. And it’s very difficult to say when someone gets swamped.

As to what type of backlogs we measure,, I guess they’re pretty standard :
In process at Support
in process at Development
Waiting for a customer action
With solution proposed.

We also try to measure backlog age, with buckets of 1-14 days, 14-30, 1 to 3 months, 3months +.
Lastly, a good thing to look at is the rate of cases being solved within an acceptable timeframe, as a percentage to overall incoming cases. This is quite a similar method as the lean factor mentioned above, basically amking sure that you manage quickly enough a deent percent of your invoming volume.

Hope this helps !

We do this for a few reasons:
“Problem backlog” implies our maintenance burden, which directly relates to SLA’s (customer perspective) and our maintenance financials (internal perspective).
“Contracted requests” directly relates to billable services, which is financially a different team, but still must be tracked as backlog from a customer perspective.
“Uncontracted requests” are customer ideas to make the product better. We want to encourage this feedback, so we don’t treat it as support backlog. We do track it tightly with Product Management, however, as these are golden nuggets to present at customer forums to justify maintenance renewals (“You asked for this …, and it’s in the next version”).

I agree not all backlog cases are equal and support backlog consists of only those cases that can be resolved or advanced by support. Cases that are linked to defects(or in R&D hands), pending customer confirmations should not be included with the “work” backlog, even though they may not be closed. Understanding what the “actionable” backlog is the key to managing it.

Does anyone use case effort or number of customer contacts to aid in managing the backlog?

Do you encourage team members to collaborate based on case age?

1) Define the term “Lean Factor” as: LF = “Support” bucket backlog today / Inflow in the last 30 days. This tell us what is the “cushion” on which we deliver the current level of service. Our objective is to take down as much as possible. Right now we hover around 25%.

2) We focus primarily on “Support” bucket backlog as the “Customer” bucket response level is at customer discretion/prioritization. And, the “Development” bucket (these folks own the code base – my team can read and suggest changes, but we can’t make the changes ourselves) is again not really under my control, but we monitor it to make sure the response level does not reach an alarming state.

Pure backlog statistics can sometimes be misleading because the unclosed case universe is frequently littered with cases that cannot be resolved within the realm of a typical Services staff. These include:

Product Defects/Enhancements
Issues that cannot be duplicated (but client refuses to close the case)
Cases awaiting client response

I have found it useful to park the backlog into different buckets (including the above). It can have a powerful impact on internal resource allocation. Important to segregate the backlog to understand those backlog cases which can be directly influenced by the Service organization and those dependent upon others.