Project Charter:
The Right Start to Save Your Business Money
And make you look like a hero…
In this article (press to expand)
Make Your Project Idea Into a Reality
Everyone has that one process at work that they wish they could improve, something that doesn't work as efficiently as they would like.
You can probably imagine that problem right now, you just haven't gotten around to fixing it, or you can't convince your boss or colleagues to buy in.
We're going to show you something to turn that project idea into a reality. It's called a project charter, and it's the document that justifies the value of your idea to the business and gives you a clear roadmap to success.
Used alongside the DMAIC framework, it'll track your progress and guide you in understanding the direction the project needs to proceed in.
What is a Project Charter?
It outlines all the benefits, scope, timeline, project team and all the potential risks involved. The kind of thing management wants to see before changing things. It's like a contract between the team executing the project and the business.
It's typically prepared by the project leader or manager, often a Black Belt or Green Belt, in consultation with the Process Owner and the participating team.
The project charter is first prepared in advance of project authorisation and start-up. It's the key document for review at the Define tollgate (the D in DMAIC), and it's revised and reviewed again at each subsequent tollgate review.
It's a living document that tracks the progress and changes in understanding and direction as the project proceeds.
Make a Project Charter in 10 Steps
(+ Quick-Start Template)
Need Help With Your Project Charter?
Get Free Project Support from Martin Hayden, Master Black Belt.
Book a free call today.
0. Download a Project Charter Template (Optional)
Our project charter template outlines all the information needed. We have Microsoft Word and Google Docs versions.
Download .docx Open Google Doc
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.
Conclusion
You should have been able to fill in the first 8 sections of your project charter, and it should now be ready for project approval.
The project charter forms the basis of the first Tollgate Review of the first stage in a Lean Six Sigma DMAIC project. That stage is called Define (the D in DMAIC).
In the next post, we'll go into what the objectives of the Define tollgate review are how exactly to run one. We'll even give you some free resources to help you kick-start your own.