You will need to know about outputs for the Develop Charter Project to get your PMP certification. After all the information gathering and analysis, you can start to document information in an organized fashion, and voilà! The charter is created.
In some organizations, the charter is created by the sponsor, customer, PMO, or some other entity and then handed to the PM. In other organizations, the PM either assists in the creation or actually creates the charter and then gets approval from the sponsor, PMO, or whoever is appropriate. Regardless, it is good practice to make sure that the project manager is involved in some manner when developing the charter.
The charter should provide a summary of the project with enough information that the initial project team can read it, absorb it, and then use progressive elaboration to plan the project in detail. Here is an example of what the PMBOK Guide says are contained in the charter.
The needs of the organization and the project should determine the actual contents.
| Charter Content Item | What It Does |
|---|---|
| Purpose and justification | The reason why the project is being undertaken. May refer to the business case, the strategic plan, external factors, a contract, or any other document or reason for performing the project. |
| Objectives | The strategic position the project is being undertaken to
deliver, or the result to be achieved. There are usually multiple objectives, such as objectives for scope, schedule, cost, quality, customer satisfaction, and so on. |
| Success criteria | Measurable criteria that correspond to each objective to indicate that the objective has been successfully met. |
| High-level requirements | The high-level business and compliance requirements must meet customer expectations. (These are not detailed requirements but merely initial, high-level requirements.) |
| Assumptions and constraints | The initial assumptions about scope, resources, funding,
approach, and other project variables. Constraints are the initial limitations, such as a fixed due date or budget. |
| High-level project description | A summary-level description of the project. May include information on high-level project and product deliverables as well as the approach to the project. |
| High-level risks | The initial risks. These will later be progressively elaborated and entered into a risk register. |
| Summary milestones | Significant events in the project. May include the completion of deliverables, phases or product acceptance. |
| Summary budget | The initial range of estimated expenditures for the project. |
| Stakeholder list | The initial list of stakeholders who can influence or will be influenced by the project, product, service or result. |
| Approval requirements | Who can approve and sign off on each deliverable and the criteria for acceptance. |
| PM Authority: Staffing Technical decisions Conflict resolution Budget management |
The authority to hire, fire, discipline, accept, or not accept
project staff. The authority to make technical decisions about deliverables or the technical approach. The authority to resolve conflict within the team, the organization, and external stakeholders. The authority to commit, manage, and control project funds. Includes variance thresholds. |
| Sponsor, PM signatures, and other relevant signatures | Demonstrates commitment and approval for the project. |
In some organizations, you see high-level assumptions and constraints documented in the charter. In others, you might see an Assumption and Constraint log that would start with the high-level assumptions during project initiation. While the project progresses, you would see more detailed assumptions. Examples of high-level assumptions include
We will use internal resources to staff the project.
The market will accept the new product.
Funding will be available.
Examples of high-level constraints can include regulations, fixed delivery dates, and a budget cap.