THE PROJECT CHARTER

Taking the time to describe a project before undertaking it can go a long way toward ensuring project success. Consider the project sponsor who said that his agency did not have time to develop project charters; instead of excessive advance planning, that time would be better spent getting the work done. His perception had probably evolved from his own frustration with project managers who spent too much time planning and never got to the work. This perception is often accurate when it involves inexperienced project managers who adopt a specific methodology and stick to it relentlessly without regarding the particular needs of each project. If the project planning effort is not scaled to the specific needs of a project, senseless, costly planning can certainly lead to a waste of time and resources.

Project managers should aim to conduct only a sufficient amount of advance planning needed to ensure the project's success—no more and no less. A clear, sufficiently detailed project charter provides enough direction needed to orient a project team as it prepares to tackle a project. The project charter, regardless of the nature and scope of the project it describes, includes twelve basic elements:

Vision – The end state produced by the project, as envisioned by the project sponsor.

Business problem or opportunity – What the project is launched to address.

Objectives – The value the project will provide to the organization.

Deliverables – A description of the end product or service generated by the project.

High-level schedule – A broad, general outline of key dates impacting the project (e.g., start date, end date, intermediate milestones).

Constraints – Internal and external factors that could limit the project's scope, schedule, or cost.

Assumptions – Statements about the project that are believed to be true and could impact the project's scope, schedule, or cost.

Risks – Potential events that could impact the project's scope, schedule, or cost.

Team roles and responsibilities – A description of the anticipated project team and its members’ skill sets.

Budget – A high-level estimate of anticipated project costs.

Scope statement – A description of project parameters; i.e., what will be included in and excluded from the project.

Sponsor approval – The signature of the project sponsor, authorizing the project and its funding.

Vision

The project vision is a critical element of a good project charter. For a project to be successful, those undertaking it must have a good idea of how to achieve its objectives and whether the goal is worth the effort. Project managers must clearly articulate a vision to the members of the project team and to other project stakeholders.

A contractor once told clients who wanted to build a new house, “If you can't describe it, I can't build it.” When the couple were unable to describe exactly what they wanted, the contractor recommended that they reconsider the project.

In this example, the couple were the project sponsors. By definition, project sponsors authorize and allocate funds to the project. They clearly are in a position to influence the project in meaningful ways. It is the sponsor's vision that launches the investment and charts the course for the project team.

A good project vision statement is brief—usually not more than a paragraph long—and should be clear and easy to explain. To adequately support the project's needs, project stakeholders providing resources must be able to understand the project sponsor's vision. With a clear vision in mind, project stakeholders can stay focused on the right direction and can reorient when obstacles get in their way.

Vision statements laced with technical acronyms and jargon specific to an industry are subject to misinterpretation. Acronyms and jargon common to one industry may not have any meaning to someone working in an entirely different industry. Consider a simple acronym like PSR. In the project management world, the initials traditionally stand for project status report. In the marketing industry, the acronym might stand for product sales ratio. Acronyms and jargon are common and convenient for expediting communications, but they can cause confusion, too.

Business Problem or Opportunity

The business problem or opportunity describes the impetus for the project. The need for a project typically arises from a business problem that requires a solution or an opportunity the business would benefit from facilitating. A basic measure of project success, then, is to consider whether the project solved the problem or facilitated the opportunity.

Objectives

Project objectives identify the specific business value that the project will provide to the organization and provide clear, definitive criteria for project success or failure. Often a number of project objectives spring directly from the project sponsor's vision.

Objectives come in two forms: functional and implied. Functional objectives can be traced directly to the project vision. For example, consider a project vision that includes a new office building constructed within Denver's city limits. The building will provide space for the business's accounting department, which has 100 employees, and it will support a state-of-the-art IT and communications infrastructure.

Several functional objectives can be derived directly from the vision statement:

This will be a new office, not a renovation.

The new office will be located within Denver's city limits.

It will provide office space for 100 accounting employees.

It will support a state-of-the-art IT and communications infrastructure.

Each of these functional objectives can be traced directly to the vision.

