iSixSigma

Need help picking a representative cycle-time metric to set expectations

Six Sigma – iSixSigma Forums General Forums Implementation Need help picking a representative cycle-time metric to set expectations

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #254907

    George Chast
    Participant

    I have an area that has SLAs for their request processes, but they are just starting to measure cycle-time directly from the workflow engine. They want to share the request processes performance

      to set expectations for requestors

    – this is paramount!

    I have quality people who want me to use %complete within SLA… Despite showing them it will not set expectations appropriately until the SLAs and cycle-times have been analyzed & reset. (if 68% complete w/in SLA, requestors won’t feel good at all, and if 100% complete w/in SLA, they won’t know how short it takes!

    I have technical people who want me to use Average cycle-time (despite showing them it is meaningless across our processes: Mean at minimum for some and near max for others)

    And, I have business people who want me to use 2σ, i.e. 95% of these come back in <this timeframe> (I like this – They feel it sets expectations which is the goal)

      What do you all think would work? What do you think is valid? Is there a common approach?

    We will validate whether the SLA or the process needs to be adjusted as we get metrics and can do the analysis, that is not today. Today, we need to publish something to set expectations. The question here is what?

    0
    #254920

    Strayer
    Participant

    Before trying to answer your question I’d warn you to be certain about the definition of closing a request. I had a very bad experience in the past where the service provider showed statistics with very good performance relative to the SLA. But those who who made the request or filed a problem report often complained that the request was not satisfied or the problem was not resolved, but they closed the ticket anyway. It seems that the SLA failed to specify that the resolution had to be satisfactory to the requester before the ticket could be closed. I blame those who negotiated the contract, not the service provider. I hope you are not in a similar situation as either the contractor or the service provider since that makes cycle time pretty near meaningless. That said…

    I would definite NOT use percent complete. It’s an old observation in project management that something can be, say 90% complete, but take longer to complete that last 10% than the first 90%. You would have to have extremely rigorous project management to make percent complete useful.

    Average cycle time could be good, except that you say there are multiple process with different expectations. You would need to drill down to supporting data comparing the different processes. In my experience, executive management usually only want to see the “big picture”. So I’d go with your inclination from business peoples’ recommendation. It gives them a number they can hang their hat on. And if they ask for details about the different processes, make sure that you also have that.

    1
    #254948

    George Chast
    Participant

    Thank you for your reply!
    1. The definition of “Complete” is always an issue… We are not ignoring that, but this question is on a different, more specific dimension.
    2. “% Requests Complete within their SLA” is not about partial completeness, but a measure of how many get completed on-time.
    3. I agree with “giving the business *They* can hang their hat on…”

    • This reply was modified 1 month, 1 week ago by George Chast.
    0
    #254949

    George Chast
    Participant

    – deleted inadvertent post –

    • This reply was modified 1 month, 1 week ago by George Chast.
    0
Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.