The Project Charter holds the information that you uncovered in the project definition process. The Project Charter is written by the project manager and approved by the project sponsor to show that there is an agreement on the work to be completed.
The information in the Project Charter typically includes:
Executive Summary (optional). The full Project Charter document may tend to become large and difficult for the senior managers to digest. You can include an Executive Summary for managers to read. The Executive Summary is an overview of the actual Project Charter document. It is not just an overview of the project.
Project Overview. State the purpose of the project. Discuss the business benefit of the project and share the overall business goals that this project is contributing to.
Project Objectives. State the objectives that the project will achieve. The project objective should support your organization business goals and strategies. The deliverables produced should support the project objectives.
Project Scope. There are two parts to the scope section – deliverables and boundary statements. For each deliverable, provide a high-level description. Understanding the project deliverables goes a long way toward describing the project scope. It is very important to be clear about what things the project could produce, but will not. This will make it much easier to manage scope change throughout the project.
In addition to deliverables, you should also state any project boundaries. Boundaries are ways to articulate aspects of the project that are in scope versus aspects that are out of scope. It is a good practice to state scope boundary conditions in terms of both in-scope and out-of-scope statements. You should further describe scope in more specific terms such as:
The data the project needs and the data that is out of scope
The organizations affected and those that are not affected
The business processes that are in scope and out of scope
The business transactions that are in scope and out of scope
Any other in-scope / out-of-scope qualifiers that make sense
Estimated Effort Hours. Estimate the effort required, and provide information on how the estimate was prepared. You may need to be working on the schedule at the same time as you are working on the Project Charter to be able to provide an accurate estimate.
Estimated Duration. Once the effort hours are known, you can estimate how long the project will take to complete (duration) based on an assumption of how many resources will be applied. If the start-date is known, the estimated end-date can be determined as well. You may need to be working on the schedule at the same time as you are working on the Project Charter to be able to provide an accurate estimate.
Estimated Cost. Estimate the cost for labor based on the effort hours, and add any non-labor expenses such as hardware, software, training, travel, etc. You may need to be working on the schedule at the same time as you are working on the Project Charter to be able to provide an accurate estimate.
Major Assumptions. Assumptions are statements that you believe to be true but you are not 100% certain. There may be external conditions or events that must occur for the project to be successful. If it looks more than likely that these events will occur, they should be listed as assumptions. Assumptions can be identified through your own experience of knowing the activities or conditions that are likely to occur in your organization over the life of the project; brainstorming sessions with the clients, stakeholders and team members; and by looking at items that were identified as low risk in the risk management process.
Major Risks. There may be future external conditions or events that will cause problems to the project if they occur. If there is a good likelihood that any of these events will occur then they should be identified as a risk.
Project Constraints. Constraints are events or limitations that are outside the control of the project team and need to be managed around. They are not necessarily problems. They are not risks since they are 100% likely to occur. They are facts. Date constraints, for instance, imply that certain events (perhaps the end of the project) must occur by certain dates.
Project Dependencies. List any other projects that are in progress of pending that have a dependency with your project. These dependencies are deliverable-based. That is, a project will pass a deliverable to you or you will pass a deliverable to the other project. Don’t consider a project to be dependent simply because you might share a resource with it.
Project Approach. At a high level, describe in words the information that is represented in the project schedule. This information is for the benefit of the client and stakeholders that will not be able to easily interpret the actual schedule. You should describe major project phases and milestones, and the general sequence of the work. You should also communicate when the major deliverables will be produced. Also take some time to explain any interesting or out-of-the-ordinary techniques that will be utilized on the project – for instance Rapid Application Development (RAD), Joint Application Design (JAD) sessions, etc. Depending on the size of your project, this section could be fairly long, but should not go over two pages.
Project Organization. The organization chart for a large project usually has many boxes that reflect involvement from various stakeholders. For instance, the project may have a formal project manager from the client organization that also reports to the project sponsor. There may be a high-level executive sponsor, as well as a lower-level project sponsor to represent the sponsor on a day-to-day basis. Key stakeholders may be organized into a steering committee to provide overall strategic guidance to the project. Vendors or suppliers may have a formal role and would need to be represented in the organizational structure.
tenstep.com