The Project Proposal Document will contain some of the information needed for the Project Charter Document. Read Part One - Project Definition, An Introduction, here.

By Colleen Garton and Erika McCulloch

Editor's Note: This article is excerpted from chapter 4 of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch.

The amount of data that you can reuse will depend on how detailed the Project Proposal was. You can use this existing information as a starting point and then work to verify, refine, define, and elaborate on it until you have a complete, detailed, accurate, clear, and concise definition of your project.

The following sections are designed as a practical guide to help you understand and create the Project Charter Document.

Project Name

The official (and unique) name of the project should be documented to differentiate it from other projects. At many companies, there will be multiple projects in progress at the same time and the project name must differentiate it from other projects.

The client will likely have a name for the product that they want built. It is common practice for companies to call their projects by “codenames” instead of using the actual product name for a project. For example, in the case study, the product OFIS could have used a project codename of “Orange” or “Oliver.” This use of codenames for projects is especially important for companies who want to keep the nature of their development efforts confidential until they are ready to release the product.

It also gives the company the opportunity to change the product name without it impacting the project name. It is possible that you may not even be told the actual product name. It may not have a name yet. Regardless of whether you are using the actual product name or are inventing a project codename, you must ensure that the name is unique to the project you are working on. If your company has ten or 100 projects in progress, the project names must be easily distinguishable from each other. As the project manager, you may choose to use a codename for your project instead of the product name. As long as the client is not opposed to it, there is no reason that you should not choose an appropriate codename. Do not choose a name that is facetious or in bad taste. Be respectful at all times.

Client Name

In this section, document the legal name of the client company along with any acronyms or nicknames that are used to refer to the client company. If it is an internal project, the name of the person or department who owns the project should be documented here. In this section, you should also document the names, titles, and contact information for each employee of the client company or department who will be involved in the project in any way. This will include the name of their administrative assistant, legal reviewer, accountant, and so on as well as the actual project team members.

Decision Makers & Steering Committee

It is critical that the project decision makers be identified and documented and that those decision makers are aware of their responsibilities. These are the decision makers on the client team and the vendor teams as well as those on the

development team. Having this information well defined and documented will prevent the project from grinding to a halt if a roadblock is encountered. In my experience, the lack of clearly defined decision makers is a common cause for projects being left in limbo for some period of time when there is a problem. Everyone has to stop while the project manager is trying to figure out who has the authority to make the decision that will enable the project to move forward. This kind of situation can impact both the scheduled delivery dates and team morale.

To complete this section, you will need to identify the decision makers at each level and for all aspects of the project. You must document what kinds of decisions each person is responsible for and the contact information for each person. You may not have identified exactly who the team members are going to be yet, so this list will consist of names and titles for some decision makers and just titles for others.

The blanks will be filled in when the Project Plan is created after the project has been approved. For those decision makers that are defined as a specific person, make sure that you have the work, mobile, and/or home phone numbers. If it is not appropriate to put personal numbers in this document (due to wide distribution), keep these numbers on a separate list and ensure that all the managers involved in the project have access to it. If more than one decision maker is needed for some decisions, make it clear which one is the primary decision maker. This will be the person who will take responsibility for making the final decision and is responsible for coordinating and communicating the decision to the project team. In the example shown in Figure 4.2, the name of the primary decision maker is bolded.

The more kinds of decisions you can identify in this section of the Project Charter, the more quickly decisions will get made and the more smoothly the project will run. If everyone on the team knows who is authorized to make decisions about what, it avoids misunderstandings and confusion when direction is coming from more than one direction. It will be clear that decisions about a specific part of the project are valid only if they come from the person designated as the primary decision maker.

If your project has a steering committee or project board, you should document the information for that group here, too. Include the names of the group members, which decisions must be made or approved by the group, and the person who will act as the primary point of contact for the group. The primary steering committee contact for the project manager is usually the project sponsor.

Figure 4.2: Decision Makers

Project Stakeholders

The project stakeholders include everybody that has any involvement or interest in your project. This includes, but is not limited to:

• Client
• Sponsor
• Project team
• Quality assurance
• Product and business management
• Executive management
• Marketing and advertising
• Social media marketing
• Vendors/suppliers
• Consultants and contractors
• Internal or external departments or groups
  • Finance and accounting
  • Legal
  • Focus groups
  • User interface designers
  • Usability
  • PMO
  • Internal IT groups
• End users

Project Description and Goals

The project description describes the project in terms that are understandable to everyone on the project team. Avoid the use of technical or industry-specific terms whenever possible. Keep the description simple, accurate, and unambiguous. For example:

“The goal of the OFIS (Order Fulfillment and Inventory System) project is to port ABC’s existing, internal enterprise order management software system to the Internet.”

The project goals are what the project must achieve at a high level. These are not the same as the objectives. Goals are high level and are not measurable (broad focus). Objectives are precise, detailed, and measurable (narrow focus).

How to Determine the Goals

To determine the goals of the project, you should ask the client the following questions:

• What would you like to achieve?
• Why would you like to achieve it?

Here are some examples of what you might learn:

