Max earned his project management professional (PMP) certification in 2013. He holds an MA in Communication from U of I.
The project charter is the driving part of every project. While it is built prior to the planning and analysis for the project, it lays out at a high level why this project is needed, what is going to be done, risks and assumptions associated with this project, and the key members of the project team. It's important that the key members of the project team sign off on the project charter before works gets underway, so that everyone is in agreement about what everyone is working toward. This article outlines the key elements that should be included in every project charter.
Understanding the value proposition is crucial to understanding both the business need satisfied by the project and the return on investment associated with satisfying that need. If a business case was put forward associated with the initial project request, then you should be able to lift the value proposition from that and plug it into the project charter. However, there are a healthy number of businesses who still avoid exploring the value proposition associated with the work they elect to do, so they find themselves spending a lot of money run projects that return very little value in terms of either value added. If this exercise wasn't done prior to the project being approved, then you should pull that information together and plug it into your project charter so that everyone is aware of what they will get for the work and money they will put into this project.
Project Scope and Objectives
This is a high-level summary of the work that will be completed, along with a summary of the deliverables that will be the output of the project. For clarity, you should be clear about what is in scope for this project and about what will be out of scope for this project.
Risks and Assumptions
You need to list what risks you see on the horizon that could impact this project, and what assumptions have about the project. Risk to a project can come from a variety of places. If a vendor you want to work with is not in good shape financially, you may list it as a risk that you have to use another vendor who isn't as familiar with your company. Alternatively, there may be a risk that local, state, or federal government passes legislation that will make what you were doing as part of this project far less valuable. Additionally, you may be working on a project where environmental considerations are important. Maybe you're running a project that will require a lot of outside work over a period of time, and weather forecasters are predicting bad tornadoes during that time frame; you would definitely want to include that as a risk. The universe of risks is wide, and you want to make sure you not only list them, but have a plan in place to mitigate them.
Regarding assumptions, this primary comes in to play around resources and scheduling, as you'll likely have to make assumptions around developer resources available to you, testing resources available to you, and other forms of team member support.
Read More From Toughnickel
What to Include in a Weekly Project Status Report
Definition of Success
You should always have it clearly laid out what the criteria are for this particular project being a success. For this criteria, you need to start by reaching back and looking at the value proposition. For example, if you make a tool as a result of the project, and part of the value proposition associated with moving forward and creating the tool was that this tool would make it possible for your company to generate widgets twice as fast, then you would want to clearly state within the success criteria that part of what will make this project a success is if this tool generates widgets twice as quickly, among other things. All of the success criteria should be measurable, so that after a period of time the business can look back and determine if the project was a success, and if it wasn't they will want to dig into it and understand where they went wrong.
This would be a high-level summary of the major pieces of work that will need to be completed to finish this project. You should also have work with the necessary teams to generate rough order of magnitude estimates around each of these milestones to get a feel for how long each of them will take.
Project Team and Stakeholders
You need to list all members of the project team. At the top you should have an executive sponsor, who should be someone at a higher level in your organization who can serve as a champion for this project. You can generally slide the person who submitted the business case into this role if they are a more senior person in your organization. From there, you should have a representative stakeholder from each functional area that will be affected by the outcome of this project. For example, this may mean you involve individuals from human resources, finance, IT, sales, and other areas as necessary. Additionally, you need to include the people who will actually be doing the work on the project.
It is absolutely critical that everyone identified as a stakeholder signs off on the project charter, indicating that they are in agreement with the high-level assessment of the work that needs to be done, the schedule for getting that work done, how they want to measure whether it was successful, and who needs to be involved. If you don't get signatures and dates on paper, then it leaves open the option for someone to come back and say that there was additional work that was agreed upon by the team that isn't being done as part of the project. If you have a project charter that everyone has signed off on, you can refer back to that and clearly see whether or not that person has a valid point and take the necessary action.
This article is accurate and true to the best of the author’s knowledge. Content is for informational or entertainment purposes only and does not substitute for personal counsel or professional advice in business, financial, legal, or technical matters.
© 2016 Max Dalton