Project Charter

The result of the Initiation planning process is the project charter . This document provides formal approval for the project to begin and authorizes the project manager to apply resources to the project. This is a major milestone, as the charter is the first official document of your approved project. All that hard work in the Initiation process has finally paid off.

The person or group approving the project issues the project charter. If your organization has a formal project selection committee, it may define who issues the project charter. This is typically someone in upper management, but this will vary between companies or departments. It may or may not be the project sponsor.

The charter is the project blueprint; similar to the blueprint you develop if you build a new home. The finished product will look a whole lot different, but at least you now have a map to help you get started.

Organizational standards drive the specific format of a project charter and the information it contains. As a project manager, you always want to determine if there is a template or required format to follow. At a minimum, your charter should contain a description of the project, the business need that created the project, and formal approval for the project to begin. If your project was involved in a formal selection process, you will have more data and can develop a project charter that contains the project description, project team information, goals and objectives, high-level business case, and formal approval.

Let's discuss the components of a charter in more detail.

Real-World Scenario: IT Project Descriptions

An IT project description needs to be a quick-read paragraph that encapsulates and describes in a few sentences what the project's product will do. It documents the key characteristics of the product or service that you're going to create as well as the work required to deliver the project.

The following are some examples of IT project descriptions:

 

• IT will create a set of computer programs and databases that will allow the vehicle service department to track all warranty work performed on any given vehicle. The system will be intranet-based and accessible via browser from any computer in the environment. The database will contain fields to house all relevant pieces of information for warranty work performed by the department. Reports will be generated that can be electronically shipped to the vehicle manufacturer for reimbursement. Drop- downs using lookup tables will be provided on the user interface wherever possible to minimize data entry time and incorrect data entry. Consistency checking will be performed on key fields that require doublechecking of the data (such as VIN).

• IT will assemble a bar-code system so that two assembly-line employees can scan all parts coming off of the line and enter them into a database tracking system. The system will consist of two PCs connected to the network and the company's ERP system. The assemblyline technicians will affix a bar code to the item, scan it, then key in pertinent data relative to the item. The data will be subsequently posted to the ERP's equipment inventory catalog for use by parts persons in the field.

Project Description

The project description documents the key characteristics of the product or service that will be created by the project and the work required to deliver the product. The description in the charter will be high level and more detail will be added when you develop the project scope statement, which is discussed in Chapter 3. The project description documents the relationship between the product being created and the business need that drove the project to be requested . This description needs to contain enough detail to be the foundation for the scope planning process that will be the next step.

Project Team

The project charter should formally identify the project manager and his or her authority. Detailing the project manager's authority in writing early on will prevent misunderstandings or issues down the road. Authority areas to document include personnel management and budget authority.

• Does the project manager have hiring and firing authority over team members ?

• Does the project manager have input into the appraisals or salary reviews of team members?

• Is the project manager authorized to spend the project budget?

• Are there any limits on the dollar amount that can be spent without sponsor or other executive approval?

All known project team members can be listed. A charter does not normally list project team members by name , but lists the category of resources required. Job titles such as Business Analyst, Systems Analyst, Programmer, and Tester can be listed. Charters for cross-functional projects should also list known team members from other departments such as a Product Manager, Marketing Communications Manager, Training Developer, or Contract Specialist.

Goals and Objectives

The charter documents the high-level goals and objectives of the project. The project charter is the first communications document to explain what the project is all about.

A charter needs to include a clear statement as to what end result the project will produce and how success will be measured. Goals and objectives must be clear and stated in such a manner that the end result can be measured against the objective. Instead of stating , 'Install a fast customer record retrieval system,' a goal should state a measurable outcome like 'Retrieve customer records in an average of 5 seconds.'

Working with the client to document quantifiable and measurable goals is key to the project success. It puts the client, the sponsor, key stakeholders, the project manager, and team members on the same page. Fuzzy objectives with no measurement create vastly different perspectives as to what constitutes project success.

Business Case

Approval of the project charter also marks the initial approval for project funding. The amount of funding initially approved for the project is linked to the business case. A business case formally documents components of the project assessment generated by the project selection process. It includes a description of the analysis method and the results.

A business case is typically a stand-alone document that is initially created at a very high level with multiple iterations over the course of the project. Details to the business case are added at various points in the project planning process. Many organizations have business case templates, with some of the sections completed at the time of project selection.

A business case summary in the project charter may include high-level costs, benefits, and payback period estimates.