Implied objectives evolve from the more technical aspects of a project. Implied objectives are inherently related to the project's functional objectives and make them achievable. The functional objectives cited above could suggest the following implied objectives:

Land suitable for the project must be acquired within Denver's city limits.

The building will meet all Denver and Colorado building codes requirements.

All projects have both functional and implied objectives that should provide some value to the organization. It is imperative that all project objectives be traceable to the project vision statement. Any objective that does not support the project vision is extraneous and beyond the scope of the project.

Deliverables

A project ultimately develops a deliverable—a product, service, or other solution—for an organization. While the project vision and objectives are stated in more general terms, the project charter should describe the deliverable in as specific terms as possible and in a clear, succinct manner that can be easily understood and appreciated by all project team members.

High-Level Schedule

Projects, by definition, are time-bound. They are temporary endeavors that exist to generate a deliverable and end once their objectives are fulfilled. As such, there is generally a timeframe driving the project and its allocated resources.

Project stakeholders consider and agree upon a high-level schedule in the initial phases of the project, as they develop the project charter. This allows the project sponsor to consider in advance how the project will fit in with existing business operations, budgetary issues, and so on.

Milestones commonly described in the high-level schedule include:

The project start and end date

Go/no-go decision points

Project planning dates

Project execution dates

Customer feedback dates.

The number and nature of the milestones included in the high-level schedule should be modified to meet specific project needs. Simple, small projects may only require a few dates, while a larger, more complex project may need more. The project charter should not include a detailed schedule for the entire project. A detailed schedule is written later, after the project sponsor has approved the project and stakeholders are ready to begin. The project charter frames only the essential elements of the schedule that are needed to formally approve or disapprove a project.

Constraints

Every project has limitations—or constraints—imposed on it by a variety of sources, including budget, schedule, and resource constraints. Constraints are internal and external factors that limit the project's scope, schedule, or cost and help define project boundaries and determine project feasibility.

Documenting constraints will ensure that the project sponsor and the project team appreciate project boundaries. For example, if early estimates suggest that a project will require 12 months to complete but the project sponsor says that the project must be complete in six months, it may be necessary to reconsider the estimates and the viability of the effort.

Assumptions

Assumptions are statements about the project that are believed to be true and could impact the project's scope, schedule, or cost. The project planning process often involves making assumptions when there is not enough time or information to confirm their veracity.

Assumptions can affect basic understandings of how to deliver the project. If an initial assumption later proves false, all project assumptions and estimates can be thrown into question. For this reason, it is critical to document key project assumptions and to revisit them from time to time, to determine their potential impact on the project and the potential need for re-planning.

Risks

Risks are potential events that could impact the project's scope, schedule, or cost, and they are identified in terms of probability and impact. For example, a project manager might decide a manufacturer has a 50 percent chance of going out of business before it delivers a project's supplies. Another PM might conclude a software developer is only 30 percent likely to successfully code a new software program. These are probability statements. A risk's impact relates directly to how it could potentially affect project scope, schedule, or cost. The following statements expand upon the two previous examples to incorporate the potential impact the risks could have on the project:

A manufacturer has a 50 percent chance of going out of business before it delivers a project's supplies. If the manufacturer goes out of business, the project will incur a 25 percent increase in material costs when it shifts to an alternate manufacturer.

A software developer is only 30 percent likely to successfully code a new software program. If the developer is unsuccessful, the investment made in the developer's time will be lost, and the project will have to restart at an additional cost of $250,000.

If a risk has no potential impact on scope, schedule, or cost, it should not be considered for project planning purposes. For small, simple projects, there is no need to spend a lot of time identifying potential risks. On the other hand, all projects contain some sort of risk, so spending even just a little time considering potential risks is worthwhile.

Team Roles and Responsibilities

The project charter also describes project team roles and responsibilities. As with all forms of business, the predominate portion of a project's costs covers human resources. To successfully estimate a project's potential cost, it is essential to consider the makeup of the project team.

In the early stages of a project, it should be possible to identify all the skill sets required for the project, along with the number of team members needed for each skill set. Good sources of this information are project managers and team members of similar projects or archived project charters from similar projects.

