Project Charter

Project Charter

The project charter is a set of a documents that provide purpose and motivation for the initiative. Serves as a working document for the team and as a reference for the rest of the company. Acts as a guiding hand for the Plan-Do-Study-Act cycle (Deming wheel, Shewhart wheel). Use the it as a guide to managing the project, meeting deliverables, etc

Also good as a method of problem identification in the sense that it clearly documents the scope and business impact of the problem the Six Sigma team is attempting to solve.

The project charter should also clearly state what the intended goals are and how success will be measured.

Remember, a project charter is a living document. You will update this throughout the course of the project.

“Any road will get you there, if you don’t know where you are going.” – Lewis Carroll

The Six Elements of a Good Project Charter

Problem Statement

Start your project charter here with a clear problem statement.

  • Describes the problem you are trying to solve or the opportunity you are trying to capitalize upon in an objective manner without commentary or opinion.
    • “Just the facts, Jack!”
  • Details what this project is solving in specific, measurable, and quantifiable terms
  • How long has the problem existed?
  • Describes the impact of the problem to the company.
    • What will happen if we DO NOT take action?
  • What’s the gap between now and future?
    • The problem statement describes the the gap between the current state and the desired state.
  • Do NOT: Suggest cause, solution, or assign blame.
  • A microproblem statement is a granular statement of the problem defined in the charter.
  • I also like using Agile’s “One Big Thing”
  • Use SMART – Specific Measurable Actionable Relevant Timely
    • Specific, Measurable, Actionable, Relevant, Time-Bound
    • The more you follow SMART, the more it will resonate with your sponsors and stakeholders.
    • Useful in defining your timelines and defining your problem and objectives.

Benefits, Goals and Objectives

Now continue with the goal statement. Here we want to take the Problem Statement and translate it into objectives (things that need to be completed to consider the project a success) and understand the benefits of what the project will deliver.

  • Anticipated benefits
  • Answer to the ‘why’
  • Think of how you would pitch this project to sponsors. If they spend their budget financing this project, what do they get out of it? Why should your company allocate scarce, precious resources of time, manpower, and budget to this effort.
  • What is the anticipated return?
  • Once you have performed a Critical to Quality tree it would be a good idea to add it to your appendix and list the Critical to Quality  items here.

Business case

The next step is to take what you’ve listed in the problem statement and the objectives and clearly and concisely lay out a case for management to select this project. Remember, even though you may have a great need for this project it still has to compete against projects in a larger portfolio at the department, division, or even corporate level for scare resources. Since no company has unlimited resources, you want to give management a compelling case for spending resources on this project.

  • Convert the problem and objectives to a statement of business value.
  • Short & to the point.
  • In non-specific and non-quantifiable terms:
    • What does the project do?
    • What is the strategic impact?
    • Why is this worth doing?
    • What happens if we don’t do it?
  • Describes what the project does to impact the strategic imperatives of the company.
    • If there is no tie to strategy, there shouldn’t be a project! These ties also serve as motivation for the Six Sigma team to get the job done!
    • Linking to business strategy is critical. (Note: Jim Collin’s books are excellent for this purpose.)
  • Identify the project needs.

Project scope

  • The boundaries
  • Who else is impacted?
  • Set by champion
  • Battles scope creep
  • Is NOT a timeline, but COULD be a time frame.
  • do NOT just restate the issue
  • This is just what your project is and what your project is NOT.
  • Think of this as your contract. Your project will do X, Y, and Z. It will NOT to A, B, or C.
  • Remember that no organization has infinite appetite for cost, schedule, or scope. And there is always a chance to do a follow up project to address items you don’t on your first one. Identifying and naming project scope usually involves tradeoffs to focus on the most critical needs of the organization.


  • What key deliverables are being delivered when – and what value will be conferred?
  • Possible prioritization and scaling of benefits.
  • List the tollgate meetings.
  • Review with your sponsors to set realistic expectations.
  • If a schedule is required, use project management tools to reverse engineer the tasks and activities needed to complete all of the objectives and ensure that you have the appropriate time to accomplish everything necessary.


