The first thing a Six Sigma project team should do as a team is plan out and document its project charter. Before it gives even the first thought to identifying root causes of problems or considers a process improvement, the team should take the time to craft a document that explains the project.
When the project charter is complete it will answer several critical questions.
- When will the project be completed?
- Why should the company support the project?
- Who will work on the project?
- Where will the team get the resources it needs?
- What is the object of the project?
Those encountering Six Sigma for the first time may see the time-consuming labor of writing a project charter as “busy work” – filler that can be cut short or eliminated so that the real work can begin.
Attempting to execute a Six Sigma improvement project without a project charter is like taking a trip through unfamiliar territory without bothering to take a map. You’re unlikely to reach your destination, and even if you do you probably won’t realize it.
A project charter gives a project team goals and objectives to keep it on course. Its first service to the team is to help answer difficult questions about the project, such as:
- What effects will the project have on other departments?
- How will we know when the project is a success?
- Do project benefits outweigh costs?
Six Elements that Make Up the Project Charter
Each section of the project charter provides guidance for the team.
Scope – A scope statement sets boundaries that prevent scope creep. Project scope can be defined in as little as one sentence. When scope is not clearly understood before the project begins a project team can wander or be slowly pushed beyond its resources or outside its area of expertise.
Deliverables – These are what a successful project produces, without them a project may be labeled a failure. Deliverables are most often expressed in numbers that are easy to measure and compare (increasing sales revenue by 8% or decreasing product costs by 15 %.)
Problem Statement – This piece documents how the process is currently performing and defines the problem. A good problem statement demonstrates the effects of the problem with quantifiable data. This section can be updated if more accurate data comes to light during the course of the project.
Business Case – This section ties the project to the company’s objectives. At its best, the business case explains how the project will benefit the customer and shows how it supports the organization’s strategic goals. It also explains how the project affects customers, stakeholders and employees.
Resources – These assets help the team carry out the project. They can include key members of the project team or technology assets.
Objective – This is an easily understood and quantifiable statement of how much the project will improve the process (e.g. reduce call handling time by 18%).
The rigors of writing a project charter eliminate bad projects by exposing their weaknesses before they consume too many resources. These same rigors help make good projects better by providing boundaries to focus team members – and goals to motivate them.
