Using DMAIC to Improve Speed, Quality, and Cost

Overview

DMAIC (pronounced "Duh-MAY-ick") is a structured problem-solving methodology widely used in business. The letters are an acronym for the five phases of Six Sigma improvement: Define-Measure-Analyze-Improve-Control. These phases lead a team logically from defining a problem through implementing solutions linked to underlying causes, and establishing best practices to make sure the solutions stay in place.

When to use DMAIC

The structure of DMAIC encourages creative thinking within boundaries such as keeping the basic process, product, or service. If your process is so badly broken that you need to start over from scratch or if you're designing a new product, service, or process, use Design for Lean Six Sigma (DMEDI), not covered in this book.

Selecting DMAIC projects

This book assumes that most readers will work on DMAIC projects selected for them by managers or sponsors. (If this is not the case and you are involved in the project selection process, see p. 26 at the end of this chapter for a quick overview.

Implementation Options for DMAIC

There are two primary options for implementing DMAIC:

1. Project-team approach
   • Black Belts deployed full-time to projects
   • Team members work on the project part-time—work on the project is interspersed with regular work
   • Full involvement by all team members in all phases of DMAIC
   • Duration can be 1 to 4 months depending on scope (some go longer; shorter is better because you can realize gains more quickly)

2. Kaizen approach
   • Rapid (1 week or less), intense progress through all of DMAIC except full-scale implementation
   • Preparatory work on Define, and sometimes on Measure, done by a subgroup (team leader and a Black Belt, for instance)
   • Rest of the work done by the full group during several days or a week when they work ONLY on the project (participants are pulled off their regular jobs)

The basic DMAIC steps (pp. 4 to 19) apply to both of these models. Additional guidance on conducting a Kaizen project is provided on pp. 20 to 25.

Do we have to follow all of DMAIC?

DMAIC is a valuable tool that helps people find permanent solutions to long-standing or tricky business problems. The basic framework works well in a wide variety of situations, but using DMAIC does involve time and expense. So you should weigh the costs of using DMAIC against the benefits and the costs of skipping some steps or jumping right into solutions. Two indicators that you should follow all of DMAIC:

1. The problem is complex. In complex problems, the causes and solutions are not obvious. To get at the root of a complex problem, you need to bring together people with different areas of knowledge or experience. You may have to gather lots of different data before you discover patterns that provide clues about the causes.

   If you have a simple problem (or one you think is simple), often an experienced person can gather and analyze data and find a solution without going through all of the DMAIC steps.

2. The solution risks are high. A key part of the DMAIC methodology is developing, testing, and refining solution ideas before you impose them on the workplace and on customers. So you should use DMAIC any time the risks of implementation are high, even if you think a solution is obvious. However, if you've stumbled on an obvious problem and the risks of implementing the solution are minor—meaning little disruption to the process, little or no impact on customers, little cost—go ahead and try it out (using proper "solution implementation" procedures, see Chapter 11).

For most projects, it's risky to skip any DMAIC steps. The logic that links the DMAIC phases is key to success. But we recognize that it is human nature to want to jump to solutions and quickly make the improvement.

If you think you have an obvious solution with minimal risks, you can try skipping some of the DMAIC steps. But before you do so, ask:

• What data do I have to show that this idea is the best possible solution?
• How do I know that the solution will really solve the targeted problem?
• What possible downsides are there to the solution idea?

If you can't provide data to support your answers to these questions, you need to work through all the DMAIC phases.

• If you want to skip steps, see p. 152 for guidelines on how to test obvious solutions
• If you encounter problems with an "obvious solution to a simple problem" and cannot prove with data that the situation has improved, be prepared to launch a full DMAIC project

Define

Purpose

To have the team and its sponsor reach agreement on the scope, goals, and financial and performance targets for the project

What you need before you start

• First draft of project charter from sponsor(s)
• Resource allocation (time of team members, initial budget)

Deliverables

1. A completed project charter (covering the problem statement, business impact, goals, scope, timeline, defined team)
2. Documentation showing what customers (internal and external) are or will be affected by this project and what their needs are
3. High-level process map(s), at least a SIPOC diagram, p. 38
4. Completed project plans. Requirements will vary by company but often include Gantt charts; stakeholder analysis; resistance analysis; risk analysis; action logs, responsibility assignments, and communication plans (not covered in this book)
5. Outcomes from the project launch meeting showing team consensus around project purpose, charter, deliverables, and team responsibilities

Key steps in Define

1. Review project charter. Have your team discuss the draft charter from sponsors. Get answers to questions. Negotiate compromises or adjustments to scope, resources, timing, team membership as needed.
2. Validate problem statement and goals. Review existing data or other sources of information to confirm that the problem you've been given…
   • Exists
   • Is important to customers (collect the Voice of the Customer)
   • Is important to the business (collect Voice of the Business information)
   • Can reasonably be expected to be improved using Lean Six Sigma (DMAIC) methodologies

3. Validate financial benefits. Use existing data to calculate current costs, profits, margins, or other financial metrics relevant to your project. Estimate the financial impact if you achieve the project goal, and verify that it meets management expectations.
4. Create/validate process map and scope. Document the main steps of the process (with a SIPOC diagram, p. 38) to verify project scope; see if data exists to provide baseline measures on time, defects/errors, rework, etc., for a value stream map.
5. Create communication plan. Identify project participants and stakeholders (sponsors, customers, managers, process operators, etc.) and develop plans for keeping them informed about and/or involved in the project.
6. Develop project plans (schedule, budget, milestones).
7. Complete the Define gate review.

Gate review checklist for Define

1. An updated Project Charter
   • Problem Statement detailing when the problem has been seen, what the problem is, the magnitude of the problem, and the impact or consequence of the problem (such as effect on customer Critical-to-Quality expectations). Make sure the problem statement focuses on symptoms only (not on causes or solutions).
   • Key stakeholders: Who are they? How will they be involved in the project? How will progress be communicated to them?
   • Business Impact reflecting expected financial benefits and assumptions.
   • Goal Statement clearly identifying the key output metric (Y) to be improved.
   • Verification of Project Scope: broad enough to achieve the project objectives yet narrow enough to be completed within the Project Plan timeframe.
   • High-level Project Plan showing the targeted completion date for the project and intermediate milestones.
   • List of team members representing key stakeholders, appropriate mix of skills, and knowledge (especially about the current process).

2. Documentation on your customer knowledge
   • Primary external and internal customers identified
   • Voice of the Customer gathered
   • Customer needs evaluated for priority and importance (through Kano analysis, p. 64, for example)
   • Ability to measure customer requirements

3. A high-level process map and/or SIPOC diagram (p. 38)
   • High-level map showing major steps or activities (details will come in Measure)
   • SIPOC map completed to identify key Suppliers, Inputs, Process boundaries, Outputs, Customers (should demonstrate that the process boundaries align with the project goals)
   • Key process output variables (KPOVs) such as time, quality, and cost metrics (to show process links to project goals)
   • Optional: Key data on time, delays, queues, defects, etc. (see p. 47)—if you don't gather these data here, you'll be collecting them in Measure

4. Detailed Project Management plans
   • More detailed schedule of activities, especially for Measure (using a Gantt chart, for example)
   • List of stakeholders who will be impacted by the project, and their expectations and concerns
   • Communications Plan for the identified stakeholders and their concerns
   • Risk management plans
   • Identification of barriers/obstacles that could hinder the team (will likely require help from the Black Belt and sponsors to overcome these barriers)

Measure

Purpose

To thoroughly understand the current state of the process and collect reliable data on process speed, quality, and costs that you will use to expose the underlying causes of problems

Deliverables

• Fully developed current-state value stream map
• Reliable data on critical inputs (Xs) and critical outputs (Ys) to be used for analyzing defects, variation, process flow, and speed
• Baseline measures of process capability, including process Sigma Quality Level, and lead time
• Refined definitions of improvement goals
• A capable measurement system
• Revised project charter (if data interpretation warrants a change)

Key steps in Measure

1. Create/validate a value stream map to confirm current process flow. Use a basic process map (p. 39) or deployment flowchart (p. 43) to get started. Add defect, time, and other process data to generate a value stream map (p. 45).
2. Identify the outputs, inputs, and process variables relevant to your project. You want to collect data that relates to your project goals and targeted customers.
3. Create a data collection plan including operational definitions for all measures.
4. Create a data analysis plan. Verify what types of tools can be used for the type of data you will collect. (See p. 72.) Modify your data collection plan as needed.
5. Use Measurement System Analysis and Gage R&R (p. 87), or other procedure to ensure accurate, consistent, reliable data.
   • If using measurement instruments, be sure to calibrate them if it hasn't been done recently
   • Make sure Operational Definitions (p. 76) of all metrics are commonly used and applied by all data collectors

6. Collect data to establish baselines.
7. Update value stream map with data.
8. Use Little's Law (p. 202) to calculate lead time.
9. Perform process capability evaluation (p. 138).
10. Make quick-hit improvements if warranted by data analysis and risk analysis so you can get partial benefits now (be sure you are in a position to measure and show improvement), then continue with project.
    • Use a Kaizen approach or, minimally, follow guidelines on implementing obvious solutions (p. 152)
    • If solution ideas pop up but the risks are high or unknown, keep track of the ideas for potential implementation but continue with your DMAIC project

11. Prepare for Measure gate review.

Gate review checklist for Measure

1. Detailed value stream map (VSM)
   • Documentation of people who were involved in creating the value stream map (should include representative operators, technical experts, supervisors, perhaps customers and selected suppliers)
   • Map showing the main process steps relevant to the project scope, along with the inventories/work in process, lead times, queues, customer demand (takt) rate, and cycle times for those steps
   • Supplier and customer loops clearly identified; output and inputs clearly understood

2. Data and Metrics
   • Lists of key process output variables (KPOVs) and key process and input variables (KPIVs) identified and checked for consistency against the SIPOC diagram
   • Indications of how KPOVs are tied to Critical-to-Quality customer requirements (CTQs)
   • Notations on which KPOVs are selected as the primary improvement focus
   • Operational Definitions (p. 76) and data collection plans (p. 72) that were created, tested, and implemented for all metrics
   • Documentation of measurement system analysis (p. 87) or its equivalent performed to ensure accuracy, consistency, and reliability of data
   • Notes on problems or challenges with data collection and how they were addressed
   • Notes on ANY assumptions that were made
   • Copies or printouts of completed data collection forms

3. Capability Analysis
   • Time-ordered data collected on process outputs, charted on a control chart (p. 122), and analyzed for special and common causes (p. 133)
   • Baseline capability (p. 135) calculations for key output metrics (Ys)
   • Product/service specifications framed in terms of external customer requirements or intenal performance expectations (note any assumptions made)
   • Documentation on reliability of the capability estimates (is the measurement process stable, and does it have the expected distribution?)
   • Project goals reframed in terms of shifting the mean, reducing variation, or both

4. Updated project charter and plans
   • Project charter, financial benefits, and schedule timeline updated to reflect new knowledge
   • Project risks re-evaluated
   • Documentation of issues/concerns that may impact project success
   • Team recommendation on whether it makes business sense to continue with project
   • Detailed plans for Analyze, including anything that requires sponsor approval (changes in scope, budget, timing, resources)

5. Quick improvements

   Actions recommended for immediate implementation, such as:

   • Non-value-added process steps, sources of special cause variation that can be eliminated to improve process time and/or capability
   • Required resources (budget, training, time) for implementation

Analyze

Purpose

To pinpoint and verify causes affecting the key input and output variables tied to project goals. ("Finding the critical Xs")

Deliverables

• Documentation of potential causes considered in your analysis
• Data charts and other analyses that show the link between the targeted input and process (Xs) variables and critical output (Y)
• Identification of value-add and non-value-add work
• Calculation of process cycle efficiency

Key steps in Analyze

1. Conduct value analysis. Identify value-add, non-value-add and business non-value-add steps (see definitions on p. 50).
2. Calculate Process Cycle Efficiency (PCE). Compare to world-class benchmarks to help determine how much improvement is needed.
3. Analyze the process flow. Identify bottleneck points and constraints in a process, fallout and rework points, and assess their impact on the process throughput and its ability to meet customer demands and CTQs.
4. Analyze data collected in Measure.
5. Generate theories to explain potential causes. Use brainstorming, FMEA, C&E diagrams or matrices, and other tools to come up with potential causes of the observed effects. (See Chapter 8.)
6. Narrow the search. Use brainstorming, selection, and prioritization techniques (Pareto charts, hypothesis testing, etc.) to narrow the search for root causes and significant cause-and-effect relationships.
7. Collect additional data to verify root causes. Use scatter plots or more sophisticated statistical tools (such as hypothesis testing, ANOVA, or regression) to verify significant relationships.
8. Prepare for Analyze gate review.

Gate review checklist for Analyze

1. Process Analysis
   • Calculations of Process Cycle Efficiency
   • Where process flow problems exist

2. Root Cause Analysis
   • Documentation of the range of potential Key Process Input Variables (KPIVs) that were considered (such as cause-and-effect diagrams, p. 146; FMEA, p. 270)
   • Documentation of how the list of potential causes was narrowed (stratification, multivoting, Pareto analysis, etc.)
   • Statistical analyses and/or data charts that confirm or refute a cause-and-effect relationship and indicate the strength of the relationship (scatter plot, design of experiment results, regression calculations, ANOVA, component of variation, lead time calculations showing how much improvement is possible by elimination of NVA activities, etc.)
   • Documentation of which root causes will be targeted for action in Improve (include criteria used for selection)

3. Updated charter and project plans
   • Team recommendations on potential changes in team membership considering what may happen in Improve (expertise and skills needed, work areas affected, etc.)
   • Revisions/updates to project plans for Improve, such as time and resource commitments needed to complete the project
   • Team analysis of project status (still on track? still appropriate to focus on original goals?)
   • Team analysis of current risks and potential for acceleration
   • Plans for the Improve phase

Improve

Purpose

To learn from pilots of the selected solution(s) and execute full-scale implementation

Deliverables

• For a quality-improvement project: Tested, robust solutions shown to affect the proven causes (Xs) that affect the critical output (Y)
• For a Lean project: Documentation on results of the chosen Lean best practice or solution applied (5S, Pull system, Four step rapid set up, etc.)
• An improved process that is stable, predictable and meets customer requirements

Key steps in Improve

1. Develop potential solutions. Use the confirmed cause-and-effect relationship (from Analyze) to identify a wide range of potential solutions. This is one step where pushing for creativity is highly desired.
2. Evaluate, select, and optimize best solutions. Flesh out the solution ideas, develop criteria and evaluate the alternatives, document the results (see criteria development, p. 256; solution matrix, p. 258; Pugh matrix, p. 265). Be open to altering or combining options to optimize the final selections. If necessary, perform designed experiments (p. 185) to find optimal settings for combinations of factors.
3. Develop "To Be" value stream map. Revise the existing VSM to reflect what the process will look like after changes are made. Include estimates of time savings, improved quality, and so on.
4. Develop and implement pilot solution. Write up the tasks to be performed in the pilot solution. Train pilot participants. Document results of pilot along with ideas for improvements.
5. Confirm attainment of project goals. Compare results to baseline.
6. Develop and execute full-scale implementation plan.
7. Prepare for Improve gate review.

Gate review checklist for Improve

1. Solution development and selection
   • Documentation on alternative solutions considered
   • Data displays, statistical analysis, or documentation on other tools used to develop the solutions
   • List of weighted criteria used to evaluate solution; solution matrix or other display summarizing the evaluation results (should include benefit, effort, cost, ease and timing of implementation, resource requirements, etc.)
   • List of concerns raised by process participants and the process owner, and notes on how those concerns have been or will be addressed

2. Pilot testing
   • Documentation (including "to be" value stream map) of the redesigned process with changes in process flow highlighted
   • Documentation on communication with process participants, customers, and owners (as appropriate)
   • Data display, statistical analyses or other documentation showing the results of pilot test or simulation
   • Documentation of what was learned from the pilot test and plans for improvement during full-scale implementation
   • Documentation confirming that the pilot solution can achieve project goals (include before/after charts, hypothesis tests, etc.)

3. Full-scale implementation
   • Documentation of plans you used for full-scale implementation
   • Risk management plans (for avoiding, reducing, or mitigating risks)
   • Plans for addressing regulatory (e.g., OSHA), legal, fiscal, or other business requirements
   • Documentation of results from full-scale implementation (especially data showing stable performance)

4. Updated charter and project plans
   • Updated project charter, financial benefits, and schedule

Control

Purpose

To complete project work and hand off improved process to process owner, with procedures for maintaining the gains

Deliverables

• Documented plan to transition improved process back to process owner, participants and sponsor
• Before and after data on process metrics
• Operational, training, feedback, and control documents (updated process maps and instructions, control charts and plans, training documentation, visual process controls)
• A system for monitoring the implemented solution (Process Control Plan), along with specific metrics to be used for regular process auditing
• Completed project documentation, including lessons learned, and recommendations for further actions or opportunities

Key steps in Control

1. Develop supporting methods and documentation to sustain full-scale implementation.
2. Launch implementation.
3. Lock in performance gains. Use mistake-proofing or other measures to prevent people from performing work in old ways.
4. Monitor implementation. Use observation, interaction, and data collection and charting; make additional improvements as appropriate.
5. Develop Process Control Plans and hand off control to process owner.
6. Audit the results. Confirm measures of improvements and assign dollar figures where appropriate. Give audit plan to company's auditing group.
7. Finalize project:
   • Document ideas about where your company could apply the methods and lessons learned from this project
   • Hold the Control Gate Review
   • Communicate project methods and results to others in the organization
   • Celebrate project completion

8. Validate performance and financial results several months after project completion.

Gate review checklist for Control

1. Full-scale Implementation results
   • Data charts and other before/after documentation showing that the realized gains are in line with the project charter
   • Process Control Plan

2. Documentation and measures prepared for sustainability
   • Essential documentation of the improved process, including key procedures and process maps
   • Procedures to be used to monitor process performance and continued effectiveness of the solution
   • Control charts, capability analysis, and other data displays showing current performance and verifying gains
   • Documentation of procedures (mistake-proofing, automated process controls) used to lock in gains

3. Evidence of buy-in, sharing and celebrating
   • Testimonials or documentation showing that:
     • The appropriate people have evaluated and signed off on the changes
     • The process owner has taken over responsibility for managing continuing operations
     • The project work has been shared with the work area and company at large (using a project database, bulletin boards, etc.)

   • Summary of lessons learned throughout the project
   • List of issues/opportunities that were not addressed in this project (to be considered as candidates for future projects)
   • Identification of opportunities to use the methods from this project in other projects
   • Plans for celebrating the hard work and successful efforts

Kaizen DMAIC

Kaizen is a method for accelerating the pace of process improvement in any setting. It evolved in the application of Lean methods in manufacturing settings, but has since been adapted to the broader DMAIC framework.

Characteristics of a Kaizen approach

The term Kaizen is used for any intensive project where employees are pulled off their regular jobs.

• Team works 3 to 5 days full time (vs. typical team approach of spreading project work over 3 to 6 months)
• Resources dedicated
  • Participants spend 100% of their time on the project during the Kaizen event
  • Participants should be treated as if they are on vacation from their regular responsibilities
  • Project sponsor, event leader, and participants must work together to make arrangements to have work covered
  • The handling of emails, voicemails, etc., is minimized (if not outright forbidden) during project time

• Project is well-defined going in
  • There is not time to redefine the purpose or scope, so the boundaries must be well defined ahead of time

• Basic data already gathered (by a Black Belt or Team Leader)
• Implementation is immediate!
  • Bias for action (will act when 70% to 80% confident vs. 95% confident as in typical DMAIC projects)
  • Implementation is completed as much as possible during the week of the event
  • Doing something now that is "roughly right" is OK (vs. the typical DMAIC approach of waiting until solutions have been refined)
  • Items that cannot be finished during the Kaizen event are to be completed within 20 days

• Management makes support areas (maintenance, information technology, human resources, marketing, etc.) available during the Kaizen event

When to use Kaizen

• When obvious waste sources have been identified
• When the scope and boundaries of a problem are clearly defined and understood
• When implementation risk is minimal
• When results are needed immediately
• In the early stages of deployment to gain momentum and build credibility of the DMAIC problem-solving approach
• When opportunities to eliminate obvious sources of instability and waste have been identified through process mapping, work area tour, data collection, etc.

How to conduct a Kaizen DMAIC

1. DEFINE (Prep Week)
   • Clearly define the Kaizen objective.
   • Select a Kaizen leader, usually an area leader, group leader or someone close to process activities (not management) to be the Kaizen team leader.
     • Make sure the Kaizen team leader or facilitator is involved in project selection and scoping.

   • Select and notify participants. Optimum is 6 to 8 team members, including at least 2 people who work directly in the project area (process staff), and 1 who supervises or leads the project area (supervisor). In order of importance, complete the team as follows:
     • People from the direct upstream process
     • People from the direct downstream process
     • People from areas that directly support the process being studied, such as information technology, finance, purchasing, engineering
     • Management staff of the project area, such as a division manager, operations manager, engineering manager, etc.
     • Other functions that may have useful insights (HR, sales and marketing, corporate functions, or other divisions)

   • Prepare training and materials (if needed). Tailor training to the focus of the project. Make copies of training manuals for team use. Make poster-size worksheets for the Kaizen workshop.
   • Assemble background information including existing data on the problem, customers, etc.
   • Complete logistics planning—meeting rooms, workplace tours, meals, lodging if people are coming from out of town, supplies needed, etc.
   • Arrange for coverage during participants' absence from their workplace and/or during disruptions to workplace. In manufacturing, build some WIP to cover for Kaizen-related production stoppages. (Ex: a team may want to implement a new setup reduction process and will require the machine to be down to try new techniques.) In service situations, arrange for temp staff, job-sharing, or other means to make sure service to customers is not disrupted (much like you would if the person were going on vacation).
   • Arrange for management/sponsor participation. Plan for top manager to launch team with motivational, appreciative kick-off. Sponsors should check in at the end of each day to provide guidance and approval.
   • Contact departments/functions whose support you'll need during the week.
     • Information technology (prep them for potential software/programming needs and ideas)
     • Facilities management (rooms needed, potential support if work layouts will be changed, etc.)

2. MEASURE (Prep Week and Monday of Event)
   • Validate the value stream map of the process. Complete a resource flow layout for all operations or tasks if necessary (people, paper, material, machines, information).
   • Carefully observe then collect needed metrics for tasks or steps in the selected process.
     • The Kaizen leader should determine whether it would help to gather preliminary data during the Prep Week

3. ANALYZE (Tuesday-Wednesday)
   • Quickly validate root causes and identify sources of waste
   • Review waste elimination techniques then brainstorm process improvements for eliminating non-value-added tasks and reducing variation

4. IMPROVE (Wednesday-Thursday)
   • Create action item list to accomplish improvements
   • Implement process improvements, train employees then test, fine-tune, and ensure the process is capable

5. CONTROL (Thursday-Friday)
   • Create Standard Operating Procedures to document and sustain improvements
   • Present results to management team, complete follow-up, develop plan to monitor results over time

Management sponsor involvement in the Kaizen Event

1. Kickoff
   • Plan for top manager to launch team with motivational, appreciative kickoff.

2. Mid-Week Review Meeting:
   • Purpose: To review with local management team the analysis findings and the proposed Kaizen activities for implementation; to address any obstacles impacting the team's implementation plan; to gain understanding and agreement from management to proceed with proposed kaizen implementation.
   • Responsibility for conducting the meeting: Kaizen project team leader.
   • Timing: For projects beginning Monday afternoon this meeting will occur early Wednesday afternoon typically between 1:00 p.m. and 2:30 p.m.
   • Duration: 30 minutes for each project team.
   • Attendees: Kaizen project team leader, team sponsor, management or the work area/facility.
   • Agenda:
     • Full group reviews Kaizen project scope, goals, and objectives
     • Team leader summarizes the Kaizen analysis findings and conclusions
     • Team leader presents improvement activities and steps developed by the Kaizen project team
     • Full group discusses and resolves anticipated or real obstacles to improvement, and any issues or obstacles identified by management
     • Sponsors and management endorse continuation of the Kaizen event with agreed-on modifications

3. Final Presentation
   • Purpose: To inform sponsors and local management of workshop findings and outcomes
   • Kaizen team leader and members present findings and results
     • Tell how the team progressed through each phase of DMAIC
     • Include data charts, process maps, etc., of before/after results
     • Document what is needed to maintain the gains
     • Document open action items and responsibilities for getting them done

   • Sponsors and management should congratulate team members for successes and thank them for their dedicated team work

Project selection

Most team members do not join an improvement project until after the problem has been identified. But if you are asked to participate in selecting and defining projects, here is a quick overview.

• Target areas are usually identified by looking at what's important to the business (the "value levers" such as cost, profit, revenue, customer segments, etc.) and gathering ideas from diverse sources (customer/marketing information, process data, employee opinions, regulatory changes, etc.).
• The project selection process starts by screening the ideas based on just a few critical criteria to make the list more manageable. Each remaining idea is assigned to someone who will do more investigation and prepare a draft charter that provides more details about potential costs, benefits, scope, etc. These draft charters are then evaluated against more rigorous criteria to select the best opportunities.
• Deciding which of the best candidate projects to implement first involves a strategic decision about what is most important to the company and its customers.