The Project Charter

What Should Be in a Project Charter?

The framework for a project charter should be based on the project management knowledge areas. Although the formality and depth of developing a project charter will most likely depend on the size and complexity of the project, the fundamental project management and product-development processes and areas should be addressed and included for all projects. This section presents an overview of the typical areas that may go into a project charter; however, organizations and project managers should adapt the project charter based on best practices, experience, and the project itself.

Quick Thinking - The Project Sponsor

According to Gopal Kapur, president of the Center for Project Management, "Sponsorship is not a spectator sport". A project sponsor should be an executive or manager with financial authority, political clout, and a personal commitment to the project. An effective sponsor is critical to the success of an IT project. Although no formal job description exists for a project sponsor, most agree that the project sponsor must provide leadership and direction, as well as political protection and problem-resolution skills. The project sponsor "champions" by:

  • Empowering the project manager
  • Ensuring sustained "buy in" from other project stakeholders
  • Clearing political and organizational roadblocks
  • Ensuring the availability of resources
  • Reviewing the project’s progress
  • Approving plans, schedules, budgets, and deliverables
  • Ensuring that the project’s goal is realized

However, as Gopal Kapur explains, "Of all the items that can go wrong on a project, the one the project manager has the least control over is the sponsorship". Often when an IT project experiences problems, there’s a good chance the sponsor is to blame.

  1. Why is a good project sponsor or champion so important to the success of an IT project?
  2. How could a project manager or team handle a situation where the project sponsor leaves the organization to take a job with another company?
  3. How should a project manager handle a project sponsor who is either incompetent or loses interest in the project and withdraws?

Project Identification

It is common for all projects to have a unique name or a way to identify them. It is especially necessary if an organization has several projects underway at once. Naming a project can also give the project team and stakeholders a sense of identity and ownership. Often organizations will use some type of acronym for the project's name. For example, instead of naming a project something as mundane as the Flight Reservation System in 1965, American Airlines named its system Semi-Automated Business Research Environment (SABRE). Today, SABRE has become a well recognized product that connects travel agents and online customers with all of the major airlines, car rental companies, hotels, railways, and cruise lines.

Project Stakeholders

It is important that the project charter specifically name the project sponsor and the project manager. This reduces the likelihood of confusion when determining who will take ownership of the project's product and who will be the leader of the project. In addition, the project team should be named along with their titles or roles in the project, their phone numbers, and email addresses. This section should describe who will be involved in the project, how they will be involved, and when they will be involved. Formal reporting relationships can be specified and may be useful on larger projects. In addition, including telephone numbers and email addresses can provide a handy directory for getting in touch with the various participants.

Project Description

The project charter should be a single source of information. Therefore, it may be useful to include a description of the project to help someone unfamiliar with the project understand not only the details, but the larger picture as well. This may include a brief overview or background of the project as to the problem or opportunity that became a catalyst for the project and the reason or purpose for taking on the project. It may also be useful to include the vision of the organization or project and how it aligns with the organization's goal and strategy. Much of this section could summarize the total benefits expected from the project that were described in the business case. It is important that the project description focus on the business and not the technology.

Measurable Organizational Value (MOV)

The MOV should be clear, concise, agreed on, and made explicit to all of the project stakeholders. Therefore, the project's MOV should be highlighted and easily identifiable in the project charter.

Project Scope

The project's scope is the work to be completed. A specific section of the project charter should clarify not only what will be produced or delivered by the project team, but what will not be part of the project's scope. This distinction is important for two reasons. First, it provides the foundation for developing the project plan's schedule and cost estimates. Changes to the project's scope will impact the project's schedule and budget - that is, if resources are fixed, expanding the amount of work you have to complete will take more time and money. Therefore, the creation of additional work for the project team will extend the project's schedule and invariably increase the cost of the project. Formal procedures must be in place to control and manage the project's scope. Secondly, it is important for the project manager to manage the expectations of the project sponsor and the project team. By making the project's scope explicit as to what is and what is not to be delivered, the likelihood of confusion and misunderstanding is reduced.

For example, the project team and several users may have several discussions regarding the scope of a project. One user may suggest that the system should allow for the download of reports to a wireless personal digital assistant (PDA). After discussing this idea in depth, management may decide that the cost and time to add this wireless PDA capability would not be in the organization's best interest. In this case, it would be a good idea to state explicitly in the project charter that wireless PDA capability will not be part of the project's scope. Although you may be clear on this issue, others may still have different expectations. The project's scope should, therefore, define key deliverables and/or high-level descriptions of the information system's functionality. The details of the system's features and functionality will, however, be determined later in the systems development life cycle when the project team conducts an information requirements analysis.

At this point, a first attempt is made to define the project's scope and is based on information provided by the project sponsor. Only enough detail is needed to plan the project so that estimates for the project schedule and budget can be defined. This may include a high-level view of the project and product deliverables and the criteria for their acceptance by the project sponsor. Detailed system requirements will be specified later on during the execution phase of the project when the SDLC is carried out.

The scope defined in the project charter can take the form of a narrative description of the products or services produced by the project. This narrative is often called the statement of work (SOW). The SOW can be developed by the project sponsor or by interviewing key stakeholders conducted by the project team.

