How Do You Know Whether a Project Charter Is Well Written?
Six Sigma – iSixSigma › Forums › General Forums › Implementation › How Do You Know Whether a Project Charter Is Well Written?
This topic contains 5 replies, has 5 voices, and was last updated by Sharmin Saylor 2 months, 1 week ago.
- AuthorPosts
- December 3, 2018 at 4:55 pm #208843
Sharmin SaylorParticipant@SharminInclude @Sharmin in your post and this person will
be notified via email.Hi everyone — I’m new here and interested in becoming a top change agent at my company. But I’m the first to admit that I still have a lot to learn. :)
For example, how do you know whether you wrote a project charter is good or not.
What if it’s well defined, but not “hard enough” for the green or black belt?
Is a “sign off” by the process owner enough to ensure that they’re bought into the project before you start it?
How do you ensure you have the resources needed to solve the problem if you don’t know what the solution is for another few weeks?
It all start with the project charter, right? So how do you know you have a good project charter to start the project off right?
Thank you!
0December 4, 2018 at 9:20 pm #208940
StrayerParticipant@StraydogInclude @Straydog in your post and this person will
be notified via email.Good question. The initial charter is a proposal, not a plan. Some organizations want to make it a project plan that you commit to and require things you won’t know at the beginning, so people fudge things such as metrics, staffing, schedule, budget, etc. To me, the most important part of the charter is the problem statement. Clearly state a specific problem with evidence that it really exists, and it’s cost to the business. That should be enough to get signoff, at least to do the work needed to put together a plan and flesh out the charter to the point your organization requires for a go/no-go decision. That said, most six sigma projects should not be big projects requiring all the rigors of formal project planning. There’s a problem. Let’s find the cause and fix it quickly and cheaply. That’s DMAIC.
0December 7, 2018 at 10:55 am #209097
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.Sharmin Saylor Strayer gave you some good advice. Stay focused on the problem statement. People need to get it out of their heads that these documents are a one shot deal. The whole idea of a project is a learning experience to understand relationships between x and y variables. As you learn more and gain more information the whole understanding can change and therefor the charter and even the problem description can change. It is rare to not spin off other projects to avoid scope creep.
For those people that want a detailed plan before the project starts just ignore them. If you could do that the problem would have already been solved.
What you do want to be as accurate as possible on (and update frequently) is the financial model. There are some projects that will create zero benefits but if someone approves them because of strategy then you want to make sure that gets documented. Every change you need to update the model. The real benefit for you is that after a few projects you will understand more than just the technology of the business. You will understand the business of the business. You will find out very quickly they are distinctly different things. Someone who understands both is a very valuable person.
Just my opinion.
0December 7, 2018 at 12:32 pm #209100
Chris SeiderParticipant@cseiderInclude @cseider in your post and this person will
be notified via email.And besides the other comments, PLEASE have a validated primary metric and secondary metrics that also impact the business–don’t forget financial benefit is ONE of potential good secondary metrics.
0December 10, 2018 at 1:27 pm #209352Focus on the “Problem Statement”. I use a check system with the problem statement that requires it answers the questions, “What, when, where and how much?” Also, keep in mind that the Charter is a living document that may require modification as the project progresses. Also, projects may require counter balance metrics. e.g. a counter balance metric may be, quality, scrap, etc. Stated, financial performance will improve by x, while maintaining the same or improved quality level. OEE metrics are good kpi’s for projects.
0December 12, 2018 at 8:36 pm #209466
Sharmin SaylorParticipant@SharminInclude @Sharmin in your post and this person will
be notified via email.@Straydog: “The initial charter is a proposal, not a plan.”
@mike-carnell: “As you learn more and gain more information the whole understanding can change and therefor the charter and even the problem description can change.”
@cseider: “Have a validated primary metric and secondary metrics that also impact the business.”
@rhb306: “The Charter is a living document that may require modification as the project progresses.”
Such great input. Thank you one and all! This will definitely help me as I go forward.
0 - AuthorPosts
You must be logged in to reply to this topic.