Assumptions & Dependencies

  • What do we know about this problem?
  • What must we believe or hold true if we are to think this project will be a success?
  • What are some global variables that need to be true in order for this process to be a success? What are some global variables that, if are not true, invalidate what we expect we will achieve with this project?
    • Ex. If the price of oils is below $90 / barrel.
    • Ex. If self-driving cars are not adopted by more than 50% of Americans.
  • What things are crucial to our success?
  • Are there other projects or efforts underway that are required for this project to be successful?
  • What times are showstoppers? What potential events are out there that could totally derail our effort?
  • Note: You could list everything in the world on this list. The best course of action is to focus on the critical few that are worth considering.

Roles & Responsibilities of team members.


  • Detail how the project impacts them or their groups, and what they may be required to help with.
  • Review the assumptions and dependencies with them. Be transparent. Perhaps they can remove some obstacles or know of better ways to ameliorate the risks. Sometimes sponsors who have a greater or more comprehensive view of the organization will be privy to dependencies that your team is not aware of.
  • Learn how to identify your stakeholders here.

Possible Project Charter additions

Six Sigma Black Belt Certification Project Questions:

Question: In order for a problem to be solved correctly, which of the following must occur first? (Taken from ASQ sample Black Belt exam.)

(A) The problem must be defined.
(B) Relevant data must be gathered.
(C) The measurement system must be validated.
(D) The process must be mapped.

Answer: (A) The problem must be defined. Without a good problem definition, we do not know what data is relevant to be collected. Nor would we know what measurement systems to be used let alone how to validate it. And we could not even map the process without a good problem definition.

Project Charter Questions

Question: What is wrong with the following Business Problem statement?

We (Santa’s elves) started receiving a lot of letters complaining about erroneous coal deliveries on Christmas. Our goal is to create a specialized group of senior elves to handle this topic.

Answer: How would Santa’s workshop know that creating a specialized group is the right / most cost-effective solution? In order to effectively use Six Sigma techniques you must have the maturity to state that you don’t know what the answer is at the outset but will use rigorous data and analytical techniques to discern what the truth is. Stating the goal up front like this abrogates that process. A good business problem statement would objectively state the facts and not let opinions creep in.

Question: What is wrong with the following Business Problem statement?

The Tooth Fairy’s tooth-reclamation process is not optimal and a lack of communication leads to poor results.

Answer: How do you know the process is not optimal? What has been done to examine this? Again, here we’ve jumped past multiple phases of DMAIC.


Question: What is wrong with the following Business Problem statement?

The Letters to Santa client communication effort has led to poor results. We are unable to receive children’s toy request in a quick enough manner and our turn around cycle time leads to additional poor practices contributing to the wrong gifts being delivered to the wrong children. By creating a computer-based system to handle all external communication we should be able to reduced cycle time to 2 days and reduce incorrectly-delivered toys by 75% by December of next year.

Answer: While the level of detail is admirable, this business problem statement presumes a solution. How do they know that creating / deploying this software will fix the process?


Question: What is wrong with the following Business Problem statement?

The average processing time for Santa’s elves to verify the Naughty and Nice list exceeds staffing allowances. The distribution of verification times is not even and the outliers in morally grey areas can take weeks. This significantly impacts the staffing model.

Answer: There is nothing wrong. Great Business Problem Statement!

Question: What is wrong with the following Business Problem statement?

The travel policy for the tooth fairy’s teeth collection unit is not documented and the practices are not uniformly applied. The opportunity exists to document the process, update the training modules, and monitor compliance with strict controls.

Answer: Fails to demonstrate what the pain of the issue is. Also prescribes actions that may or may not be the best course of action.

Question: What is wrong with the following Business Problem statement?

Some group inside Global corporation X has a client acquisition cost of $20 per client. That group has an internal goal of client acquisition costs of $15 by the year 2020.

Answer: While this statement is specific, measurable, actionable, relevant and timely, it doesn’t explain the “why” of the goal. What is the point of pain for the organization if this project does not go through. While you might think that a cost reduction effort is self-explanatory, remember that every company has a large portfolio of projects that need to be rated against each other to decide which ones will be validated. Also, without an understanding of the amount of pain, how would you begin to understand the scale of the issue or calculate the ROI?

0 comments… add one

Leave a Comment