Figure 2-1 Sample Table Describing Project Team Roles and Responsibilities

Beyond the estimated number of team members and skill sets required for the project, it is important to identify team roles and responsibilities. This information helps the project sponsor validate the need for each skill set, and it also allows project team members to appreciate the scope of their responsibilities.

Simple tables easily communicate project team roles and responsibilities in a project charter. Figure 2.1 is an extract from an actual list of project team roles and responsibilities used in a project charter.

Budget

The project budget is a high-level estimate of anticipated project costs. This estimate is essential for the project sponsor, who makes the go/no-go decision for a potential project. It is also essential for the project manager when preparing to move forward with a new project.

For small projects, the budget estimate may be simple and quite straightforward, without needing additional detail.

Medium-sized and large projects require more detailed budget estimates to address those projects’ increased complexity. Also, the investment in the project is greater; those providing the funding for the project may want more detail about how the project budget will be spent.

Scope Statement

The project scope statement is a description of project parameters; i.e., what will be included in and excluded from the project. It is more than the vision and the statement of objectives, although it includes elements of and should trace to the project's vision and objectives.

To return to the previous example of the office-building project, the scope might include a parking lot for up to 50 employee cars. It might exclude covered parking of any kind, but include at least ten compact slots for visitor parking. The scope might also include the parking lot's direct access to a major arterial road, but exclude any modifications to that road, such as dedicated highway on- and off-ramps.

The project scope provides direction for the development of the project's deliverable, and it may also provide guidance about how the project is to be run. For example, a scope statement may mandate the use of an inhouse project manager who is an employee of the sponsoring organization and exclude the use of contract administrative support. It may include a requirement that the project be completed by the end of the coming spring, and it could mandate a budget not to exceed a specific amount.

A well-developed scope statement should be brief and may be in either narrative or outline form. A common approach is to format scope statements as tables listing scope inclusions and exclusions.

It is worth taking the time necessary to clearly delineate the scope of a project, before moving forward with project work. While the other sections of the project charter provide a clear picture of the project's direction and objectives, the scope offers a more view of the project's parameters, its deliverables, and its execution.

Sponsor Approval

One purpose behind the project charter is to provide sufficient information for the project sponsor to make a go/no-go decision to authorize the project and its funding. The goal is to describe the project well enough to enable the project sponsor to make a reasoned decision about whether to invest in the effort.

Imagine you are considering whether to join a group on a week-long hiking trip through some place you have never been to before. Intuitively, you feel like the trip might be a good experience, but it will cost a significant amount of money, and you would like more information before you make a commitment. You would likely want to learn more about:

The destination and its appeal

When the trip will start and end

What you will need to take

Any dangers you might face

How much it will cost

The credentials of the organizer.

Knowing this information could help you reasonably decide whether to sign up for the trip or not.

When deciding whether to move forward with a new project, important information to consider includes:

The project sponsor's vision

Project objectives

The business value the project will deliver to the organization

The project deliverables (e.g., products, services)

Overall schedule estimates

Overall resource estimates (e.g., budget, human resources, materials)

Potential project risks.

An understanding of this information will help you determine whether a project is a wise undertaking.

Once a decision has been made to proceed with a project, the project sponsor should formally approve the project charter and announce the project to the owning organization. Announcing the project validates its importance and is intended to secure the support of other managers in the organization who may be called upon to provide project resources.

SCALING THE PROJECT CHARTER EFFORT

Those who prefer to avoid excessive paperwork and bureaucracy need not balk at the effort required to write a project charter. The charter should simply describe the project and the project team's approach; it does not have to be a lengthy, verbose report. As with all aspects of pragmatic project management, the amount of effort required depends on the characteristics of the project; the goal is to invest minimum effort to achieve maximum gain (Figure 2.2).

Figure 2-2 Planning Scaling Model

There is no minimum page requirement for a project charter. The substance of the document matters, not the number of pages or diagrams. For very small projects, writing a project charter may begin with a simple conversation among project team members over a cup of coffee and scribbles on a napkin. Other times, when more money is at stake and the risks are higher, writing a project charter may require a more deliberate, lengthy process.

