1 Identify the list of different markets 1 for each of these markets note: * Their needs * percent size * who/what do they consist of * How diverse are the market/customers, list percents of groups. E.g. Age group 1 Segmentation of the market and establishment of segmentation strategies(Git06, 108) 1 SWOT 1 Do the Business Use cases * (Get an overview in order to have something to discuss with the customer) 1 Non-Functional requiremetns 1 Identify cognitive images using a SixSigmaKanoSurvey(Git06, 108) 1 Convert cognitive images into CTQs using QualityFunctionDeploymnet(QFD)(Git06, 108) * SixSigmaQfd 1 Select final CTQs(Git06, 108) 1 Develop and validate the measurement systems for each CTQ(Git06, 108) 1 Develop a design scorecard(Git06, 108) 1 Review intellectual property issues(Git06, 108) 1 Develop a plan to manage risk among the CTQ characteristics from the customer and critical-to-process characteristics(CTPs) of the project (Git06, 108) * (i.e., understand the conflicts between the requirements of the targeted "customer requirements," (CTQs) and the critical-to-process requirements (CTPs) of the project.(Git06, 108) 1 Revise the project objective, if necessary.(Git06, 108) 1 Revise the Multi-Generational Product Plan (MGPP), if necessary(Git06, 108) 1 Passage through the Measure Phase tollgate review.(Git06, 108)

• Project team [leader (BB or GB), members, champion, process owner, IT representative, finance representative].
• Project business case.
• Project objective.
• Project plan (e.g., Gantt chart with responsibilities and resources).
• Document control system.
• Risk reduction plan.

Ch5 dfss_gb

$ Market segmentation: is the process of dividing a market into homogeneous subsets of customers such that the customers in any subset will respond similarly to a MarketingMix established for them and differently from the customers in another subset.

• Internal and external markets?

E.g. staging, they are StakeHolders, should they also be Counted as Customers? see also(Git06, c14)

Indentify the arease where each of the segments are unique, or at least significantly different.

$ sustainability: is the degree to which a segment is large enough and/or profitable enough to be considered for attention with a unique marketing mix(Git06,c14.1). $ accessibility: is the degree to which a firm can effectively communicate with the members of a market segment. $ measurability: is the degree to which information exists (or is obtainable) on a particular market segment. $ responsiveness: is the degree to which a selected target market responds to a marketing mix.

(The finance book)) $ Audience: - $ Purpose: presents a description of the product and examines why the product represents a real opportunity for the company. $ Length: - $ Content: description of the product and examines why the product represents a real opportunity for the company. * also analyzes how the company can win against the competition. * Who are the customers? * How much product will they buy? * Why will they buy this product? * how the product will be positioned against competitive products. $ Tools Used: * establish the value of the product in the market. * Market Segmentation * Value Chain Mapping * Value Proposition Identification * Market FMEA * determine how well the product is positioned against competitive products * SWOT Analysis * Product Positioning Maps * Market Perceived Quality Profile * establish specific customer requirements and to design product concepts with features intended to address these requirements * Customer Selection Matrix * Customer Interviews * Image KJ * Requirements KJ * Relative Importance Questionnaire * Ideation * Pugh Concept * present a pricing and growth strategy for the product. * sales outlook * promotion strategy * distribution plan.

(Git06,c14.1)

• Macro Segmentation $ product use: is a variable used to segment the business market according to their usage of a product. $ Type of organization: is a variable used to segment the business market by different types of organizations. $ customer size: is a segmentation variable useful in segmenting the business market by the number of customers or the volume of sales.
• Micro segmentation -- define the purchasing behavior of organizations. $ key purchasing criteria:
  • pre-certified vendor program (Yes or No)
  • minority vendor program (Yes or No). $ personal characteristics of purchasing agent:
  • purchasing agents trained in Six Sigma management (Yes or No)
  • purchasing agent certified by a national purchasing association (Yes or No). $ purchasing strategy variables
  • electronic versus paper purchasing system,
  • sole source versus multiple source purchasing policy,
  • competitive bidding on price assuming equal quality versus competitive bidding on quality and price. $ importance of purchase:
  • size of purchase order (under $1,000 versus $1,000 or more),
  • strategic purchase (web page) versus routine purchase (paper supplies).

