iSixSigma

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 4 months, 1 week ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • December 3, 2018 at 4:55 pm #208843

    Sharmin Saylor
    Participant

    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!

    0
    December 4, 2018 at 9:20 pm #208940

    Strayer
    Participant

    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.

    0
    December 7, 2018 at 10:55 am #209097

    Mike Carnell
    ★★★★★★★★★★
    Participant

    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.

    0
    December 7, 2018 at 12:32 pm #209100

    Chris Seider
    ★★★★★★★★★★
    Participant

    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.

    0
    December 10, 2018 at 1:27 pm #209352

    Rhb
    Participant

    Focus 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.

    0
    December 12, 2018 at 8:36 pm #209466

    Sharmin Saylor
    Participant

    @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
  • Author
    Posts
Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.