The Napkin Approach

Project charters can be long or short. The length of the document and the amount of detail depends on the needs of each project. I once delivered a small IT project using a napkin. My first assignment as a project manager for a consulting company required me to manage an IT project for a small government agency. It was a simple project, with a budget of around $80,000 and a team consisting of just myself and a technical lead. Our goal was to implement a software package that the agency's manager had learned about watching a demonstration at a professional conference. The project's requirements were clear, and the project sponsor's vision of the deliverable was simple and straightforward.

My project teammate and I discussed the project over a cup of coffee. We estimated it would take six months to flesh out our understanding of the project's principle deliverable: a customized software package. I sketched out the objectives for the project and a few milestones on a napkin lying next to my coffee mug, and we were ready to begin.

The project flew by without a hitch, and the customer was pleased with the results—so pleased, in fact, that it expanded the contract to add more features to the new system. As my supervisor prepared to sign the first contract extension, he asked to see the original project charter. He wanted to use that document as a starting point to meet the expanded contract's new requirements.

When I told him that the project charter included little more than hen scratches on a napkin, he raised an eyebrow. Although we delivered the project successfully—the napkin proved sufficient in this case—he expected us to deliver the next project with a bit more sophistication.

Projects of any size generally require something a bit more substantial than a napkin when it comes to documenting the project charter. Nevertheless, the most important thing was that we had developed a clear project charter before we began work on the project, and the charter had sufficient detail to identify project objectives and our approach.

The Expanded Project Charter

Large and complex projects with challenging objectives require a more substantial investment than small projects, which creates a need for additional information in the project charter. Conscientious project sponsors demand more information before making a decision involving greater investments and risk. An expanded project charter offers more information, even as it answers the same questions as a basic charter: What are the benefits, objectives, risks, and costs to the organization? What approach will the project team take? The difference lies in the level of detail.

For example, a small project might have a simple and direct business problem: The IT vendor no longer supports the current software. This places our business at risk, so we must replace the software.

A larger project might have a more complex set of challenges: The IT vendor no longer supports the current software. The business environment has changed substantially. We must update our capabilities, functionality, and customized user interfaces to support our increasingly sophisticated staff and clients. This places our business at risk, so we must replace the software.

In the two examples, the business-problem statements imply significantly different levels of complexity. The need to expand the basic project charter is driven by such differences in complexity, as well as differences in project risk and the particular needs of the sponsoring organization.

Consider once again the example of the project charter crafted on a napkin for the $80,000 IT project. The customer was so excited by the product that it submitted more than fifty change requests over the next year, increasing the value of the project to more than $1 million. Change requests involved adding functionality and remote technology, which increased associated project risk. Rather than a simple, straightforward software package integration project that affected only one organization, the project expanded to impact two major public agencies, several powerful special-interest groups, and dozens of commercial organizations. Each had a vested interest in the outcome of the project, and as the project grew and investments increased, interest in the project piqued even more.

When the project surpassed $100,000 in value, a document clarifying the customer's expectations was needed, especially to gain buy-in from the numerous stakeholders. We set about transferring the information from the napkin to a more formalized document. The expanded project charter elaborated on the project approach in some detail, formalizing project processes like issue management, change control, budget management, configuration management, test management, and others.

Even then, the project charter was fairly brief, but it clarified the customer's expectations and balanced those expectations with our project plans. Most importantly, the customer's senior representative and sponsor officially signed the charter, explicitly agreeing to the project terms written in the document.

An expanded project charter may start as a basic charter during project initiation and evolve into an expanded document over time. Project managers should never hesitate to re-plan or reshape the project charter as needed.

Beyond the contents of the basic charter, the expanded project charter may include requirements, specifications, stakeholder analysis, criteria for success, details about the planned approach (e.g., the project plan, project initiation activities, project planning activities), and several management plans for categories such as:

Scope

Change

Schedule

Cost

Configuration

Issues

Resources

Quality

Communications

Requirements

Risk

Procurement.

Shape the project charter to meet the needs of the project.

PROJECT CHARTER CHECKLIST

EXPANDED PROJECT CHARTER CHECKLIST