The purpose of a Market FMEA is to identify possible areas of market failure that may hinder the successful introduction of a new product into the chosen market.

If the commercialization team identifies substantial risk areas that cannot be adequately mitigated, after review of the available data, the team and business management will determine if the project should proceed, be placed on hold, or killed.

1 definition of the market to be served by our new product 1 identify the potential categories of risk that the project may experience. * e.g. * technology * competitors * customers. 1 identify major project-related failure modes that may occur in each of these key categories. 1 Identify cost/impact 1 identifies and records the potential causes for the failure mode.

(Chapter 9. Identifying Market Opportunities)

Opportunities and threats always come from outside the company and directly address key items needed for success in the markets being evaluated. Opportunities and threats are found in either market conditions or the environment surrounding the business. %X% They are stated in positive terms in a way that reflects that if such conditions exist, the company will have a better opportunity for success in targeted markets.

• In the market
  • Growth rate
  • Customers
• In the environment
  • Competition (Why isn't this in the market?)
  • Regulations
  • Economy

$ opportunities: may include items such as the existence of large markets, markets having high growth rates, or markets where a high level of customer interest in our product exists $ threat: will be defined as the absence of an identified opportunity and will be determined as the team begins the subsequent SWOT scoring process

Strengths and weaknesses always come from within our company and relate to how well the company can take advantage of the identified opportunities.

As with opportunities and threats, strengths and weaknesses are stated in positive terms in a way that reflects that if such conditions exist in the company, the market will be satisfied and our probability for successful product commercialization will be improved.

$ Strengths: for a company may include having reliable products, possessing a well-trained sales force, and offering acceptable product pricing. $ Weakness: will be defined as the absence of a strength and will be determined as the team conducts the SWOT scoring.

• In the Product
  • efficient product
  • reliable product
• In the Company
  • Sales force
  • Reputation
  • Budget
  • Product R n D

The weights of importance are determined based on how much influence the presence of that opportunity or strength has on our company's ability to achieve success in the marketplace.

 	Candy Wrappers	Hot Food Wrap	Video Screen Film	Safety Glass Film

Opportunities and Threats Weight Rating Score Rating Score Rating Score Rating Score High Level of Customer Satisfaction 19 3 57 1 19 2 38 0 0 Many Customers in the Market 15 2 30 1 15 -1 -15 -1 -15 Large % of Customers Using Our Type of Product 15 3 45 2 30 3 45 3 45 High Willingness of Customers to Use Our Type of Product 15 2 30 2 30 3 45 1 15 High Level of Customer Expectation from Product Performance 14 2 28 -1 -14 0 0 0 0 Low Level of Competitor Activity 10 0 0 1 10 2 20 2 20 Large Customer Base 8 1 8 2 16 3 24 0 0 End Use Provides Significant Benefit to Society 4 3 12 0 0 3 12 1 4 TOTAL 100 210 106 169 69

 	Candy Wrappers	Hot Food Wrap	Video Screen Film	Safety Glass Film

Strengths and Weaknesses Weight Rating Score Rating Score Rating Score Rating Score Diverse Product Portfolio 18 1 18 0 0 0 0 -1 -18 Act on Data/Evidence 12 1 12 0 0 0 0 0 0 Siginificant Experience in the Market 12 0 0 0 0 1 12 -1 -12 Ability to Target Specific Customer Needs 5 2 10 2 10 1 5 2 10 Products in the Top 10% of Performers in the Market 15 2 30 2 30 1 15 0 0 High Level of Promotion Expertise 18 2 36 2 36 0 0 0 0 Skilled Sales Force 12 3 36 2 24 1 12 2 24 Significant Customer Education Capabilities 8 1 8 1 8 1 8 1 8 TOTAL 100 150 108 52 12 Market Size (M lbs): 250 100 150 59

Every segment will not place the same level of importance on the items identified. In fact, some segments may view the presence of the item listed as an opportunity to actually be a threat. As shown in Table 9-4, the rating scale chosen is a -1 to 3 scale with -1 meaning that the item listed as an "opportunity" is actually a threat and 3 meaning that the presence of this particular opportunity is very important to success in this market segment

Table 9-4. SWOT Rating Scale Score Opportunities and Threats 3 Very important to success in this segment 2 Above average importance to success in this segment 1 Average importance to success in this segment 0 Not important to success in this segment -1 A detrimental impact on this segment Score Strengths and Weaknesses 3 Our capability offering would have the greatest impact here. 2 Our capability would have an above average effect on the market. 1 Our internal capabilities have an expected, normal impact. 0 Our capability would have no effect. No impact. -1 Among the worst. Always an internal problem. Really bad internal capability effect.

• X-axis: Strength
• Y-axis: Opportunities
• Dot size: Size of market(in product weight/number/...)

So when comming up with projects, one could segment the customer base and then possible use the number of users as the market size.

The purpose of a Market FMEA is to identify possible areas of market failure that may hinder the successful introduction of a new product into the chosen market.

If the commercialization team identifies substantial risk areas that cannot be adequately mitigated, after review of the available data, the team and business management will determine if the project should proceed, be placed on hold, or killed.

1 definition of the market to be served by our new product 1 identify the potential categories of risk that the project may experience. * e.g. * technology * competitors * customers. 1 identify major project-related failure modes that may occur in each of these key categories. 1 Identify cost/impact 1 identifies and records the potential causes for the failure mode.

Start by doing UseCase' of the way the project is understood this far.

See: UseCase

(This is now more a comment thing, I think that Problem domains are the way to go now). That seed is probably the data from the Charter, but what? Probably see(Git06, c14)

$ availability: $ efficiency: $ flexibility: $ integrity: $ interoperability: $ maintainability: $ portability: $ reliability: $ reusability: $ robustness: $ testability:

• Look at the problem statements

• Look at the SIPOC

• Event driven Use cases(Rob06,c4)

• Learning what people need(Rob04,c4)

It seems to me, that in order to ask the right questions one has to understand what one is dealing with. So in this case here, it seems that doing the scenario as well, before starting the Kano should hopefully provide some more insight.

See "Business Event" in SwDevFitpPgAcronyms.

%X% It seems that this might be the SharedPhenomena(Kov99,61).

1 Identify BusinessEvent * Each time an input flow of data occurs, something must have happened in the adjacent system to produce the flow. That "Something" is the Business Event(Rob04,c4,p4). * A supplier has provided input. See also: SipocProcess. * A BusinessEvent can also be an Output From TheWork to a Customer/AdjacentSystem. a. Identify ContextInput on the ConctextModel. a. Write Name for BusinessEvent a. Reference the BusinessEvent to the ContextInput a. Describe What the Event does. What is it accomplishing. a. Describe Why this is done, what does the Customer get out of it. a. If possible describe the UltimateGoal * X%X TODO V Explain the difference between 'Why' and 'UltimateGoal', and how to identify them. a. Link the BusinessEvent to the relevant Objectives (SixSigmaObjectives). 1 Draw BusinessUseCase. * The preplanned response, a unit of functionality(Rob06,c4,p17) * processes(Rob06,c4,p17) * data that is retrieved and/or stored(Rob06,c4,p17) * output generated(Rob06,c4,p17) * messages sent(Rob06,c4,p17) * or some combination of these(Rob06,c4,p17) a. Write Name for BusinessUseCase a. Link to BusinessEvent a. Draw minimal operations chart (Flow chart with just the processes and that data going in and out.) * It should probably only contain Process, Storage and Message nodes. 1 Identify the EventOwner(Rob04,c4,p6)/StakeHolder. a. Link BusinessUseCaseEvent to Stakeholders 1 Identify what the ultimate result is needed from TheWork. * Only by understanding the true nature of the event and the intentions of the adjacent system can you find the most appropriate response to the event(Rob04,c4,p8). * To ensure what rely needs to be addressed. get to the root of it. 1 Link to ObjectiveId BusinessEventObjectivLUT 1 Itterate until all inputs and outputs are handled. 1 Go through each Inputs. 1 Then make sure all Outputs has been covered. * Is some Outputs haven't been covered by a BusinessUseCase, then identify what BusinessEvent would cause the Output and write the BusinessUseCase for the BusinessEvent.

%X% TODO C The first, most important, step in documenting requirements is to: Frame the problem - to put it into a definitie form, with definite parts, and definite relations between the parts. (kov99,p56).

• BusinessEventUseCase Concept:
  

Like selecting an OS, there is no use case for that?

I I allow linking StoryCards directly into the UseCase list, then I'm affraid that it might seem easier to just link the StoryCard directly rather than finding the correct UseCase.

Is it because the OS selection is a non-functional requirement?

(Rob06,c6,p17)

(Rob06,c6,p17)

This distinction between run-time and development-time qualities has important implications for how

the non-functional requirements are specified(Mal01,p3).

Also, trade-offs may have to be made between run-time and development-time qualities. For example, performance and modifiability may be in tension in the system design, so that the users' desire (often influenced by competitive pressure) for performance may have to be traded off against the development organization's goal of having a more maintainable architecture(Mal01,p3).

Everyone who is measured on short-term success will put short-term requirements ahead of those that contribute toward long-term effectiveness. In particular, developers and project managers are working against the release clock. This is why architects have to be vigilant about taking development-time qualities into account(Mal01,p3).

An architect's role is to achieve the right balance of quality characteristics in the system and make sure to document the quality attribute expectations in the SRS (Software Requirement Specification) in order to deliver a product that satisfies all the system's stakeholders(Sar07).

Bas03,c2 +c? Describes how the Quality things affect the architecture.

• Many people view quality exclusively as a program to ensure product conformance to an internal set of product specifications. As mentioned in the last section, a more important view of quality is "How well do external customers perceive that our product meets their most important needs?
• To be successful in making quality a weapon that can be used to gain competitive advantage, a company must have a fundamental understanding of what customers want and how well the company can meet these needs compared to the competitors.

David Garvin, "Competing on the Eight Dimensions of Quality." Harvard Business Review No. 87603, Nov.-Dec. 1987. David Garvin, Managing Quality: The Strategic and Competitive Edge (The Free Press, 1988)

According to David Garvin,[1], [2] product quality from a customer's point of view can be summed up in eight key dimensions: $ Aesthetics: The product has a nice appearance to the customer. * Light bulb: A consistent bulb surface with no scratches. $ Conformance(Interoperability): The product matches the expected specifications for the product. The most common general definition of quality. * Light bulb: The number of units produced (e.g., on a parts per million basis) that do not meet the specifications for lumens. $ Durability: Product life. * Light bulb: How long a light bulb is expected to last under typical operating conditions. $ Features: Secondary characteristics of a product or service. * Light bulb: The color of the bulb. * Paint: Protection against weathering. $ Perceived quality: The reputation of the company producing and marketing the product. * A belief that a company's products have a higher level of quality than competitive products. * Light bulb: Customers purchase a bulb because the brand has been promoted to last longer than competing products. $ Performance(Efficiency): The primary operating characteristic provided by a product. * Light bulb: Must provide a certain number of lumens of light. * Paint: Must provide coverage of the surface. $ Reliability: The frequency with which a product fails. * Light bulb: Less than 0.1% of light bulbs fail to reach the expected life for the bulb. $ Serviceability: How easily, fast, competently, and courteously a repair of the product is conducted. * Light bulb: The ease of return of light bulbs that fail within the warranty period. * Car repair: Rapid and courteous service in performing engine repairs.

While understanding customer needs in light of the dimensions of product quality is important, the design team should also explore what service expectations customers have for the new product.

Berry's Quality Characteristics for Services $ Reliability: Consistency of performance * Accuracy in billing $ Responsiveness: Timeliness of service * Turnaround time on orders $ Competence: Possession of required skills and knowledge * Expertise and knowledge of customer contact personnel $ Access: Approachability and ease of contact * Frequency of busy signals or being put on hold on the telephone $ Courtesy: Politeness, respect, consideration, and friendliness * Tone of voice and appearance of customer contact personnel $ Communication: Listening to customers and keeping them informed in a language they can understand * Clear explanations of the service being provided $ Credibility: Trustworthiness, believability, and honesty * Perceptions of the company and company reputation $ Security: Freedom from danger, risk, or doubt * Confidence in physical safety, financial security, and confidentiality $ Understanding of the customer: Efforts to understand the customer's needs * Learning the customer's specific requirements and providing individualized attention $ Tangibles: Physical evidence of the service * Facilities, tools, and equipment

As a new product is introduced, the product moves through its life cycle and goes from being a "surpriser and delighter" to being "expected." The new product development effort and the need to constantly stay in touch with the changing needs of the marketplace never ends.

A more in-depth discussion of quality attributes can be seen in Karl Wieger's book, Software Requirements (Wieger 1999). Some examples of quality requirements that capture how users expect systems to behave can be described as follows(Sar07):

• Availability refers to the percentage of the planned "up time" during which the system is fully operational. It is very important to define the "up time", as some tasks are more time critical and if the system is down during that time it can frustrate users.
• Efficiency refers to how well the system utilizes processor capacity, disk space and memory. An architect needs to assure that the systems make efficient use of given resources as, for instance, 100% resource usage can severely affect the performance of the system.
• Flexibility refers to how much effort is needed to add new capabilities to a system. Flexibility is very important when the system is being developed in an incremental, iterative fashion through a series of successive releases. If the architect anticipates system enhancements, then he or she can choose design approaches that maximize the software's flexibility.
• Interoperability refers to how easily the system can exchange data or services with other systems. The architect needs to know which other applications the users will employ in conjunction with the product and what data they expect to exchange.
• Reliability refers to the probability of the system executing without failure for a specific period of time. An architect needs to establish quantitative reliability requirements based on how severe the impact would be if a failure occurred and whether the cost of maximizing reliability would negatively impact performance. An architect needs to specify replication and failover scenarios as well as security plans to protect the system from hackers.
• Robustness refers to the extent a system continues to function correctly when confronted with invalid input data, defects in connected software, defects in hardware components, or unexpected operating conditions. In conjunction with the users, the architect needs to identify all expected error conditions in order to determine the robustness goals of the system.
• Security refers to precluding unauthorized access to a system, ensuring that the software is protected from virus infection, and protecting the privacy of data entered into the system. There is no tolerance for error concerning the security of the system.
• Usability refers to 'ease of use' and 'user-friendliness' of the product or application. An architect needs to make sure that the users are able to access the system using all desired channels of communication. For instance, the architect may have to document that the users desire to access the application over the web using three types of browsers.

While the above list indicates quality attributes important to users, the following suggests important concerns for developers(Sar07):

• Maintainability indicates the ease of correcting a defect or change in a system. It is critical that systems are developed to accommodate incremental and periodic revision. This is a very important requirement because if developers, administrators, and operators cannot figure out how to manage their applications, they will not survive past the first release. For example, with regard to my work with Datum, maintaining the application became a nightmare as adding a small feature took a lot more time and sometimes required significant rework.
• Portability refers to the effort required to migrate a piece of software from one operating environment to another. The architect needs to build a plan to migrate the system to the latest version of the software. My MIS application was not easily portable as every new release of the framework had integration issues that were very time consuming to resolve.
• Reusability refers to the extent a software component can be used in applications other than the one for which it was initially developed. Developing reusable components costs more compared to developing an application-specific component. An architect needs to specify which components of the system will be reusable and needs to create a library of the reusable components that can be easily integrated with other applications. The MIS application at Datum was designed as a reusable application, which increased its cost of developmenttremendously.
• Testability refers to the ease with which the software components or integrated products can be tested to find defects. Testability is very important if the product is being developed incrementally. Frequent testing at each development increment can help determine whether changes damaged any existing functionality. The MIS system I worked on went through many enhancements, and it was very hard to test, understand and maintain, as its cyclomatic complexity was very high. Cyclomatic complexity is a measure of the number of logic branches in a source code module. The more logic branches a system has, the more test scenarios must be developed in order to test these branches.

Do the problem domains(Kov99,59).

Each problem domain consists of: $ Purpose: $ Entities: People, trucks, files? ... $ Attributes: $ Relationships: $ Events: $ Causal law: $ Shared phenomena: $ Vocabulary: Explain the entire vocabolary for the domain(Kov99,60) $ Pattern: (Kov99, $ Graphical representation: Drawing the Entities and the entities relation to each other. * Optionally draw lines(Shared phenomena) to dimmed related domains.

For each Problem domain: 1 Write the Name of the domain 1 Write up each requirement that the Problem Domain needs to fulfill * These requirements are the upper level/upstream requirements that are the reason for formulating the Problem domain * And circumstantial requirements from other domains. * e.g. Needs that this domain can fulfill for another domain. * TODO N Is this what (Kov99,59) refers to as Proposisitons? 1 1 1

TODO V What is the relation to SixSigma here? TODO V What is the relation to QFD? It sounds like, this is before QFD starts?

TODO N Propositions(Kov99,59) Predicate calculus, propositional calculus.

If you make an assertion about a name or a number, then you are treating name or number as an entity(Kov99,60)

• No part of the domain can be, two entities, at once.
• You must know in advance all of the predicates that you want to assert of the entities.

The initial question might be: "What are the current problems with the current proccess."

Asking; "What do you need", might well give you answer: "faster horses."

How to find/come up with that Disruptive new technology/answer....

%INCLUDE{SixSigmaKanoSurvey}%

See: GettingToCtqs

What is 'CTQ' in all of this?

%INCLUDE{SixSigmaQfd}%

Select the final set of CTQs to be designed into the product, service, or process. These decisions require a benefit/cost analysis of each cognitive feature.

Problems, such as endless bickering and ill will, can arise from the lack of an OperationalDefinition. A definition is operational if all relevant users of the definition agree on the definition.

$ Validity: means that the measurements gathered reflect the "right" operational definitions represented in the project. $ Timely: Are you able to detect changes as they occur? $ Accurate: Does the average of the measurements represent the "true" representation of what is happening? $ Repeatability: If the same person were to measure the same products, services, or processes at two different instances of time, would they yield the same measurements, assuming there was no change? $ Reproducibility: If different people were to measure the same products, services, or processes at the same time without collaborating, would they yield the same measurements?

1 Timely 1 Accurate 1 Repeatable 1 Reproducable 1 Do the methods of collecting the measurements match your need to know what is happening with the products, services, or processes? 1 Do the processes of data entry, transfer (e.g., between one computer application and another), processing of the data, and extraction of the data change the reliability of the data in any way (e.g., rounding of significant digits in the data, transcription errors, etc.)? 1 Are our methods reliable in that the measurement process is expected to maintain itself in a state of statistical control? 1 Can the measurement system be improved in the future?

The validity of a measurement system can be determined through designed studies, statistical analysis, and data integrity audits. For instance, the answers to questions

• 1, 5, and 6 are answered through system audits.
• 2 is found through calibration and linearity studies.
• 3 and 4 are often determined through Gage R&R studies, which are designed studies conducted to measure the variation due to repeatability and reproducibility.
• 7 is only answered over time through the use of statistical tools such as run charts and control charts

Measurement system design includes:

• who will be responsible
• what will be measured,
• when will it be measured
• why is it being measured
• how will the measurement process be monitored and improved if necessary
• where will the measurement data be hosted
  • (i.e., which system(s) will hold the information), along with how will it be accessed.

<img src="%ATTACHURLPATH%/components_of_measurement_variation.PNG" alt="components_of_measurement_variation.PNG" width='739' height='467' />

$ Part-to-part variation: is the variability created by the measurement of multiple parts per unit under identical conditions (e.g., same server, same store in chain). The ideal measurement system has 100% of variability due to part-to-part variation. $ Reproducibility: (e.g., variation due to servers) is the variability created by multiple conditions such as multiple operators or labs. $ Variation due to gages: is the variability created by repeatability, calibration, stability, and linearity. $ Repeatability: (or precision) is the variability created by multiple measurements of the same unit under identical conditions (e.g., same server, same store in chain). This is called within group variation, or common variation. $ Calibration: is the adjustment of a measurement instrument to eliminate bias. It is important that adjustment of a measurement instrument is not overreactive to noise in the system. For example, if a marksman adjusts his rifle sight every time he shoots by how far he is off target, as opposed to shooting six shots and adjusting the sight by how far the average of the six points is off the target, he will increase the variation of the shots from the target. $ Stability: (or drift) is a change in the accuracy (bias), repeatability (precision), or reproducibility of a measurement system when measuring the same part for a single characteristic over time. Bias over time (accuracy) is the difference between the observed process average and a reference value over time. $ Linearity: is the difference (bias) between the part reference value and the part average over the different values of the domain of the gage. Bias over domain (accuracy) is the difference between the observed process average and a reference value over the domain of a gage. An example of a linearity issue occurs when reading an automobile speedometer. If the speedometer has a 10% error rate, then the error of measurement in a school zone (20 mph with an error rate of 2 mph) is different than the error of measurement at highway speeds (70 mph with an error rate of 7 mph). If a constant error of measurement over the domain of a measurement system is desired, then different measurement instruments should be used at different speeds. $ Percent R&R: is the percentage of the process variation due to the repeatability and reproducibility of the measurement system. Percent tolerance is the percentage of the part tolerance due to the repeatability and reproducibility of the measurement system. $ Resolution: (discrimination or number of distinct categories) is the fineness of the measurement system (meters, centimeters, millimeters, etc.). At a minimum, the measurement system must be able to distinguish between excellent, good, fair, and poor units (four categories). * Some researchers require at least 7 to 10 categories if the data represented is continuous. * A gage scale (measurement tool) should be able to divide the tolerance (USL - LSL) into at least 10 parts measurable by significant digits. For example, a 12-inch ruler marked in whole inches yields 2 significant digits to the left of the decimal point and 1 doubtful digit to the right of the decimal point (10.7 inches yields 2 significant digits (1 and 0) and 1 doubtful digit (7)). If this is a sufficient resolution, then you can continue. If it is not, then the gage (measurement tool) is inadequate, and it must be replaced or fixed.

A sign of inadequate discrimination for a measurement system of a continuous variable is when a range chart (R-chart) exhibits three or fewer values within the control limits, or when the range chart exhibits four values within the control limits and more than 25% of the ranges are zero.

Variation due to the measurement process must be separated from variation due to the actual process to address variation due to the process.

Study:

$ Measurement system analysis (MSA) checklist: A measurement system analysis checklist involves determining whether the following tasks have been completed: 1 Description of the ideal measurement system (flowchart the process). 1 Description of the actual measurement system (flowchart the process). 1 Identification of the causes of the differences between the ideal and actual measurement systems. 1 Identification of the accuracy (bias) and precision (repeatability) of the measurement system using a test-retest study (see page 140). 1 Estimation of the proportion of observed variation due to unit-to-unit variation and R&R variation using a Gage R&R study (see page 142). * R&R variation includes repeatability (e.g., within person variation), * reproducibility (e.g., between person variation), * operatorpart interaction (e.g., different people measure different units in different ways). * A common rule of practice that has developed over the years is: * If R&R variation < 10% of observed total variation, then the measurement system is acceptable. * R&R variation is called study variation in Minitab, but this is a misnomer because R&R variation is based on the standard deviation, not the variance. Because the variance is the square of standard deviation, then an R&R variation of 10% is equivalent to an R&R variance (called R&R contribution in Minitab) of 1%. * If 10% <= R&R variation < 30% of observed total variation, then the measurement system is borderline acceptable (acceptability depends on the situation). Alternatively, R&R variance is marginal between 1% (0.102) and 10% (approximately 0.302). * If R&R variation >= 30% of observed total variation, then the measurement system is unacceptable. Alternatively, R&R variance greater than 10% (approximately 0.302) is unacceptable. $ Test-Retest Study. Test-retest studies are performed by repeatedly measuring the same item under the same conditions, operator, inspector, gage, location, etc. A general rule is to collect at least 20 observations and to calculate the mean and standard deviation of the repeated measurements. The resulting statistics are analyzed as follows: 1 If (standard deviation < [1/10] � Tolerance), then the measurement system has acceptable precision or repeatability. If (standard deviation ≥ [1/10] � Tolerance), then the measurement system has unacceptable precision or repeatability. In the later case, the measurement system must be improved or replaced before baseline data can be collected for a Six Sigma project. 1 A "standard unit" or reference value is required to determine the bias in a measurement system. Bias = (Standard value - Mean value). Without a "standard unit," it is impossible to determine the accuracy of the measurement system. 1 The bias of the measurement system (Bias = Standard value - Mean value) = (40.0 - 39.8) = 0.2. If the bias remains constant over time, 0.2 should be added to all future measurements. $ Conduct a Gage R&R Study: A Gage R&R study is used to estimate the proportion of observed total variation due to unit-to-unit variation and R&R variation. R&R variation includes repeatability, reproducibility, and operator-part interaction (different people measure different units in different ways). If R&R variation is large relative to unit-to-unit variation, then the measurement system must be improved before collecting data. * The data required by a Gage R&R study should be collected so that it represents the full range of conditions experienced by the measurement system. * For example, the most senior individual and the most junior individual should repeatedly measure each item selected in the study. The data should be collected in random order to prevent individuals from influencing each other. 1 Do a two-way ANOVA(git06, 146)

The purpose of a design scorecard is to formally state critical parameters (CTQs, Part Features (CTPs), etc.) in the Voice of the Customer and the Predicted Voice of the Process.

• Establish nominal values and specification limits for each CTQ, as well as the target for the process sigma (Part A of the scorecard).
• Predict output of the Voice of the Process with respect to stability, shape, mean, and standard deviation, as well as DPU and predicted process sigma (Part B of the scorecard).
• Highlight problems and risks of CTQs with respect to failure to meet desired process sigma levels.
• Track CTQs throughout the entire life of the product, service, or process.

| Scorecard—Part A VOC ||||| Scorecard—Part B VOP |||||| |CTQ| Target (Nominal) | LSL | USL | Sigma Target| Stable (Y/N)| Shape | Mean | Standard Deviation| DPU |Predicted Process Sigma| | | | | | | | | | | | |

Are we infringing on intellectual property with respect to construction procedures, materials, and design similarities to the works of other(Git06, ch05.9)

Team members input the CTQs and CTPs into a Failure Modes and Effects Analysis (FMEA).

update the project objective at this point based on any new information that has come to light due to the Measure Phase

the Multi-Generational Product Plan (MGPP) is used to view the "entire picture of a project." It does not concern itself with details, but rather addresses the more significant strategic and tactical issues.

• Has scope creep created an unmanageable project from a manageable project?
• Are the decisions compatible with future generations of the product, service, or process?
• Have new ideas been added, generated during the course of the project, to a list of future modifications?