As anyone involved in Six Sigma knows, selecting the right project is a critical component of project success. If practitioners do not put enough effort into selecting the right opportunity for improvement, a project can end in disaster, or create unnecessary work and complexity for the project team.
Selecting projects with just a few obvious inputs or simply selecting the squeakiest wheel are not always the best methods. These strategies may work at times, especially in tackling the low-hanging fruit, but a more structured approach is required when priorities are not so obvious.
Practitioners need a robust and reliable approach to 1) quickly determine whether the project is indeed a good DMAIC project and 2) prioritize projects to ensure resources are allocated appropriately. A criteria-based selection matrix helps practitioners standardize the project selection process, boosting its reliability.
To build and use the criteria-based selection matrix, it is important to understand 15 key pieces of selection criteria:
1. Customer impact – Will the successful outcome of the project have a material impact on customers’ (internal or external) perceptions of quality? A voice-of-the-customer (VOC) analysis with actual customer input would be beneficial in answering this question.
2. Process stability – Is the process relatively stable? If the process is new, has it reached a stable level of performance? Note that “stable” does not necessarily mean that the process is performing as desired (i.e., as per customer specifications). Also, is the process likely to undergo major structural or design changes in the near future? Process stability is important in accurately assessing the impact of improvements without the “noise” created by changes within the process.
3. Defect definition – Is the process defect well defined? If the project does not have a specific element that needs to be fixed, it could become a victim of scope-creep and lose its focus. Avoid making the final output (the “big Y‘s”) the measure of defect. For example, high costs, poor customer satisfaction rates or not achieving revenue targets can work as high-level problems to tackle, but are not ideal “defect metrics.” The defect metrics should be operational in nature. Examples of appropriate defect metrics include cycle time, error rates, rework rates, first-time call handling percentage, straight-through processing rates, lead times and complaint rates (all “little y’s”).
4. Data availability – Is data available around the process metrics? If not, is it attainable? Rarely will all the data needed for a proper process improvement study be waiting around to be analyzed, but it is important that key required data can at least be collected without having to spend an unreasonable amount of time, resources and effort.
5. Solution clarity – Is the solution already known? If so, just do it and skip going through the DMAIC motions. Keep in mind, however, that lots of people may have lots of good solution ideas, and it still may be worth going through the effort of identifying the true underlying root causes, rather than risk simply fixing symptoms.
6. Benefits – An appropriately vetted cost-benefit analysis should demonstrate the value of the project, ideally using a discounted cash-flow model to calculate the net present value or similar cash-flow analysis of the project. Do not forget to include the soft benefits such as customer satisfaction and how that translates into improved retention and higher sales.
7. Impact on service quality – Will the project contribute to enhancing overall service quality along the delivery value chain? It is not enough that end customers are satisfied, if the process has become more complex and unwieldy.
8. Project sponsorship – The level of project sponsorship is often the difference between project success and failure. Strong sponsorship at an appropriately high level cannot be underestimated and is a prerequisite for all Six Sigma projects.
9. Project alignment – Does the project align with corporate strategic objectives? If not, the likelihood of the project not getting appropriately funded and resourced increases (assuming it even gets the green light to proceed).
10. Project timeline – Can the project be completed within a reasonably short time period? A good benchmark to use in most Six Sigma projects is completion in six months. If the project cannot be successfully completed within six months, the chances of it being a viable DMAIC project diminish.
11. Probability of implementation – Practitioners should consider the probability of actually implementing a solution to the problem (assuming a correct solution will be identified), taking into account the level of acceptance or resistance by the organization or department. High cultural or organizational resistance means the probability of implementation is low. Probability of implementation also will be influenced by other factors, such as competing initiatives, significant organizational changes or changes in strategic objectives.
12. Investment – Will the costs to fix the problem likely include large cash outlays or capital investment? If so, the odds of meeting the requirements of a good Six Sigma process improvement project diminish because gaining the investment may be difficult.
13. Team availability – This takes into account the amount of time key team members have to support this project, especially if they are also responsible for other day-to-day functions. Dedicated Green Belts and Black Belts are essential to keep the project moving forward.
14. Controllability of inputs – Although this may not be uncovered until at least some data has been collected, practitioners should make an assessment as to whether there are likely to be sufficient inputs (i.e., contributors to the output to be improved) that are both measurable and controllable. If there is little or no control over the inputs to the process, achieving the project objectives becomes daunting.
15. Process redesign – Because these criteria are designed to limit project options to those that can be improved through DMAIC, project viability is low if the process being examined cannot be improved much further without redesigning it.
Now that the 15 criteria are clear, it is possible to create the project viability matrix, illustrated in the table below. Note the “weighting” column next to each of the criteria. Practitioners should use this column to establish the relative importance of each of the criteria (the weighting scale ranges from 1 = least important to 5 = most important). After assigning a weight to each of the criteria, practitioners should give an answer to each question about the project (1 = definitely no and a 5 = definitely yes).
|Project Viability Matrix|
|Description||Weighting||Definite No (1)||Mostly No (2)||Possibly (3)||Mostly Yes (4)||Definite Yes (5)|
|1||Are customers (internal/external) dissatisfied or defecting?||3||X|
|2||Is the process relatively stable?||3||X|
|3||Is the specific defect (defined by customer) known?||4||X|
|4||Is data related to the defect available or collectable?||5||X|
|5||Is the solution not obvious?||3||X|
|6||Are the expected benefits significant enough?||3||X|
|7||Will service and/or quality be noticably improved?||2||X|
|8||Does the project have Champion and sponsor support?||4||X|
|9||Is the project aligned with departmet or company goals?||3||X|
|10||Can the project be completed within 6 months?||2||X|
|11||Considering the risk, is there a good probability of implementation?||4||X|
|12||Will the solution likely involve little or no capital investment?||3||X|
|13||Are the necessary team members available to support the project?||2||X|
|14||Is the ability to make change in the process largely in our control?||4||X|
|15||Will the solution likely not involve redesign of the process?||3||X|
Now it is possible to determine the individual weighted scores, as well as the total score. To find the individual weighted scores:
To find the total score:
The total score will fall into one of three possible categories:
Some questions to which the answer is a “definite no” will automatically disqualify the project from being a DMAIC project, regardless of the overall score. For example, if the project has a known solution, no Champion support or requires a redesign, using another approach to solve the problem may be best.