Six Sigma Project Charter

The six sigma project charter is a document that details the improvement opportunity to both the team and top management. The document is the key deliverable from the define phase.

It is very important to understand that it is a living document, that is, it may be revised at needed during the course of your improvement opportunity.

The project charter is typically divided into specific sections as detailed below:

Several free examples can be located by conducting an internet search. You will find that all the examples are differ slightly in appearance. The look and feel of the document actually matters very little. It is the content that is important.

The Business Case

The business case statement ties the improvement opportunity to your organization's business objectives and also helps to sell or justify the need for this specific improvement to top management.

More specifically, the business case describes how the customer or stakeholders are impacted by the problem. It also details the time period your company has been experiencing the problem, and provides an overview of why it is important to the company to proceed with this specific improvement opportunity.

Example

During the 3rdquarter of 2008, the time to respond to quote requests has risen from an average of 3 days to an average of 25 days. Our process objective is a maximum of 4 days. This large gap in productivity has lead to the loss of 2 customers and with it, a loss of over $20M in sales.
Return to the Menu

The Problem Statement

We've written extensively about the problem statement in the problem solving strategies section of this site, so we won't repeat it here. Just remember that the problem statement must clearly define the problem, where it exists, how big the problem is, and when the problem occurs.
Return to the Menu

The Goal Statement

The goal statement in the project charter describes the anticipated improvement that your team is expecting. It should be worded in concise terms. Creating an outstanding goal statement is easy if you follow 5 simple concepts. The acronym for a good goal statement is SMART:

Specific- don't use confusing or ambiguous language anywhere within the project charter. Clearly describe the goal using the terms described in this list
Measurable- define in terms of percentage, monetary gains, throughput, productivity, etc. This give the team an objective to reach... and a basis for comparison after completion of the project
Attainable- attempting to set too high of a goal is the beginning of a poor plan. Set a goal that is achievable within 3-4 months. If the overall goal cannot be reached within that timeframe, set an interim goal. This will help keep your team motivated
Relevant- the team's goal should correspond to the problem at hand, business objectives, and the identified Critical to Quality elements identified in the define phase
Time-bound- list when the team expects to achieve this improvement goal

A good goal statement always begins with a verb. Use terms like increase, reduce, achieve to begin your goal statement.

Example

Reduce RFQ cycle time to 3 days or less before April 1
Return to the Menu

The Scope Statement

The scope statement states exactly what is included within the project. It may also list what is outside the scope of the project. This statement provides an awareness of the specific boundaries of your improvement opportunity.

In theory, your team may have already determined the basics of the scope statement for the project charter. If you've developed a high-level process map, then it might show where the start and stop points are.

Those starting and stopping points define your scope statement. Continuing with the same problem as above, a sample scope statement could be:

Example

Identify the root causes of late responses in the RFQ process

The above example is an excellent beginning to the scope statement. It defines exactly where the team will focus their problem solving efforts. The statement allows for no misunderstanding among team members or stakeholders.

This is the main objective of the scope statement... a clear and concise statement defining the boundaries. It is important to ensure that you scope statement accomplishes this objective. An unclear scope statement will lead to scope creep.

Scope creep causes the size of your project to increase, and with it comes a drain on your team's resources, a loss of team focus and morale, cost overruns, delays... There's a lot that can impact your improvement opportunity if the scope statement is weak.

One final tip regarding the scope statement... if the team is able to reduce the size of the scope, by all means do so. For example, if the team in our example determined during the measure phase that the main issue was related to the two customers that were lost, they could rewrite the scope statement to read:

Revised Scope

Identify the root causes of late responses in the RFQ process as they relate to Customer X and Customer Y
Return to the Menu

Cost of Poor Quality

COPQ is a measure of how much the problem at hand is costing your organization. This metric is very important to both your project charter and help sell the project to top management and your team. By knowing the impact of the problem in monetary terms, it puts additional emphasis on the importance of solving the issue.

There are several categories to consider when measuring cost of poor quality. Our COPQ Case Study shows how to determine the cost of poor quality.
Return to the Menu

Required Resources

The resources section of your project charter lists the key members of your team and higher level contacts. For example, the project champion, team leader and members should all be listed. Also consider listing any key supplier or customer contacts.
Return to the Menu

Key Performance Metrics

While all the other fields of your charter document are important, for our money, this is the critical field to be completed. The key performance metrics are in place to give your team a baseline measure of the process and prove there actually was significant improvement of the process!

The team should identify measures from their critical to quality (CTQ) analysis. They determined what the customer feels is important to them, and they've determined the problem. Therefore, the initial primary metric should relate to those concepts.

Only after a true root cause has been identified should a team consider changing the primary metric. A secondary metric may also be added instead of amending the primary metric.
Return to the Menu

DMAIC Cycle What you need to know about Six Sigma Training

Get FREE examples by subscribing to the Improvement Matters E-Zine