This procedure is intended to identify the activities and methods used to apply financial analysis and valuations to Lean Six Sigma (LSS) projects. It’s not intended to replace or supersede any existing financial procedure, but rather augment existing methods, more completely integrating LSS activities with the rest of daily business activities.
​
The rigor with which financial benefits must be proven is generally intended to exceed usual financial standards. This is deliberate to leave no doubt that benefits claimed have made their way to the bottom line. For this reason, indirect costs, cost avoidances and cross-business unit costs are examined with great care.

All financial benefits are calculated at the enterprise level, netting out the impact in all affected departments or business units. A change that benefits one business unit while causing higher costs in another business unit is credited only with the net impact on the overall business. Accordingly, charges between business units and transfer pricing are generally not the focus of LSS improvement efforts. The claimable amount is the financial impact on the net margin.
​

Financial benefits are divided into three levels in order to facilitate understanding and to associate the greatest rigor with the most important benefits.
​

Financial benefits that are immediately traceable to current financial statements are designated as Tangible. Most of the financial benefits sought from LSS projects are Tangible.

Tangible financial benefits must pass the tests of timeliness, certainty, and causation, for example:

Financial benefits similar in character to Tangible benefits, but delayed beyond the current fiscal or calendar year. This is typically achieved through redeployment of resources for whom financial gain is delayed.

Level 2 benefits must pass similar tests as Level 1 benefits but those benefits are deferred. In addition:

Intangible financial benefits are any benefits clearing arising from the project, but which cannot be justified as Tangible or Delayed Tangible. They are not given financial credit, but simply recognized as other positive outcomes of the project.

Any believed financial benefit that does not impact the bottom line is deemed fictitious. This would include savings arising from rules of thumb that do not produce cash results, or changes in transfer prices that benefit one organizational unit at the expense of another.

Every proposed project shall be subjected to sufficient analysis to ascertain the level of financial benefit that can be expected from that project. Financially motivated projects are typically expected to provide benefits in excess targets set by leadership. While project valuation is an estimate, it should be a reliable estimate, such that there is a clear opportunity to realize at least the amount of financial benefit estimated.

It is recognized that occasionally projects will be chartered with no expectation of financial benefit. While this is permissible, it is expected that projects motivated by financial considerations will have a target expectation.

The Kure Value Finder (KVF) should be completed in order to clearly identify the expected impact of the project on the business. The KVF should be completed before the project charter has been written. The project sponsor and intended Project Leader will often create the KVF, although others are often included.
​
The KVF should begin at the bottom with the basic premise of the project, such as “Process xx cycle time reduced” or “Process xx waste rate reduced”, and all direct business consequences should be identified. For each of the direct business consequences other consequences are also identified. This continues until the overall objectives are reached (usually some combination revenue, cost or customer satisfaction). When all consequences have been identified, they are all reviewed, and those to which monetary impact can be assigned are colored green or flagged with a dollar sign ($).

It is recommended that the KVF be used for all financially motivated projects. If the benefits are few and obvious, the KVF will be easily completed. For example, we may wish to reduce process defects, which would reduce scrap and rework. The corresponding KVF diagram might look like this.
​
However, the process may be capacity constrained, and we may be having difficulty shipping orders on time. Under these conditions, the KVF would be more complex, with more financial potential.

​

All of the KVF boxes that are flagged with dollar signs are reviewed in order to determine rough estimates of financial impact. These are estimates based upon easily obtained financial data without exhaustive analysis. The important consideration here is speed rather than accuracy.

We are not interested in the exact valuation of each box, but the order of magnitude. Is it worth $1000, $10,000, or $100,000 per year? Those boxes worth incidental amounts are typically ignored while those of substantial value are identified for further analysis. At this point the order of magnitude values are used to establish the project valuation.

While most projects are expected to produce financial benefits, the project may focus on a process improvement that is not directly financial, but measured in some other units. The Process Baseline is often a measure of how effectively the basic premise of the project is being fulfilled. Examples might include process yield, or scrap, manufacturing capacity, or process lead time. In such cases the process baseline is created by taking multiple measures of the process output over some planned time period.

The KVP establishes the logical relationship between the Process Baseline and the Financial Baseline. The Financial Baseline value is the sum of the values of all the boxes with significant financial impact. For purposes of valuing the project the rough order of magnitude values are sufficient. However, to establish the Financial Baseline greater precision is needed. Typically, the Black Belt and the Financial Rep will jointly agree upon a feasible method of determining a more precise valuation of each box.

For baseline purposes, it is sufficient to determine financial impact to the nearest $1000 dollars. If greater precision is easily obtained it may be used, but such precision is not usually required. Typically the Financial Baseline is determined over the same period of time as the Process Baseline, following the criteria set forth in “Methods of determining baseline periods”. It is desirable for the Financial Rep to sign off on the method of calculating the Financial Baseline.

The amount of data needed to establish a baseline is dependent on the nature of the process, its stability and variability. In most cases there is a record of historical data that can be used.

In cases where processes are stable (statistically “in-control”), and of low variability, a baseline may be established based on the past three months of history.

In cases where processes are stable (statistically “in-control”), and of low variability, a baseline may be established based on the past 6-12 months history.

If the process exhibits an upward or downward trend, the baseline should include the past 6-12 month history. Use Time Series Trend Analysis to establish the baseline and to forecast future baselines to which actual improvements may be computed.

