When you’re ready to start a project you need to create a Project Charter. In our last Blog we went over the consequences of not having a charter. Today, we’re going to cover the steps you need to take to create a Project Charter. There is no specific template. There isn’t a formula, like a math equation. You have a lot of flexibility and you should create a process that matches your culture and environment. There are, however, elements that need to be in your charter. Just as importantly, you need to always remember that the purpose of the Charter is to make disagreements apparent. IF, and only IF, everyone is in agreement the Charter process ensures that you stay on track. Let’s take a look at the steps you need to take:

Charter Document: Try to keep as much of the following in a single document. It doesn’t matter if it’s Word or PowerPoint or something else; just use whatever is comfortable for you. Try to keep to just one document, that is physically signed by all the participants. If you need to you can have supplementary documents, but try to keep all the key data in the one document.

The Project:Make sure that this is just one project. If you have more than one project, that’s fine. Just create more than one Project Charter. A given charter may have more than one action, or doing one project may imply other projects (that don’t need to
be described in this document… remember, keep it simple). However, if there are
obvious “other” projects make sure that this is not a surprise to the rest of the group. If it is not in the Project Charter, it needs to be touched on in the stakeholder meeting.

Describe the project: It can be just a few sentences. You don’t need to go into a great deal of detail. That can lead to lengthy discussions over the details, even when there
is agreement on  the overall project. A description like, ”Reduce errors in documents by installing custom spell checker dictionaries and ensuring that 100% of document are spell checked.” Make it as basic as possible, but use as much space as you need.

List stakeholders: List all the stakeholders, all team participants, and the sponsor. Not all stakeholder will necessarily need to do anything for your project, but they need to be
involved enough to know what’s going on. For a lot of stakeholders I’t not so important if they will help the project “go”’ it’s more important to know if they plan on making the  project “stop”.

List the team: Who will do the actual work for the project? If you don’t have a dedicated improvement group, it may require more of a time commitment than the team you have pulled together. Do you need to expand the team, or do the team member’s managers need to free up more of their time? This is an important issue for the success of the project. Don’t sweep it under the carpet. Make sure that this is loud and clear in the meeting!

List the sponsor: One big, but frequent, mistake is that projects move ahead without a clear sponsor. Make it clear who is asking for this project and that they MUST physically
sign the Charter (e-signature is fine) before the project proceeds.

Review meeting: Remember, the purpose of the meeting is NOT to get the Charter signed. If it’s a difficult project with cranky team members, you may just want to get through the meeting and move on. DON’T DO IT! The purpose of the meeting is to get all the key individuals to get all of their issues, disagreements and problems on the table. The 1^st draft of the Charter is just the talking point, it is not a sacred document. Be prepared for it to be blown out of the water. That’s fine. Even if the project comes to a stop and is taken off of your project list, it is better for a project to die a quick death before resources
are spent rather than have a painful and lingering death after you’ve spent months working on the project. So, be prepared to have at least one follow-up meeting to re-review the 2^nd draft.

Signatures: Your template for a Project Charter can be anything you want it to, but I recommend that you have more than just the sponsor sign. The extent of the signature
process depends on the size of theproject, the degree of contention, etc. If you currently have a lot of contention during or after a project about who agreed to what… sounds like you need more signatures rather than less.

Charter updates: While the project is ongoing, changes almost always happen. Sometimes the changes are small, sometimes the changes are large. As changes build up over the lifetime of the project, you can sometimes drift from the original goal. Which is one of the major causes for friction after a project: “I never signed off on that change”, “This project is not what I signed off on”, “Why was this change approved without my involvement”, “You removed an important component… the project is a failure!”. Avoid all that by having a formal change process for the charter. There are no hard and fast rules, but I recommend that if the project is under 30 days you don’t need to meet or modify the charter, unless there is a major change (and that might be done by email). If the project is more than 30 days, have a regular meeting (every two weeks, every moth, etc.) to go over changes. If there are no changes, the meeting can be skipped (after emailing everyone… “I
haven’t heard of any changes team, should we cancel this meeting?”).  If a big change happens today, you may need a special meeting.

Project completion: Once the project is over, you need one more meeting. This serves two important purposes. The first is actually ending the project. Project can either go on forever or the final completion steps of a project are never completed, and then the improvements never quite work as expected. The completion meeting is where you check, and everyone in the meeting agrees, that they have delivered everything they are supposed to (and no one is “covering” for a friend). The second reason is that the project sponsor is incentivized to check the details. For example, training may have updated the training materials  to reflect project updates, but a manager may not agree that the materials are inadequate. They may be poorly written and missing information. This is the opportunity to say there is a problem. Everyone who had any sort of deliverable must sign off.

Sponsor acceptance: When all the team members and stakeholders have signed off, then the sponsor does a final signoff. This is the sponsor’s agreement that the project was
completed to their satisfaction.

That’s about it. Each of these steps has a separate tangible benefit, but it all comes down to informing everyone who needs to know and driving out issues and problems early in the process. Remember, using the Charter to drive success for a project is very important. However, using the Charter to identify a project that will never succeed is even more important. Maybe a bad project can be rehabilitated, or maybe it needs to be killed. Getting a bad project off of your agenda will free up resources and improve your team’s morale. Spend your time on the projects that sponsors want, and that will succeed! And that’s my Niccolls worth for today!