• Costs All costs estimated at the time of project approval should be listed. These costs include estimates for materials, equipment, and human resources. The estimates in a project charter are very high-level estimates based on costs of similar projects or estimates from experts familiar with the type of work involved.

  In a typical IT project, there are both capital and expense costs. Capital costs would include the purchase of new equipment such as servers or workstations. Expense costs include items like salaries, travel, and training.

• Benefits A key benefit is revenue. Revenue is the cash flow generated by providing a billable good or service to an external customer. Not all projects generate revenue, but for those projects that will be sold to external customers, this is a critical component. The early revenue estimates are provided by the marketing organization based on a target price and a forecast of sales.

  Revenue is a benefit that can be quantified and measured. A new product may be projected to bring in $2M in revenue during the first year of product launch.

  Other benefits, such as increased customer satisfaction, may be more difficult to quantify. Benefits that cannot be easily quantified in dollars are sometimes referred to as soft benefits.

• Payback period The payback period identifies when the project will pay for itself. For a revenue-generating project, this can be a timeline of the project costs compared to project revenue.

There can also be a payback period on a project that does not generate revenue. A new call handling system with menu options may drive efficiencies in a call center operation that will allow the center to grow without adding additional staff. This cost avoidance figure can be used to calculate when the system will pay for itself.

Formal Approval

The project charter should be signed by the executive with the authority to move the process forward. This person could be the project sponsor, the project client, or a representative of the project selection committee. The key is making sure the person signing the charter is at the appropriate level within the company to authorize the project.

This sign-off provides the project manager with the authority to move forward with the work required to complete the project. This approval may be required prior to the release of purchase orders or the formal commitment of functional managers to provide resources to support the project.

Issuing the project charter moves the project from the initiation phase into the planning phase. Regardless of who actually signs the project charter, now is the time to make sure you have buy-in from your stakeholder group. All of the stakeholders need to receive a copy of the charter. It is also a good idea to schedule a meeting to review the charter, review next steps, and answer any questions or concerns. To eliminate any future disagreements regarding the outcome of the meeting, all key points and any decisions made should be documented in a memo sent to all the stakeholders. Issues that are dealt with as soon as they surface are easier to resolve. Ignoring concerns or not keeping stakeholders in the loop can create escalations to higher management and start your project off on the wrong foot . The support of management is critical and the best way to maintain this support is through ongoing communications. Maintaining consensus among stakeholders is a key part of the project manager's responsibility throughout the life cycle of the project.

IT Chain of Command

When considering the overall project, especially in context of the charter and the associated names of people in that charter who are able to authorize the resources necessary to enact the project, it will be beneficial for you to understand who's in the IT chain of command so that you know who is capable of doling out this authorization. While most IT shops are somewhat smallish (i.e., just a few members in each specialty group-servers, programming, etc.) these groups can be broken out among various managers who each have their own budget, and who can call the shots for the employees under them. For example, your project might call for a telephony person, who reports to the telecommunications department, of which there are four or five employees and who have a manager over them who is responsible for their day-to-day operations. This person is one who must appear on the charter because he has the ability to authorize the use of the resources you require. Ditto for programmers, who probably come from a different group, with a different manager. You can't schedule a telecommunications person using the authorization of the programming manager because she doesn't manage the telecom folks! So it's prudent to understand the chain of command that's involved with any given technological project.

The IT chain of command can vary widely depending on the size and spread of the organization you're working for. Generally speaking, however, there will always be a supervisor or manager of the software development, network operations, server administration, telephony, security, Internet/intranet, architecture, and database teams .

Typically, these supervisors/managers report to a director-level individual or perhaps even the chief technology officer (CTO) or chief information officer (CIO) (the so-called C- band executives) of the company. This, of course, depends on the company's size. See Figure 2.1 for an example of the IT reporting hierarchy.

FIGURE 2.1 The IT reporting hierarchy

In Figure 2.1 you'll see a department called the project management office (PMO). Some (not all) enterprises have realized that many endeavors benefit from a professional project manager overseeing the project-whether the project is technical in nature or not. So the idea of a PMO was formed -a centralized location for all project managers, staffed and managed by project professionals, and capable of taking on any project in the organization.

The Frustrations of Hierarchy

Because the charter speaks to the types of people who will be required to complete the project (note that we may not necessarily know the names of the people at this point in time, but we do know that we need a certain class of individual) understanding the chain of command makes your job easier when it comes to understanding who's got to sign off on who's joining the project. You can't, for example, stipulate that you need a programmer but not list the head of the programming department as one of the persons who must authorize the usage of his or her resources.