If the process displays seasonal variation then the baseline must include at least two seasonal periods, typically the past two or more seasonal periods (more if readily available and representative). Use Time Series Seasonal Decomposition to establish the baseline and to forecast future baselines to which actual improvements may be computed.

When no historical data is available, a project may be launched without a baseline. Data is then gathered as soon as the project begins. To avoid delaying the project, no specific baseline period is required.

To assure that there is a meaningful improvement there must be (1) a significant measurable improvement and (2) evidence that it resulted from the project.

LSS projects are intended to deliver ongoing benefits, year after year, so it is necessary to demonstrate that the improvements put in place represent a statistically significant change, not just a “lucky break”. While any valid statistical method may be used to demonstrate improvement, the methods taught to Black Belts are highlighted here, and recommended in favor of more complex methods. It is beyond the scope of these procedures to explain or demonstrate the use of these methods. Refer to the Lean Six Sigma Black Belt Training material as needed.

Most statistical tests used here are based upon Hypothesis tests, readily available from statistical tools (such as Minitab, SigmaXL, Excel or online), which automatically generate a “p” value which represents the probability that the results observed could have happened as the result of random chance alone. This “p” value is related to Confidence Level by: Confidence Level = 1 – p. For Tangible benefits, we will expect a “p” value of 0.20 or less, corresponding to 80% Confidence (or better).

The basic method used to confirm the improvement is to compare the results from the baseline period to the period immediately after the project improvements have been completed. While these are not the only correct means any of the following methods are acceptable:
​
​Control Charts. While control charts are not particularly sensitive indicators, they are one of the simplest ways to clearly demonstrate a large change. If the amount of the process change is more than one standard deviation the control chart may be a good choice.

For the baseline period establish the ±1.64σ control limits (adjusted for subgroup size, if subgroup charts are used). Performance data is tracked on this chart right up to the completion of the project improvement implementation.

The chart is then marked to denote the process change, and new data is added while the original control limits are maintained, and the pattern of the data is examined.

If any of the new data points plot outside of the control limits, then we can be 80% sure that there is a significant difference. If there is a distinct favorable process shift at or around the time of the process improvement completion, this also can demonstrate a significant difference. If there are 4 or more points in a row, all on the same side of the centerline, there is over 90% confidence of a shift. If this shift is the only shift that is evident, then the Run Chart in Minitab can provide a more precise “p” value (use the value for clustering).
​
​Two Sample Hypothesis Tests. While control charts provide a clear picture of the improvement, they often are not sensitive enough to detect a significant, but small shift. In such cases a two sample hypothesis test is preferred. The type of test could be a t-test, 2 proportion test, Mood’s Median or Mann-Whitney test, depending on the nature of the data. Typically the baseline data is used as one of the samples, while the data collected after the improvement is the second sample.
​
​Tukey End Count Overlap Test. In some cases there is a large improvement but it is very difficult or time consuming to gather data points. In such cases the Tukey End Count Overlap test is a practical alternative. Simply collect three data points Before and three After. Then arrange the data points in rank order of their value. When arranged in this manner, if all of the After data points are all better than all of the Before data points, we may be 95% Confident that the improvement is real.

While there is no way to statistically prove that the project produced the result, reasoning can usually suffice. If there are no competing efforts, it is often obvious that the results came from the project.
​
If there are others who may claim credit, investigation of actions and other evidence may be helpful. In some cases it may be necessary to negotiate a fair allocation of credit to the competing parties.

Occasionally LSS Projects result in novel situations that may project valuation.

While most LSS projects seek to make improvements not previously achieved by discovering new causes and solutions, once such discoveries are made it is usually advisable to spread the improvements as broadly as possible. It is common practice to sponsor replication projects for this purpose. Such projects take the discoveries made in previous LSS projects and replicate them (often with some modification) in other areas of the business. These projects typically are shorter in duration than the projects which create the initial improvement, and can greatly leverage the benefit throughout the business.
​
Because this leverage is so important, financial benefits from replication projects are calculated in the same manner as non-replication projects, even though they are usually easier and faster to execute.

If the LSS project discovers situations which ultimately result in financial write offs, such as bad debt or inventory obsolescence, those write offs are not to be charged or attributed to the LSS project, as they should have happened in the normal course of business. The fact that the LSS project led to the discovery of hidden items that should have been written should simply be recognized as helping the business avoid misrepresenting financial conditions. The one exception to this exemption is when the reason for the write off was directly caused by the LSS team, such as a product design change that actually created inventory obsolescence.

Occasionally LSS projects may discover a business practice that is contrary to policy, regulation, law or payor requirements. In such cases it is the duty of the Project Leader (or their representative) to disclose such findings to an appropriate organizational executive. Any costs incurred in correcting the situation, as well as any fines or penalties, shall not be attributed to the LSS project. It will be considered fortunate that the LSS project had discovered the condition before the situation further deteriorated.

It is not unusual for LSS project efforts to discover business situations that can be quickly improved, even though they may be out of the project scope. If such situations occur and result in a financial benefit to the business, then the LSS effort may be credited with the improvement, since the situation would have gone unnoticed if not for their efforts. The classification and calculation of benefits must conform to the same rigor as benefits resulting from in-scope improvements. If the project team discovers the situation and identifies it to others who subsequently act on that information, then the benefit credit is typically shared between the two groups.

It is intended that this document supplement an organization’s accounting practices. In the event of a conflict, the organization's documented practices will prevail, while any non-conflicting aspects of this document may still be applicable.