Begin the charter with a brief description that concisely summarizes the intent and motivation for the project. This section could describe the problem that stimulated the project or the business opportunity that the project is intended to create or exploit. There might be a final project deliverable or goal that will set the stage for the rest of the charter. You could include a summary of the business case that explains why the organization wants to undertake the project.

Information about the project can be presented at a fairly high level at this stage. Keep the description brief, including supporting information in the form of an appendix or cross-references to other sources. Subsequent planning activities will elaborate this preliminary information into further detail. The initial objective of the charter is to acquire approval and funding for the project. Keep this goal in mind as you decide how much information to include.

As Chapter 4 discussed, defining your project’s business objectives, goals, and success criteria is a fundamental aspect of project initiation. Describing the business objectives helps all participants understand why the project exists and why it is significant. People who understand the importance of what they’re working on are more motivated than those who don’t know the compelling reasons behind the project. Business objectives and goals often are found in the following categories:

It’s important that the business objectives be measurable so that the organization can determine whether these objectives have been achieved. The project’s business objectives should align with achieving the organization’s strategic goals. Watch out for conflicting objectives, such that successfully achieving one objective interferes with achieving another.

Chapter 4 also described the process of defining project success criteria. Various stakeholders could have different business objectives and hence different success criteria. Alignment between the success criteria and business objectives is essential to focus the project team’s efforts.

Stakeholders are individuals, groups, or organizations who are actively involved in a project, are affected by its outcome, or can influence its outcome. The critical stakeholders include the project sponsor or funding authority, the project manager, key customers for this product, specific user classes, anyone else with oversight responsibility for the project, and perhaps others. It’s good to note the project manager’s level or scope of authority. See Chapter 4 for more information about developing stakeholder profiles. You might also include a table that lists affected business areas and organizations and that describes the impact the project will have on them.

The project sponsor is the most important stakeholder during project initiation. The sponsor is responsible for securing resources, approving scope changes, establishing policies, and providing approval at defined checkpoints for the project to proceed to the next phase—or not. The project sponsor will also help remove barriers to project success when necessary. To that end, the project sponsor must have the authority to fix problems and make things happen.

It’s also an excellent idea to identify who the key decision makers will be for this project. Conflicts will arise, issues must be resolved, choices must be made, and scope increases will be proposed. Identify the core group of people who will make these decisions. Any group who makes decisions should select their decision rule, the mechanism by which they will make those decisions, preferably before they confront their first major decision (Gottesdiener 2001).

Some organizations include a roles and responsibilities table or a project organization chart in this section of the charter. Such a chart would show the relationships between the project sponsor, project manager, a steering or advisory team, team members, other stakeholders, and perhaps other projects. This is appropriate if you have identified essential project roles and perhaps some of the individuals who will be filling those roles. However, that information might not be available until after the charter is approved and the team structure established.

The charter is a good place to describe how you anticipate the team’s composition might change during the course of the project. A small core team involving a project manager, product manager, and technical lead might take the project to its first approval gate. You would then establish a larger cross-functional team with the responsibility to define, design, implement, validate, verify, and deploy the product. Once deployed, a smaller group could attend to the product while it is in customer use.

When I began writing books, I learned about the "elevator story." You’re chatting with some random person in an elevator and you just happen to mention that you’re writing a book. "Cool," Fellow Rider replies. "What’s it about?" You have perhaps 30 seconds to summarize your book and convince Fellow Rider that it’s fascinating and he should buy many copies for his friends and family. Similarly, if someone asks "What is this project about?" you should have an elevator-story description available. A vision statement is one way to communicate concisely the intended outcome and benefits of your project.

This section of the project charter establishes a strategic vision for the product that the project will deliver to address the business objectives. You might prefer to store this information in a separate vision and scope document (Wiegers 2003). This vision statement will provide the context for making decisions throughout the course of the project. The vision should not include detailed requirements or project planning information. Nor should it attempt to describe every product characteristic or every benefit the project will provide to every stakeholder. Geoffrey Moore (1991) proposed the following effective keyword template for creating a vision statement:

For (target customer)

Who (statement of the need or opportunity)

The (product name)

Is a (product category)

That (key benefit, compelling reason to buy or use)

Unlike (primary competitive alternatives, current system, or current business process)

Our product (statement of primary differentiation and advantages of new product or service)

Here’s an example of a simple vision statement. Several years ago I began developing eLearning versions of many of my training seminars, beginning with a seminar called "In Search of Excellent Requirements." I wrote a vision statement and some requirements when I launched this project, just to make sure I had a clear idea in my own mind as to where I was headed. Following is that vision statement, with the keywords from the template highlighted in bold:

Software people talk a lot about scope and scope creep. The project scope describes an agreement between the project team and the customers as to what is included in the project and what is not. That scope boundary between what’s in and what’s out is critical. It provides a reference frame against which proposed feature and requirement changes can be evaluated. Clarifying the project’s scope and limitations helps to establish realistic expectations of the many stakeholders. Proposed requirements that are out of scope for the envisioned product must be rejected, unless they’re so beneficial that the scope should be expanded to accommodate them (with accompanying changes in resources and/or schedule).