Project Schedule

Although the details of the project's schedule will be in the project plan, it is important to summarize the detail of the plan with respect to the expected start and completion dates. In addition, expected dates for major deliverables, milestones, and phases should be highlighted and summarized at a very high level.

Project Budget

A section of the project charter should highlight the total cost of the project. The total cost of the project should be summarized directly from the project plan.

Quality Issues

Although a quality management plan should be in place to support the project, a section that identifies any known or required quality standards should be made explicit in the project charter. For example, an application system's reports may have to meet a government agency's requirements.

Resources

Because the project charter acts as an agreement or contract, it may be useful to specify the resources required and who is responsible for providing those resources. Resources may include people, technology, or facilities to support the project team. It would be somewhat awkward for a team of consultants to arrive at the client's organization and find that the only space available for them to work is a corner table in the company cafeteria! Therefore, explicitly outlining the resources needed and who is responsible for what can reduce the likelihood for confusion or misunderstanding.

Assumptions and Risks

Any risks or assumptions should be documented in the project charter. Assumptions may include things that must go right, such as a particular team member being available for the project, or specific criteria used in developing the project plan estimates. Risks, on the other hand, may be thought of as anything that can go wrong or things that may impact the success of the project. Although a risk management plan should be in place to support the project team, the project charter should summarize the following potential impacts:

  • Key situations or events that could significantly impact the project's scope, schedule, or budget - These risks, their likelihood, and the strategy to overcome or minimize their impact should be detailed in the project's risk plan.
  • Any known constraints that may be imposed by the organization or project environment - Known constraints may include such things as imposed deadlines, budgets, or required technology tools or platforms.
  • Dependencies on other projects internal or external to the organization - In most cases, an IT project is one of several being undertaken by an organization. Subsequently, dependencies between projects may exist, especially if different application systems or technology platforms must be integrated. It may also be important to describe the project's role in relation to other projects.
  • Impacts on different areas of the organization - As described in Chapter 1, IT projects operate in a broader environment than the project itself. As a result, the development and implementation of an IT solution will have an impact on the organization. It is important to describe how the project will impact the organization in terms of disruption, downtime, or loss of productivity.
  • Any outstanding issues - It is important to highlight any outstanding issues that need further resolution. These may be issues identified by the project sponsor, the project manager, or the project team that must be addressed and agreed upon at some point during the project. They may include such things as resources to be provided or decisions regarding the features or functionality of the system.

Project Administration

Project administration focuses on the knowledge areas, processes, and controls that will support the project. These are actually separate subplans or strategies that make up the project management plan. Administration may include:

  • A communications plan that outlines how the project's status or progress will be reported to various stakeholders. This plan also includes a process for reporting and resolving significant issues or problems as they arise.
  • A scope management plan that describes how changes to the project's scope will be submitted, logged, and reviewed.
  • A quality management plan that details how quality planning, assurance, and control will be supported throughout the project life cycle. In addition, a plan for testing the information system will be included.
  • A change management and implementation plan that will specify how the project's product will be integrated into the organizational environment.
  • A human resources plan for staff acquisition and team development.

Acceptance and Approval

Since the project charter serves as an agreement or contract between the project sponsor and project team, it may be necessary to have key stakeholders sign off on the project charter. By signing the document, the project stakeholder shows formal acceptance of the project and, therefore, gives the project manager and team the authority to carry out the project plan.

References

In developing the project charter and plan, the project manager may use a number of references. It is important to document these references in order to add credibility to the project charter and plan, as well as to provide a basis for supporting certain processes, practices, or estimates.

Terminology

Many IT projects use certain terms or acronyms that may be unfamiliar to many people. Therefore, to reduce complexity and confusion, it may be useful to include a glossary giving the meaning of terms and acronyms, allowing all the project's stakeholders to use a common language. Figure 3.3 provides a template for a project charter. Feel free to adapt this template as needed.

Project Charter Template
  • Project Name or Identification
  • Project Stakeholders
    • Names
    • Titles or roles
    • Phone numbers
    • E-mail addresses
Project Description
  • Background
  • Description of the challenge or opportunity
  • Overview of the desired impact
Measurable Organizational Value (MOV)
  • Statement or table format Project Scope
  • What will be included in the scope of this project
  • What will be considered outside the scope of this project
Project Schedule Summary
  • Project start date
  • Project end date
  • Timeline of project phases and milestones
  • Project reviews and review dates
Project Budget Summary
  • Total project budget
  • Budget broken down by phase
Quality Issues
  • Specific quality requirements
Resources Required
  • People
  • Technology
  • Facilities
  • Other
  • Resources to be provided
    • Resource
    • Name of resource provider
    • Date to be provided
Assumptions and Risks
  • Assumptions used to develop estimates
  • Key risks, probability of occurrence, and impact
  • Constraints
  • Dependencies on other projects or areas within or outside the organization
  • Assessment project's impact on the organization
  • Outstanding issues
Project Administration
  • Communications plan
  • Scope management plan
  • Quality management plan
  • Change management plan
  • Human resources plan
  • Implementation and project closure plan Acceptance and Approval
  • Names, signatures, and dates for approval
References
Terminology or Glossary
Appendices (as required)