The project charter is a foundational deliverable created during the project’s initiation phase. The charter documents the project’s purpose, planned direction, and what is initially known.
It may be called a charter, proposal, grant, or request. It may be a formal contract or a less formal document. Regardless of the format, articulating the project’s intent is invaluable and harder than expected. Developing the charter often requires negotiating with stakeholders to align their support for the project.
Including the project manager early in the process is advantageous. It provides valuable context and helps them build stakeholder relationships. Critical decisions are made, and important assumptions, constraints, and risks are revealed. Early engagement reduces the learning curve and may avoid disastrous mistakes.
Once, I was asked to lead a project after the charter had been approved. The completion date was already set. Several weeks into the effort, I realized that the objectives were ill-defined, the original assumptions were unrealistic, and the project was doomed. These issues would have been uncovered sooner had I been involved in developing the charter.
The project charter is built on the business case. Many charter sections are refinements of similar business case components. While both documents can be updated, this typically does not occur unless there are significant changes in project direction.
The charter is tailored to the project’s needs. For example, large, complex, external projects require more formality than small, internal ones. Mature organizations and large enterprises may use a standard template. Review and approval requirements may follow organizational policies.
The charter generally contains the following sections:
The purpose describes the end-state objectives or reason for the project. It can describe the current business challenge and intended benefits or outcomes. The purpose establishes the “north star.” The team can return to the charter throughout the project to reorient themselves and guide future decisions.
The objective is sometimes obscured by the proposed solution. For example, a new application is requested without clearly defining the intended internal or customer benefits. A 5-Whys analysis can facilitate the purpose-discovery process by asking, “What problem are we trying to solve?” Often, a better solution exists.
The high-level narrative describes the project’s outcome, key deliverables, and boundaries. Distilling the project into a clear, well-articulated “elevator pitch” is invaluable. The descriptions should be inspirational and aspirational.
Defining external (customer-facing) and internal (team) deliverables clarifies expectations. Identifying what is in- and out- of scope sets project boundaries. Excluded items may be needed but are not the project team’s responsibility. For example, the team may create training materials but not deliver the training.
Critical success factors turn high-level objectives into measurable outcomes. They may be expressed as key performance indicators (KPIs), critical success factors (CSFs), or objectives and key results (OKRs). Regardless of the format, we want to have clear, well-defined expected outcomes. Well-written success factors follow the SMART construct—specific, measurable, achievable, realistic, and time-bound. For the new application, performance improvements (e.g., revenue, customer satisfaction, etc.) define “success.”
Stakeholders are anyone impacted by the project, its decisions, and its outcomes. Identifying stakeholders begins at initiation and continues throughout the project. Effectively engaging and managing stakeholder expectations is a key to project success.
During initiation, the goal is to identify critical individuals and constituencies impacted by the project. We want their input to establish alignment. Failure to achieve agreement will be a precursor to future issues and potentially lead to project failure.
Stakeholders can be internal or external. Internal stakeholders may include the project sponsor, senior management, the project team, oversight, and other impacted organizations. External stakeholders include customers, users, vendors, and suppliers. Community organizations and regulatory authorities will be important constituencies, particularly for public works or infrastructure projects.
After identifying the stakeholders, we should assess, concern, and influence. Our stakeholder list may be extensive, but we may only need to focus on a subset.
Requirements are statements of stakeholder needs and are progressively elaborated during the project. At this point, the goal is to identify high-level needs that describe the solution’s desired features and functions. Both functional (user-facing) and non-functional (technical) requirements should be identified. The requirements set expectations, define constraints, and are input into the cost and duration estimates.
The requirements for a new home may state the number of bedrooms and bathrooms and include high-level desires for a “chef’s kitchen” or “open concept design” that will be refined during the planning and design phases.
The charter includes a high-level project schedule, key milestones, and the estimated project budget. This information is updated from the business case and will be further refined during project planning, where the baselines will be established.
These estimates establish a cognitive anchor for stakeholders even though they are still preliminary and represent a range of uncertainty. At this point, the budget estimate may only be +50%/-30% of the final project costs.
Assumptions and constraints are identified and documented throughout the project. Both also represent risks and should be documented on the risk register.
Assumptions are known-unknowns. They are things we know that we don’t know. Therefore, we should document and validate them as soon as reasonable.
Constraints limit the project. Scope, schedule, cost, and quality are common primary constraints. Regulations, contracts, standards, and internal operating requirements are also limitations. Constraints should be documented and incorporated into our project planning and execution.
Risks are both opportunities and threats. Risk management is an ongoing process. We want to focus on high-level or overall project risks at this stage. What are the positive outcomes, and how can we ensure they will be achieved? What bad things can happen, and how can we reduce their likelihood or impact?
Risks should be documented as If/Then statements. If this event occurs, then this is the impact. We should start developing risk response strategies. Risks can be included in the charter and added to the project’s risk register.
Exit criteria describe what conditions must be fulfilled to close the project and serve as a bookend to the project objectives and critical success factors. The exit criteria help stakeholders define their expectations.
The approval requirements should identify those responsible for accepting interim and final project deliverables. Identifying approvers upfront clarifies project roles and expectations. An approval matrix can be developed for projects which multiple stakeholders and deliverables.
The project charter should name the project manager and sponsor, and establish their level of authority. This section may be influenced by the organization’s culture and formal operating guidelines. Defining the boundaries of authority speeds decision-making and reduces conflict. Project governance will be further defined in the project management plan.
© 2023, Alan Zucker; Project Management Essentials, LLC
See related articles:
I am available for in-person training and consulting. To learn more or to subscribe to my newsletter, visit our website: http://www.pmessentials.us/
Image generated by DALL-E
Leave a Reply