Here's the problem with a chain-of-command hierarchy in a standard IT shop: The director of applications development's goals may not be the same as the director of operations. Your job as a member of the project management office (PMO) is to try to get these two on the same page with respect to your project-to see that the outcome of this project is of paramount importance and that the two must agree on this. But that's not always the case. So you wind up doing a lot of resource allocation planning, working with the leaders of each unit in order to come up with convenient windows of time when the people you need are going to be available. You don't usually have the luxury of a manager telling you 'You can have my best programmer for as long as you need him or her!'

Another similar, only worse , problem arises when the directors of these various units don't report to the same individual, as shown in Figure 2.2.

FIGURE 2.2 Business units not associated with the IT hierarchy

Now you've got an issue where you not only need to coordinate resources across various managers but also across executive leaders. While the executive might say 'Sure, you can use so-and-so!' the manager may not be so wild about the idea. Or vice versa.

Still more confusing is the hierarchy in which the business unit has some IT staff and you also have some IT folks who are going to work on the project. This is similar to the CIO/CTO model shown in Figure 2.2 except that the business unit's objectives may be quite different than the objectives of executives who are committed to IT. You may well find that you get an initial commitment from the business unit director to use a staff IT person, but that permission is yanked back at the last minute due to other pressing issues. Or you might find that your assigned staff person is a yo-yo, being pulled constantly off of the project in order to put out business unit IT fires.

Unfortunately, there is no really good way to manage such complicated scheduling issues, apart from doing your best to anticipate problems up front and then planning into your project enough leeway to handle such issues. Business unit leaders need to understand that a commitment to an important IT project means that the staff you need are available to you at the time you need them and they cannot be used for other work!

Case Study: Chaptal Wineries Email and Intranet Systems

This case study will follow you through the remainder of the book. It's designed to be complicated enough to require the use of all of the project management components we talk about, using information from each chapter you read.

You work for a mid- sized winery-Chaptal (named for the process of adding sugar to wine to increase its alcohol level-chaptalization)-in the Sonoma county region of California.

Business has been very, very good! Wine is hot, hot, hot all over the country and your wine maker, Rachel Ranee, has gained in stature and favor throughout the major wine circles.

The owner of the winery, Kim Cox, has decided to set up shop in other interesting parts of the world: Chile, southeastern Australia, and western France. She has established strong partnerships in these areas and is now ready to connect the three sites together into one network so that she can keep track of the daily activities of each new winery. The prospective new wineries are as follows :

France LaCroix is in the Bordeaux region of France. Chaptal's partner is Guillaume Fourche, a long-time Bordeaux negociant , one who buys wine from the various smaller wine merchants to blend into interesting cuvees that are then bottled and sold. Kim wants to set up an international distributorship with this man, utilizing Rachel's wine-making skills to seriously kick up the quality of the wines that LaCroix distributes.

Chile Metor Sanchez in the Aconcagua Valley has been making wonderful Chilean red wines for several years now. Metor Sanchez is interested in branching out internationally and understands that a partnership such as one through Chaptal would be beneficial for both wineries.

Southeastern Australia In Adelaide, Australia, a new renegade winery has sprung up. Roo Wines, headed up by a young new upstart wine maker, Jason Jay, holds Kim in a spell with the luscious dark Shiraz wines that they release.

Kim has entered into financial agreements and working partnerships that allow her to own a stake in each of the wine company's output, while allowing them to retain their original look and feel. The people who work for each entity will ultimately report to Kim, but each endeavor is free to continue doing what it does best. Kim has committed to not creatively interfere.

As the head of IT for Chaptal, you've been with the winery since it had one little fileserver on which Kim kept the spreadsheets for the various accounts and Rachel kept track of the residual sugar readings of the grapes.

Today Kim has told you that she wants you to install an email server in each of the other three locations, connecting them so that everyone can quickly communicate with one another. She also wants an intranet site set up so that the new wine releases can be easily pre-released to all sites for comment and approval.

Having just recently passed the CompTIA Project+ test, you understand that there are some basic elements you need to capture in this first meeting:

Basic Requirements You have two requirements that you must fulfill:

1. Set up an email system between the four sites.

2. Set up an intranet.

Stakeholders Clearly, Kim is the project sponsor, but who will be the stakeholders? In addition to Kim there are three primary stakeholders:

1. Guillaume Fourche

2. Metor Sanchez

3. Jason Jay

But in addition to this list, various staff members will benefit from the new changes. Also, the support entities that assist in the production of the various wines will be stakeholders as well.