How often have you been involved in a project where the customer and the project team didn't seem to share the same understanding of the project definition? Frequently, what the project manager sees as newly revealed requirements tend to be viewed by the customer as requirements that should have been obvious from the beginning. In this article, which is a brief excerpt from The Project Success Method, a Wiley book, author Clinton M. Padgett explains the first task of a new project team: development of a written charter that clearly defines project scope and other key project requirements...

Bonus! Listen to a 15-minute MPUG podcast featuring author Clinton Padgett here. Just choose to save the MP3 file to your hard drive and tune in with Windows Media Player. Padgett explains why so many projects fail, shares the steps for the project success method, lays out why he believes time is more important than cost or quality, provides a technique for establishing a project's critical path, and offers a method for implementing the practices described in the book.

The first and most obvious purpose of a project charter is that it ensures that all the project stakeholders formally agree on the project definition and have recorded that definition in writing. The charter protects the project team against uncontrolled scope creep and the other disasters awaiting project teams that begin their work with only a vague or assumed understanding of the project scope and other requirements.

As a project manager, you want to involve all project stakeholders directly in creating the project charter. Ideally, the customer will participate directly in developing the project charter. Whether the customer participates directly or not, you as a project manager are well advised to ask the customer and all other project stakeholders to sign the charter to show their personal acceptance and commitment to the project definition.

In other words, if the customer won't participate with the team in defining the project, then the team should define the project and put the responsibility on the customer to either accept their definition or revise it. If the customer decides later to expand project scope or modify other requirements, then the project team and the customer must go through a formal charter revision process, during which all project requirements and constraints are open to discussion, renegotiation, and possible modification.

Project managers and teams in the construction industry learned the importance of this lesson centuries ago. The signed agreement between the customer and the contractor clearly defines project scope based on plans and specifications. If the customer asks for an additional feature, the contractor and customer must negotiate the added fee for the increase in project scope as well as other revisions to the agreement, such as changes to the project's scheduled completion date. In effect, a “change order” on a construction project is a revision to the project charter.

In other types of projects, however, project teams too often fail to follow this prudent discipline. This failure is especially common when the project customer is within the same organization as the project team. Keep in mind that any conversation about project scope and other requirements—no matter how comprehensive and concise it may seem to you—is no substitute for a written document that is signed by the stakeholders.

Another advantage of involving the project customer in the chartering process is that it usually gets the project started earlier and gives the team the maximum amount of time to get the project done. I have seen many cases where everyone in an organization knows that there is a major project to be done, and maybe they have a year to get it done. But senior management consumes the first six months procrastinating and dithering on specifying the project scope and other requirements. The chartering process forces the customer to grapple with the issues associated with the project definition and to make the necessary decisions, so that the project team can get started with its work.

The project charter has two other important purposes, as well. First, the process of developing the charter is as important as the document itself. The charter development process is an excellent opportunity—coming as it does at the earliest stage of a project—to involve the new team in teamwork, which leads to the development of a real team as I described in Chapter 4. And because of their direct involvement in the chartering process, the team members begin to take ownership of the project; that is, they begin to think of the project as our project, rather than as someone else's project that I would like to have as little involvement in as possible. So the chartering process helps to build a real team and to build commitment to the project.

There's often a strong temptation to have one person draft the charter for review by all stakeholders. However, this “straw-man” approach short-circuits the teamwork and commitment-building value of the chartering process. A far better approach is to have the stakeholders start with a nearly blank sheet of paper and develop the charter together. This approach virtually always leads to a better charter. All stakeholders are actively involved and their views are represented. The process highlights contentious issues and enables stakeholders to tackle and resolve them at the most advantageous time in the process; that is, at the very beginning.

Second, the project charter serves as an efficient and consistent means of communicating the project definition to people who were not involved in the charter development deliberations, such as people who join the project team later, contractors and other resources who will work on the project, or managers of the functional departments from which the team members are drawn.

Because the project charter is such an important communications device, you should ensure that it:

• Is concise. My basic rule is that the charter should never exceed three pages, plus attachments, and would ideally be two pages or less.
• Avoids using technical jargon and undefined acronyms that may not be understood by some readers.
• Is written as a management document rather than a technical specifications document.

Reprinted by permission of the publisher, John Wiley & Sons, Inc., from The Project Success Method: A Proven Approach for Achieving Superior Project Performance in as Little as 5 Days, by Clinton M. Padgett. Copyright (c) 2009 by Clinton M. Padgett.

To order a copy of The Project Success Method, visit Wiley or your favorite bookseller.

Clinton M. Padgett is President and CEO of Project Success, Inc. (PSI), a consultancy focused on helping clients develop excellence in project management. For over 15 years, he has provided consulting and training to clients in a wide range of industries. Contact him at Clint.Padgett@projectsuccess.com.