iSixSigma

Advice on Six Sigma Project

Six Sigma – iSixSigma Forums General Forums Implementation Advice on Six Sigma Project

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #55213

    JJ
    Participant

    Hi,
    Would like to make the following project as a 6 Sigma project, is it doable?

    Problem: High volume backlog which need to be completed in 2014 but still yet to complete till now 2016. Reason due to high staff turnover which result in lack of resource and time spent on other more critical tasks.

    In addition, there is possibility that this is a redundant process as this task may be done in other process. Hence, possible solution to change the frequency to done once in every 2 yrs or eliminate this process.

    In the above scenario, can this be done as a Six Sigma project?

    Thanks in advance for your advice.

    0
    #199195

    Prabhu V
    Participant

    Hello JJ,

    Requesting to follow the below links for better clarity on your issue.

    My opinion: Since you’re already classifying that the process is redundant and frequency is very rare, you can think of evaluating the alternatives if feasible.

    And also you have already narrow down the root cause (reason) for the issue you’re facing, hence I won’t suggest it won’t be good Six Sigma project.

    Backlog clearing may be a one-time activity (no cyclic in nature), hence it won’t fit the Six Sigma criteria in general.

    Regards

    0
    #199196

    Strayer
    Participant

    First look into whether or not this is really a redundant process. If it is, then ask why it still exists. It might be that “this is the way we’ve always done it”, someone wants to protect their turf, or it does something that the other process doesn’t, even though the rest is redundant. The first two are facts for management action. If it’s the latter you could do a good lean project to combine functions and eliminate redundancy. Many of the analytical tools we use in DMAIC aren’t a good fit for that. Once you have a clear understanding of the project and improvement goals you may find an SS project to make it happen.

    I’ve seen wasted effort on improving a process that was eliminated soon thereafter so above all make sure you aren’t doing that.

    0
    #199200

    Dahmane
    Guest

    You don’t sound too sure about the process redundancy and I don’t understand why a task makes a process redundant. It would be good to know why do you think the process is redundant and not a part in the process.
    I could think of other reasons for your high volume backlog, assuming you are using scrum:
    1- Wrong development estimate
    2- Requirements misunderstood or not properly defined
    3- Bug fixing of failed functionalities between sprints, not counted for
    4- No US clarification meeting done at the start
    5- Too many changes during development
    6- Development process not optimised
    7- Development process not followed
    8- Development process not documented
    9- Unit testing isn’t good enough or not done at all
    10- Sprint review not properly reviewed by the product owner
    11- Issues overlooked or not properly tackled during Retrospective meetings
    etc…
    There could be dozens of other issues I could add but a thorough analysis should be done on the “Whole” and not only on the “parts” otherwise you will be dealing with symptoms rather than the problem(s).
    I am not sure how big is your project (requirements) but being over a year behind is a serious delay and I am sure that development planning is one of your biggest problem.
    To improve your process, you can for sure use the DMAIC approach and I have to add that it’s by no means exclusive to 6 sigma.

    0
    #199204

    JJJJ
    Guest

    Thanks all for the valuable advice. I suppose the project mentioned is more to Lean Six Sigma to improve the process further.

    For Six Sigma will be more on reduce defects, save costs
    e.g.
    Problem statement: Increase in error rates (20% – 30%) for document review that resulted in increased processing time and additional cost in rework and investigate the issues. This also incurred customer dissatisfaction on the quality of work produced and delayed delivered document.

    Goal statement: To reduce the defects/rework by 30% within one year of implementation. This will improve customer satisfaction on the improved quality and turnaround time.

    In this case, is it more relevant on Six Sigma context?

    Thanks again in advance.

    0
    #199205

    jjjj
    Guest

    Thanks all for your valuable advice.

    Understand the project mentioned applies more on Lean Six Sigma.

    Six Sigma will be more on reduce defects/rework. Increase cost savings and customer satisfaction.

    Example:
    Problem statement: Increase in error rates (20% – 30%) for document review that resulted in increased processing time and additional cost in rework and investigate the issues. This also incurred customer dissatisfaction on the quality of work produced and delayed delivered document.

    Goal statement: To reduce the defects/rework by 30% within one year of implementation. This will improve customer satisfaction on the improved quality and turnaround time.

    In the above scenario, more applicable to Six Sigma?

    Thanks in advance

    0
    #199206

    julie rapacki
    Guest

    What possible “need” justifies a project that has been on hold for two years? I suggest that your first course would be to to identify what “need” existed, whether it was a real need and whether the need still exists today. If it doesn’t matter to customers, don’t do it. If the need still exists, for example, to meet a legal requirement or some contractual obligation, calculate the risk of non-compliance with the expense of reviving a project or simply focus on proving its redundancy.

    0
    #199208

    Ashley Leonzio
    Guest

    I most certainly think you can do this project using Six Sigma methods! I have done two projects with some of my call center teams that had customers complaining that it took too long to solve their problems. We diagnosed the problem to be that we weren’t controlling our backlog, which created long times to resolution.

    I recommend looking at Little’s Law which states that the size of your backlog is a factor of the incoming rate and the cycle time. If the incoming rate is the same or more than the outgoing rate, then you will not be able to reduce the size of your backlog.

    The way I have solved this in the past is:

    1. Burn down the backlog. Use overtime if necessary – but stop the bleeding.
    2. Determine what is causing you to not be able to close as many items out as needed. (staff, tools, etc) Use fishbone diagram, workout sessions, etc!
    3. Design improvements to address the root cause of why it might take too long. (e.g. To combat loss of knowledge with turnover, can you design a better onboarding system; If redundant, eliminate the step, etc)
    3. Create a CONTROL PLAN! Consider incentives to ensure the team meets the needed closure rate each week.
    4. Dont forget to MEASURE your KPIs: Incoming per week, closed per week, closed per agent, backlog size.

    0
Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.