Within the Lean Six Sigma world, the Project Charter serves as a contract between an improvement team and the Project Sponsor or Champion. It provides essential clarity to everyone involved as to what they’ve all agreed to deliver. It helps to align the team with each other, with the Sponsor of the project and with the organization as a whole.
It’s often referred to as a “living document” which means it should be updated especially during the Define and Measure Phases of DMAIC. As the team maps and measures processes, they learn more about the project which changes the charter information. They update the baseline, add depth to the Problem Statement and expand the team if it makes sense. The charter is “alive” but changes are less likely once the Analyze Phase is complete.
There is a Project Charter template and, although the information required seems reasonable, the execution is not always obvious. Even with a sample list of questions to answer, it’s more helpful to see what others have done. It’s even helpful to see what others should not have done.
Although the trigger to starting a Project Charter is the discovery of a problem, there is flexibility in terms of which elements to complete first. We’ll follow a typical sequence and work through the 6 essential segments of the Project Charter. We’ll offer guidelines, review examples and highlight a few flagrant mistakes.
1. The Problem Statement
The Problem Statement clarifies the specific pain being experienced. This pain is commonly referenced in terms of excess time, defects or cost. Things are taking too long and there are too many mistakes and both those things will drive up costs. The pain is from the perspective of the customers of the process—internal or external. Problem statements reflect the Voice of the Customer.
Defining a problem sounds easy—“We’re losing money on textbooks,” or “Our application process takes too long.” Those definitely sound like problems. But the intent of a Project Charter is to provide clarity, and neither of those statements completely spells out the issue. How much money are we losing? Which text books? To make it easy to flesh out a Problem Statement, we’ve created 5 questions to answer.
We need to know:
- What is the exact problem?
- When is it happening?
- What is the magnitude or frequency of the problem?
- Where is it happening?
- What is the impact on customers & the organization?
These questions drive us to more clarity:
During the past 2 years (when) science textbook shipments have been missing (what is happening) 30% (magnitude) of the time for Beta Middle School (where) resulting in average yearly costs of $150K (impact).
This is a helpful Problem Statement. It’s got plenty of detailed measurements. Notice it only includes one problem, missing textbooks. They didn’t try to throw in other issues like, “science textbooks are missing and of inferior quality.” We’re trying to solve the problem of missing textbooks. Stay focused. But even focused teams can stray when they define problems.
I’ve seen Problem Statements like this:
The Maintenance Team is losing 30% of our textbooks due to disorganization which will require a new software installation to monitor and track all delivered textbooks to reduce the $150K yearly replacement costs.
Reading that you might sense some issues brewing. What happens when this well-meaning project team reaches out to the Maintenance Team to collect data? What happens when the shiny new software program fails to solve the problem? What you see in this statement are the 3 sins of Project Statements:
3 Sins of Project Statements:
- Root Cause
1. Blame (It’s the Maintenance Team)
If you name a person, group or department as responsible for the problem, you create a no-win situation. Even if you’re right, pointing the figure at a particular group guarantees you’ll have difficulty getting any data, information or cooperation from key Stakeholders. Point no fingers in a Problem Statement.
2. Root Cause (Due to disorganization)
If you include a root cause and you’re right, then you should go solve it and stop wasting time doing root cause analysis with DMAIC. But if you’re wrong, then you’ve kicked off a project with limiting assumptions. Assume no root cause in a Problem Statement.
3. Solutions (Software will fix it)
If you include a solution in the Problem Statement there are two places you could end up. If this is a verifiable solution to a known root cause, then implement it and call it a Quick Win (don’t waste time with DMAIC). But, if the solution is based on assumptions or gut instinct, then the implementation will cost money, waste time and the odds of solving the problem are low. Include no solutions in a Problem Statement.
The Problem Statement is the “starting line” of a project. It announces the baseline of the problem and clarifies the “as is” state of the process. You may not have the exact numbers, but you should know what you’re looking for and include placeholders to update during the Measure Phase—“X% of textbook shipments are missing”. Now let’s step back and consider the Business Case for addressing this issue.
2. Business Case
The Business Case is the “reason for being” of the project. It raises the focus up to the organizational level. Looking at this project through the eyes of the business and the end customers, does it make sense? Is it worth doing the project?
The Business Case should address these 4 questions:
- Why is this project worth doing?
- Why is it important to do now?
- What are the consequences of not doing this project?
- How does it fit in with business initiatives and targets?
Here’s a Business Case for conducting the missing textbook project:
For the past 2 year the Acme School District has been faced with reordering textbooks that have been lost or misplaced. This is happening across the district and results in losses of roughly $100K per school. In some cases this results in students going without course material for the start of the school year. Given the current strategic initiative to reduce waste in school supplies, addressing this project will impact the Key Process Indicator (KPI) of supply costs. If we don’t address this problem now, the cost of replacing missing textbooks will reduce the district’s budget for overall student learning materials. This threatens to erode the students’ overall learning experience.
The case is clear, it’s important to do this project. It is connected to the district’s organizational strategy, it’s aligned with the goals and tied to a Key Process Indicator. We have a problem and it’s worth addressing—time to establish a target with a Goal Statement.
3. Goal Statement
The Goal Statement is the measurable “finish line” of the project. It’s the target the team shoots for—the charter must be clear on what it means to succeed. We often ask for Goal Statements first because they’re easier for people to consider than a Problem Statement or Business Case. They’re shorter and the structure is tightly defined:
Goal Statement Format:
[Increase/Decrease] [Unit being measured] from a baseline of [baseline measure] to a target of [target level] by [date projected to reach target level]
Back to our textbook problem, their Goal Statement might look like this:
Decrease (verb) the percent of missing textbook shipments (units) from 30% (baseline) to 15% (target level) by June of this year (date projected to reach target level)
The Trouble With Goal Statements
People get into trouble with Goal Statements possibly more than any other aspect of the Project Charter. There are many great guidelines for Goal Statements, but we’ll focus on the most common misfires.
I’ve seen Goal Statements like this:
Streamline the textbook process with a new supply-ordering system that will improve the staff productivity related to managing textbooks, reduce shipping costs per school and reduce the percentage of reordered text books from 30% to 0% by Q2 of this year.
4 Sins of Goal Statements:
- Multiple Goals
1. Multiple Goals (productivity, shipping costs, missing books)
If you include more than one goal, then you run a few risks. For one, the team’s success rides on reaching not one but multiple targets. Hitting multiple goals might hinge on solving multiple root causes. This taxes the team, dissipates their focus and extends the life of the project. Pick one target that mirrors the baseline measure and leave it at that—set yourself up for success!
2. Vagueness (streamline, improve productivity)
There are lots of things that sound like good goals—“improve productivity” sounds great, but what does it mean, specifically? We need a clear-cut, measurable target in order to know when we’ve hit it. Include one measurable target in the goal statement and leave squishy terms out.
3. Solutions (supply-ordering system)
If the team didn’t stick a solution in the Problem Statement, they often try sneaking one in here. It seems rational to say that the goal is to implement a solution. Once again, if we truly know the solution then call it a Quick Win and call it a day. But if you’re writing a Goal Statement, include one, well-defined, measurable target. Solutions go in the Improve Phase (or the Solution Parking Lot), not the Project Charter.
4. Perfection (30% to 0%)
Pursuit of perfection is integral to process improvement but the journey to get there is iterative. If the team shoots for perfection out of the starting gate they will disappoint both themselves and everyone else. Set reasonable expectations—50% reduction/increase is a good rule of thumb. Remember, the idea is to continue improving the process. Perfection is a pursuit, not the end point—we can always do better.
Another helpful acronym is SMART goals (Specific, Measurable, Attainable, Relevant and Timebound). Remember, the goal—of a Goal Statement—is to make the measure of success abundantly clear. Problem Statements create the starting line and Goal Statements establish the finish line. These two statements must be mirror images, tightly constructed and clear. With these bookends established, the next element to address what happens in between—the Scope.
The question you’re dealing with here is, “how big does this thing get?” Projects tend to grow in the minds of leaders and ambitious team leads. Once a project is proposed, management often sees endless opportunities for expansion. The resulting projects sprawl and threaten to bury well-meaning problem solvers. The key is to use the Scope to declare boundaries and define what the team has agreed to address.
The Scope is answering two questions:
- What are the start and stop points of the process being addressed?
- What departments, product types, customers, areas, etc. are “in” and which are “out?”
Back to our textbook problem, their Scope might look like this:
- 1st Process Step: Order a year’s supply of textbooks
- Last Process Step: Place ordered textbooks in storage
- In Scope: Science textbooks, Beta Middle School, ordering system, communications with suppliers, Maintenance Team, storage facility
- Out of Scope: Non-science textbooks, all other district schools, book-selection process, classroom areas, students
The Scope of a project also seems straightforward but problem solvers unfamiliar with the concept of scoping can go astray. I’ve seen Scopes like this:
- 1st Process Step: Define the process problem
- Last Process Step: Control the improved process
- In Scope: Root cause analysis
- Out of Scope: Nothing
People sometimes confuse the steps of the process with the steps of DMAIC. They address the problem-solving process instead of the process being analyzed. The other red flag is seeing “nothing” out of scope. That means the team’s responsibilities are boundless.
The two things that help most with scoping the project:
- Use the SIPOC (high-level map) to determine the first and last process steps
- Err on the side of scoping tightly (avoid “boil-the-ocean” projects)
Some ways to tighten the scope is to limit which units are being studied. In the textbook example, the problem is happening across the Acme School District, but they are focusing on the Beta Middle School first. It’s often a great idea to solve the problem in one location or for one product family and then transfer the resulting solutions once the team has solved for root cause.
It’s a great way to contain the project without losing the upside of transferring the gains elsewhere. Keep that in mind when a well-meaning manager offers, “hey, while you’re working on that, you know what else you could tackle?” Say yes, and that you’ll address that once you solve the initial problem. When scoping, stay focused.
5. Project Timeline
This one is relatively easy, just hard to stick to. The trick is to be realistic about the “planned” completion dates. How fast are you planning to complete the project? Is this a 3-month project? A 4-month project? Bigger? Just like home-improvement projects, it’s hard to know what you’ll uncover during the course of the project—what’s under the “floorboards” is a mystery. But if it’s limited to one department, you have some existing data and you’ve got some helpful teammates, you can probably get it done in 3 months.
Here’s what the textbook project timeline might look like:
||Planned Completion Date||Actual|
Having the “Actual” column turns the timeline into a mini Confirmation Check Sheet which is handy when reviewing the reality of past project life cycles. The Timeline involves a bit of forecasting—an inexact science—and deadline setting which requires discipline. Set your timeline to be realistic with incentives to keep it moving. Nobody enjoys a project that extends endlessly and saps the momentum from Continuous Improvement efforts. Make sure your Sponsor supports you in carving out time for project work. Stick to the plan.
6. Team Members
Having team members might be a bit of a luxury for some problem solvers but it doesn’t hurt to ask. Even if there are Subject Matter Experts who plan to assist only when you need them, add them to the charter. It’s good for people to see that you plan to involve them. They’ll take their role more seriously. What’s critical is to have a Project Sponsor or Champion.
Here’s what the textbook project team structure might look like:
||Person||Title||% of Time|
|Team Lead||Larry Lead||Manager||20%|
|Project Sponsor||Mary Management||Director||10%|
|Team Member||Paula Perfect||Clerk||20%|
|Team Member||Harry Helpful||Clerk||20%|
|Process Owner||Own Overseer||Director||5%|
|SME – IT||Tanya Tech||IT Manager|
|SME – Finance Partner||Melvin Money||VP Finance|
|SME – Black Belt Coach||Marcia Mentor||Manager|
Subject Matter Experts (SMEs) including Finance Partners and the Black Belts are not regular team members but they can be essential to a project. The Finance Partner is critical for verifying that any claimed cost savings are real. It’s important to be able to substantiate return on investment. The worst case is claiming gains at the end of a project only to have Finance label them “wishful thinking.”
The biggest problem I’ve seen in this area is not having a Sponsor for the project. If there’s no Sponsor, there’s no project—period. Without someone in a leadership position to advocate for the team, address barriers and support the project, there is little likelihood of success. A team leader can work without a team, but the project will not survive without a Sponsor. Find a Sponsor and then build your charter.
Reflections on the Project Charter
The Project Charter is a great example of the adage, “plan your work and work your plan.” It’s the project guideline. Collaborate on the charter where possible and share it with the Project Sponsor to ensure alignment from the get-go. Clarity is king and the charter clarifies exactly what the team has agreed to accomplish. Follow these rules of thumb and you’ve got all the information you need to build a first-rate Project Charter.