Products evolve over time on their journey to full realization of the product vision. A particular project therefore might address just the next release of the product. That is, the scope for a given project could represent a defined subset of the vision. Defining those scope boundaries helps the project manager keep the project focused on its objective. Otherwise it can grow out of control as more and more of the ultimate vision gets crammed into the current project.

There are various, complementary ways to represent project scope. One useful technique is the context diagram, which shows the entire system or product to be developed inside a circle. (See Figure 7-2.) That circle represents the system boundary. Outside the circle are boxes that represent various external entities that interface with the system in some way. These interfaces are depicted with labeled arrows. This scope depiction technique shows the interfaces between the system and objects outside it, but it doesn’t explicitly itemize what the system will and won’t do. A second way to represent project scope is by creating a list of essential external events that can take place to which the system must respond in some predictable way. In addition, describe limitations and exclusions, such as product features or characteristics that a stakeholder might anticipate, but which are not planned to be included in the project. See my book More About Software Requirements for detailed descriptions of these and other scope-representation techniques (Wiegers 2006).

Figure 7-2. The context diagram (with annotations).

An assumption is a statement that is treated as being true without definitive knowledge that it is true. The charter should identify any assumptions that were made while conceiving the project. Known facts are not assumptions. I once read a requirements specification for a system to handle Web site domain name registrations. It stated the following assumption: "A new Unique Domain Authentication Identifier cannot be requested for a domain name that is pending release." This is not an assumption but rather a statement of fact, most likely a business rule that imposes this constraint.

There’s a good chance that one stakeholder’s assumptions will be different from another’s. Incorrect and conflicting assumptions pose a risk to the project. Assumptions will need further evaluation and validation during later project phases. Give each assumption a unique identifier (not just a bullet symbol) so that people can refer to it during discussions and in other documents. These labels also enable you to keep a record of changes made to the project charter.

A dependency arises whenever a project must rely on some external factor for success. Sources of dependencies include standards bodies, other projects, suppliers and subcontractors, technologies, and business partners. Broken dependencies are a common cause of project unpleasantness. As with assumptions, give each dependency a unique identifier so that it can be referred to and tracked. Besides these external dependencies, internal dependencies between project tasks and project participants will become evident during project planning. Those are better recorded in the project management plan, rather than in the project charter. Dependencies also can lead to risks that the project must mitigate and monitor.

A constraint is a factor that limits the choices available to the project manager or team. The project manager must know about constraints so he can make appropriate trade-off decisions to cope with changes in product features, quality objectives, staff available, schedule, and budget (Wiegers 1996). See Chapter 4 for more information about assessing the relative priority of these five project dimensions and the latitude each provides to the project manager. Other known project constraints could include products to be reused, components to be acquired, interfaces to other projects or products, or technologies to be employed.

Include a list of major project milestones and key deliverables. These milestones form the skeleton of the detailed project schedule developed later during planning. It’s not essential to include the target date for each milestone unless they are fixed constraints. Non-constrained target dates should be plausible estimates, not ideal fantasy dates. Showing a date range for a milestone at this early stage is more realistic than stating a specific day. As Chapter 11, discusses, estimates made based on limited knowledge and analysis early in the project have considerable uncertainty. Overly precise estimates convey an impression of accuracy that simply isn’t justified. Management and customers should resist the temptation to view these very preliminary milestone dates as firm commitments. The project management plan will contain a more detailed list of milestones, estimated dates, and deliverables, so identify only the most significant project events here.

Note

Preliminary milestone dates that lodge in management’s memory and are used to hold the project team accountable even though everything else about the project has changed months later. A management goal is not an estimate.

Summarize the major business risks associated with this project. Risks could relate to marketplace competition, timing issues, user acceptance, implementation issues, or possible negative impacts on the business. Estimate the severity of each risk and identify any risk mitigation actions to consider. The charter is not the place to include a detailed list of all potential project risks. Instead, focus on the business risks associated with either undertaking or not undertaking the project. See Chapter 6, for more information about risk management.

By the act of approving a charter, senior management is agreeing to commit specific resources to the project. Human resources (or as they are sometimes called, "people") might include a project manager who is assigned during project initiation. Other human resources could encompass specific key individuals, teams, organizations, subcontractors or suppliers, and support functions. Describe any critical skill sets that team members must have. If you know the names of specific key contact individuals for the project, such as someone in the Human Resources department who will assist with project staffing, include them in the charter. Non-human resources include funding (include a preliminary budget summary here), computers, physical facilities such as buildings and rooms, hardware devices, software tools, other equipment, and training. Not all of these might be known at the time the charter is written.

If the team composition and project organization are known at the time of chartering, you can include that in the charter, perhaps in the form of an organizational chart. You likely won’t know the names of individuals because staff won’t be assigned until the charter is approved and the project launched. However, you might have preliminary knowledge of the necessary team roles, use of multiple development locations, or use of subcontractors. In some cases, that information will not be defined until later and should be stored in the project management plan rather than in the project charter.