LearnSixSigm
On this page: Template Download Instructions
In this Template
- Project Charter template for Lean Six Sigma.
- Beautifully formatted, easy to read.
- Word and Google Docs formats.
- Ready to print: A4, U.S. Letter, etc.
- Comprehensive instructions and advice included.
How to Use This Template
The project charter is first prepared in advance of project authorisation and start-up. It is the key document for review at the Define tollgate (The D in DMAIC) and is revised and reviewed again at each subsequent tollgate review. It is therefore a living document that tracks the progress and changes in understanding and direction as the project proceeds.
Any changes or updates made to this document should reset the Last Update Date to the current date. If it is appropriate to your document control system, an issue number and issue control may be added. The Estimated End Date should be revised for each of the tollgate reviews as the project proceeds.
1. Choose a Project Name
The project name should be clear and simple. It should focus on the problem, not the solution. You also want this to be memorable, so your contribution to the business is recognised when the project is complete.
Spend a couple of minutes on this, then once you've chosen, write it down.
Example:
Let's imagine a sandwich shop that is turning customers away at lunchtime. These project names focus only on the problem:
"Boost lunchtime capacity" or "No lunch customers turned away".
However, these project names propose a solution, which isn't what we want right now:
"Hire more employees" or "Simplify lunch menu".
2. Describe the Business Scenario
This is a description of the background to the problem as expressed by the Process Owner. It could be in terms of a process failure or waste. It is intended to provide context and understanding of the impact on the customer and business, and the opportunity for improvement.
Example:
The following description recognises the waste to the business of the example problem we outlined before, and describes the process failure:
"At lunch on weekdays, there are so many customers waiting to be served, a long queue builds up at the counter, and lots of customers leave before they can be served."
3. Describe the Problem Statement
The Problem Statement describes the nature and extent of the problem, but still does not describe the solution. It is usually expressed in terms of what has the problem plus the extent and the impact of the problem.
It should be specific and expressed in measurable terms. The metrics used may be estimated or anecdotal data. It will be updated with real data as the project progresses.
It is sometimes best expressed in bullet points with a metric associated with each problem bullet. This anticipates a statement of the goal(s) which match each of the problems with future state expectations and their related metrics.
"Sandwich makers are unable to keep up with the pace of orders placed during the busy period 11:30am-2pm. A queue builds up inside the shop and out of the door."
"It's estimated that around 15% of customers leave the line before we can serve them. It's unknown how many potential customers are put off by the long queue."
4. Goal Statement
The goal statement describes the expected outcome of the project. It should be specific and defined in measurable terms. It is usually expressed as one or more descriptions like Better or Faster, or Cheaper, as measurable deliverables in quality, delivery, or cost. These may be updated as the project progresses when better data or understanding arrives.
For the problem described above, this might be something like:
"The shop should serve customers more quickly, so that the queue in the shop should never exceed 3 people. Quality of the product should not decrease, or increase if possible, and price should remain the same, or decrease if possible."
5. Project Scope:
The Project Scope helps to clarify the boundaries of the project, what is included and what is excluded. It describes which departments, areas, sites, cells, products, components or processes are to be improved and which are to be excluded, either by omission or with an explicit statement. This will help to avoid incorrect assumptions by sponsors about the deliverables and help to avoid scope creep.
For our example sandwich shop project we've been imagining, we might like to limit the project to the scope of just the sandwich counter, where orders are prepared, or we could expand the scope to the whole shop. It should depend on the scope of the problem. If orders can't be filled because prepared or ordered ingredients are running out, then the scope might expand to the kitchen or back office where those activities take place.
6. Assumptions
This is optional and should be limited to significant assumptions that would affect the success of the project. Issues such as the availability of key resources, essential equipment or investment.
There are likely to be many minor assumptions and concerns, especially in the early stages of the project, which would not normally be documented here.
7. Team Members
This is an opportunity to recognise the contribution of all team members. It should include all those participating if only for a short time. Later, there will be opportunities to recognise and reward the success of the project, but all those involved should be mentioned.
8. Risk Assessment
A structured risk assessment is not always required, but if there are one or more significant risks to the business.
Our template contains a standard business risk assessment with independent measures for Probability of Occurrence and Severity of Impact. It is usual to classify these as High, Medium, or Low.
For risks that are coded as High-High, High-Medium, Medium-High or Medium-Medium, it would be appropriate to consider a risk minimisation or mitigation plan.
Some organisations have pre-defined definitions of Occurrence and Severity. These suggestions below are useful if they are not defined in your business:
| Probability of Occurrence | Severity of Impact | |
|---|---|---|
| High | >70% | Project killer |
| Medium | 30-70% | Medium |
| Low | <30% | Minor |
9. Project Closure
The Project Closure Summary is a report on the project conclusion. It isn't due until completion of the project, but we should include this for completeness.
It acts as a final review of the goals of the Project and their achievement. It completes the project charter and provides a record of lessons learned and an archive for similar project opportunities.
The Results Achieved should be completed based on one or more months of successful operation of the new process. Results may be quality metrics, delivery metrics, or financial metrics. These aren't required yet, so no need to worry about these right now.
Once the new process is stable it is usual to project these savings over 12 months and claim them as achievements for the project.
Future Opportunities indicate other project opportunities that surfaced during this project. This will allow for identification of follow-up projects or new opportunities while not encouraging scope creep on the existing project.
Lessons Learned: This could refer to the project results, the way the project was conducted or any other area where it would be done differently if we had to do it over again.
10. Project Sign Off
This section isn't due until project completion, but again, we should go over it quickly now.
The Project Sign Off demonstrates completion of the project with a successful conclusion and delivery of the goals and handover back to the process team and the process owner.
Sign off by the Black Belt or Green Belt project leader and the Process Owner is mandatory.
In case of specific quality, delivery, or finance goals, the appropriate department head or controller should also sign to confirm achievement of the goals claimed. Don't worry too much about what this means yet; we'll get to that in more detail in another post.
Related Templates
-
SIPOC Template