• We would like to move our company to the Internet sometime in the next year.
• We want to improve our call center operations.
• We want to offer our retailers more ways to contact and connect with us.

Business Case

As the project manager, it is unlikely that you will be required to define the business case unless you are the person proposing the project. The initial business case will have been presented as part of the concept or proposal for the project. Now that the project has been more clearly defined, the business case should be updated and expanded to include more detail. The business case is the justification for the project. As your project progresses, you will need to ensure that any proposed changes to your project align with the business case. If they do not, either the business case needs to be updated or the proposed changes should be denied.

The business case typically includes some historical data about the company which defines how, and why, things have been done in the past, together with data showing current trends and/or changes in the marketplace or organization that make the project necessary. The detail and complexity required for the business case will be directly proportional to the size of the proposed project. At the very least, it needs to include a high-level and compelling overview of why the business needs to move in the specific direction that the project proposes. This will often include aligning the project with a key strategic business goal.

How to Determine the Business Case

To determine the business case for the project, you first need to understand the goals of the project.

Using the example goals defined earlier:

• We would like to move our company to the Internet sometime in the next year.
• We want to improve our call center operations.
• We want to offer our retailers more ways to contact and connect with us.

Ask your client these questions:

• Why are these goals essential to your company?
• How will they change the way you do business?
• How will they benefit your company financially?

Here is an example of the kind of information you are trying to extract from your client:

• Over the past seven years, the company has grown from having a relatively small retailer customer base in a few states to a distribution network of over 2,000 retailers in fifty states. We are in the process of securing wholesale distribution contracts with a number of international businesses. Our call center has grown significantly over the past few years. Due to the multiple time zones we are servicing, the call center needs to be operational for approximately twelve hours per day. Our overhead is out of control, and we need to reduce costs.
• By integrating the current order management system with the inventory system and moving it to the Internet, the company could offer access to retailers to place orders, get status on current orders, get quotes, view the current catalogue, and check available inventory 24/7.
• We believe we can reduce costs by 60 percent in the call center, by 20 percent in the sales department, and by 60 percent in marketing.

Key Business Requirements

The client will have precise requirements regarding what and how the project is to be implemented. This section should document each and every requirement that the client has in respect to this particular project. For example, they may require that the coding is done in a specific programming language or that the product is designed to run on a particular hardware platform. Other examples could be that some existing systems must be used in the solution or that the project must be completed

before a specific date even if that means reducing the project scope to meet that date. In addition, there may be requirements that relate to specific processes and procedures or security concerns. The client may have identified some, or all, of these in the RFP. It is your responsibility to work with the client to ensure that this information is complete and accurate so there are no surprises later on. You don’t want to implement and test a product with an Oracle®database (because you know the client uses one) and then find out that the client will be using this product with their proprietary database and not with the Oracle database that they use for accounting.

Ensure that you capture the low-level as well as the high-level requirements. The more you know about what the client specifically wants and specifically does not want, the better positioned you are to deliver a quality product with high value to the client. Anything that is critical to the business needs of the client should be documented clearly and concisely in this section.

How to Determine the Key Business Requirements

To get insight into key business requirements, ask the client these questions:

• How many users do you need to support?
• What technology/processes cannot be changed?
• What technology/processes must be changed?

Using the previous examples, here are some suggestions on what you might hear:

• Ability to significantly increase distribution network without increasing headcount
• System must be implemented to support 4,000 retailers and have the scalability to support 8,000 retailers
• Seamless integration—order management, back orders, inventory, and account information must be seamlessly integrated
• Call center screen must have ability to show all account and order information on one screen
• Existing Oracle database must be used for back end
• Retailer account numbers must not change
• Product numbers must not change

• System must integrate with the billing/accounting system
• Warehouse system must support bar codes
• Processes need to be created and documented for sales, warehouse, and shipping
• Functional training for sales, warehouse, shipping, and accounting
• Technical training for on-site webmaster, systems admin, and database administrator

Next time: Part 2 of Creating a Charter Document.

Want to learn more about project management best practices now?  Pick up your own copy of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch - available and on sale at the MC Press Bookstore today!

Colleen Garton is a highly respected and experienced writer, consultant, and speaker. She is the author of two management books: Fundamentals of Technology Project Management and Managing Without Walls. Recognized internationally as an expert on virtual and global management, Colleen is an experienced and in-demand public speaker for numerous events and conferences around the world. She is also author of the blog Working With or Without Walls.

 Colleen has extensive management and training experience in the United States and internationally, with more than two decades of practical experience in traditional and virtual management spanning multiple industries. She is the owner of the Garton Consulting Group. Before founding the Garton Consulting Group, Ms. Garton held senior management positions at some major U.S. corporations.

You can follow Colleen on Twitter at @ColleenGarton and on Facebook.

---

MC Press books written by Colleen Garton available now on the MC Press Bookstore.

		Fundamentals of Technology Project Management Master the specific project management issues that technology professionals must face. List Price $69.95 Now On Sale
		Managing Without Walls Optimize the effectiveness of your teams...no matter where they are. List Price $37.95 Now On Sale