Initiating the Project

Overview

You've determined that your new work assignment is a project according to the criteria detailed in Chapter 1, "Building the Foundation." You've dusted off your communication and organizational skills and bought yourself a cool new organizer tool. You're set to go. Now what?

Your next stop is the Initiation process. This is the first life-cycle process in any project. This is where you determine whether the project is worth doing, select which projects should be worked on and in what order, and publish the project charter.

This chapter will cover all the aspects of a project's Initiation phase. In this chapter, you will learn about:

• Selecting projects and assigning priorities
• Sponsoring a project
• Determining stakeholder roles and responsibilities
• Creating the project charter
• Holding the project kickoff meeting

Selecting Projects for Success

Project Initiation is the first process in the life of a project. We've already addressed the initial question, "Is it a project?" So this phase serves as the official project kickoff.

The project Initiation phase acknowledges that the project should begin or that the next phase of a project already in progress should begin. For example, prior to the handoff from the Planning phase to the Executing phase, the Initiation phase is revisited to determine whether the handoff should occur.

Initiation phase

The first phase in the project life cycle, where project requests are generated and approved or denied. The project charter is produced in this phase, the project manager is appointed, and the organization recognizes that the project should begin.

There aren't any formal rules for project Initiation other than the publication of the project charter, which we'll cover in a later section of this chapter. Generally what occurs during this process is that a project is proposed due to a need or demand. A selection committee, or perhaps the senior director or manager, reviews the project request and its accompanying details and then makes a decision whether to undertake the project. Following a "go" decision, the project charter is created and approved, resources are committed, and a project manager is assigned.

The following graphic illustrates how the Initiation process works. Needs or demands create requests for projects, and that in turn kicks off the Initiation phase of the project. The output of this phase is the project charter. The project charter then becomes an input into the Planning process, which is the next phase in the project life cycle.

How Projects Come About

The VP of Sales strolls into your boss's office one day and asks for a little assistance. Ms. VP is interested in purchasing a system that will help her staff profile potential customers. The sales department has satellite offices over a six-state region, and each of these offices needs access to the system. Since this is an IT system, and you work in the IT department, Ms. VP thinks it's a good idea to let your department run with the project.

Your boss was mightily impressed with the last project you successfully completed and decides you'd be the perfect candidate for this project. It will stretch your skills and give you even more experience in the project management arena. You jump at the opportunity.

You know that this is a project: There are definite beginning and end dates, it's unique, and it's temporary in nature. Even though Ms. VP is planning to purchase this system from a vendor, the implementation of the system is a project that will require the participation of members from both the sales department and the IT department. This new system will interface with existing systems the IT department manages currently.

This project came about as the result of a business need. Ms. VP would like to increase sales for the organization, and she thinks this new tool will help her sales team accomplish that goal. Organizations are always looking for new ways of generating business. It seems that some of the most common business concerns today include operating more efficiently, saving time or money, and serving customers with higher levels of excellence than their competitors. These are some of the reasons behind new project requests. Now we'll look at all the categories of needs and demands that generate projects.

Project Generators—Needs and Demands

There are six needs or demands that drive almost all projects. Understanding why a project came about will sometimes help you clarify the goals and scope of the project (which we'll cover in Chapter 4, "Defining the Project Goals"). For example, if you understand that a project is being driven by a legal requirement, you'll know that the project is required to be completed according to specific conditions and that there are certain aspects of this project that cannot be compromised. The new law may require certain specifications, and those specifications become the requirements for the project. Below is a brief description of the categories of needs and demands that bring about projects.

Business need The customer-profiling project that this section opened with came about because of a business need. This organization would like to increase sales by examining its customer base and allowing sales team members to use the information to improve the number of "yes" responses they get. Business needs (such as improving efficiency, reducing costs, and utilizing resources efficiently) are very common reasons for new project requests.

Market demand The needs of the marketplace can drive new project requests because of changes in the economy, changes in the supply and demand cycles, and so on. As an example, the auto industry may initiate a new project to design and create cars that run on a combination of electricity and gasoline because of a decrease in the supply of oil.

Customer request Customer requests can generate any number of new projects. Keep in mind that customer requests can come from internal customers or from customers that are external to the company. If you're looking at it from the perspective of the vendor, the customer-profiling project given in the opening of this section is an example of a customer-driven project. Your organization, the customer, has purchased a profiling system from the vendor. Your organization has some specific requirements that must be met regarding this system prior to installation. From the vendor's viewpoint, you are the customer and the purchase and customization of this product to suit your own organization's purposes (a customer request) are what are driving this project.

Legal requirement Projects driven by legal requirements come about for as many reasons as there are laws on the books. Perhaps Congress passes a new law requiring warning labels to be placed on certain electrical appliances cautioning users of potential hazards. Producing the labels and attaching them to the appliances, when none were required previously, is an example of a project driven by a legal requirement.

Technological advance We live in an age of technological advances that seemingly take place almost overnight. Things never dreamed of just a generation ago, such as talking on a wireless phone from almost any location, are taken for granted today. Perhaps you work for a telecommunications organization that provides wireless services. Technological advances in the software available for the handheld devices generate a project to create and introduce a new line of services for business customers that takes advantage of the new software capabilities and generates more profits for the organization.

Social need Projects driven by social needs may include things like designing and presenting public awareness campaigns about the prevention of infectious disease or creating educational programs for underprivileged children. Social needs can be driven by concerned customers or concerned citizens. Perhaps the organization's customers put pressure on the company to develop new methods of testing that reduce environmental hazards or protect water supplies in the countries where the company operates.

Whatever the reason for the project, whether it be a business need or customer request, most organizations require some process by which projects are submitted, reviewed, and selected. In the case of new legal requirements, for instance, your organization may have no choice in the matter since the law requires that the project be undertaken and completed. This is usually the exception, however, as most organizations have a formal process for project selection. We'll examine the project request and selection process next.

Project Requests

Let's go back to the beginning of the customer-profiling project that was requested by the VP of Sales. Projects in this organization go through a two-step process before they become projects. First, the project is submitted to a review committee on a project request form, or a project concept document, similar to the one shown below.

project concept document

Outlines the objectives and high-level goals of the project. Used in the selection process to determine whether the project should be approved or denied.

On the first page of the project concept document you can record general information about the project, including the project objectives and overview, so that review committee members can make decisions regarding whether to actually commence working on the project and where it should fall in priority with the other project work of the organization. The review and prioritization is the second step of the process and occurs prior to actually beginning the work of the project.

The project concept document is the first template that we'll talk about in the project Initiation process. You may want to make changes to this template to suit your organization's needs. Keep in mind that the information provided here should be high-level only. Detailed descriptions and objectives will be required later in the project charter and scope statement. This document should not go over two pages, so don't let the requestor get too carried away with the amount of information on this form since you don't know yet whether the selection committee is going to approve the project. The concept document should contain enough information to make a go/no-go decision but should not detail every requirement of the project. You'll be creating other documents during the Planning process that will give the details of the project, including deliverables, requirements, and so forth. The project concept document form should contain these basic elements:

• Project requestor, department or company name, and contact information
• Date of the request
• Project name—you may want to include room for a project number for tracking purposes within your department.
• Business justification—this should include the need or demand that brought about the project and will answer the question, "What business problem or issue will this project solve?" This section can include a subsection describing the impact to the organization if the project is not undertaken. Business justification should also contain appropriate financial information, such as cost/benefit analysis or internal rate of return, to justify the project and help the selection committee make a determination on the project. We'll cover these concepts in the next section.
• Project description—this is a brief overview of the project objectives and what outcomes the requestor is hoping this project will produce. This should include a list of high-level objectives that the project must meet in order to be considered successful.
• Project costs—this information may or may not be available at this point. If the requestor has a limited budget amount, they'd want to note that here. If the requestor knows that a contractor is required for this project or that services need to be purchased outside the organization, they should list those initial cost estimates here if known.
• Required or requested completion date

The second or last page of the concept document has two sections. One is for the project manager—or perhaps a functional manager if a project manager has not yet been assigned—to fill out. This section should include high-level planning estimates. This will give the review committee an idea of how long the project is going to take to complete. It should also include a list of the other business areas in the organization that will be impacted if the project proceeds.

The last section of this page is for the review committee. This section has an area that indicates that the review committee has reviewed the request, the date reviewed, and whether the project has been accepted or denied. Providing an area for signatures is a good idea as well. Here's an example of what this portion of the form may look like:

This is the first document you will file in your project notebook. It's an official project document that can be shared with anyone who asks. You'll reference this document when preparing the project charter. That occurs after the project has been officially approved by the review committee.

Selecting and Prioritizing Projects

Project selection is the next step in the process. But many organizations do not have a formal selection process. Rather, the CIO, or some other senior executive, merely says, "do it," and you have a project on your hands. That's not really the best way to select or prioritize projects. If your organization does not have a formal method for project selection, consider adopting the techniques outlined in this section. You'll likely have more success with the projects you do undertake, and your organization will benefit by weeding out the unprofitable or potentially unsuccessful projects before they even start.

The first task is to establish a selection committee. Review committees or steering committees are formed to review the project concept documents and decide, based on a myriad of criteria, which projects should go forward. Selection criteria can be as simple as someone in the top ranks of the company saying that the project will be done to complex scoring models with multiple criteria to determine which projects are chosen. We'll look at a few of these methods shortly.

Most projects are subject to some type of financial review as well. Organizations are in business to make a profit, unless of course they're a nonprofit organization or a government agency. If they're in business to make money, they're going to be concerned about choosing projects with the greatest potential for revenue. Nonprofits and government agencies aren't concerned with making profits, but they are concerned about getting the greatest utilization out of their operating funds as possible. That means they want to select projects that provide the most benefit for the least cost. Not altogether different from their profit-making partners, their motivation to use resources to their fullest extent possible while receiving the greatest return possible is the same. Let's look at the first category of selection criteria that organizations might use to choose their projects.

Calculating Return

Profit and nonprofit companies alike have limited resources and limited amounts of time. As such, they're interested in knowing whether if they invest the time and resources to produce the product of the project, it will be a good investment. Financial calculations can tell you whether the project is likely to produce a good return on your investment. In other words, are you going to get more out of it over the life of the project (or the product the project is going to produce) than you put into it? Financial calculations are also used as selection criteria when comparing and deciding among several projects.

The most common financial methods used as selection criteria include payback period, cash-flow techniques, cost-benefit analysis, and internal rate of return. Below is a brief explanation of each of these techniques. It's beyond the scope of this book to go into the detailed formulas behind each of these calculations. If you're interested in sitting for the PMP exam or the CompTIA IT Project+ exam, you'll need to know these formulas, so I recommend picking up a copy of the PMP: Project Management Professional Study Guide or some other text that explains these formulas.

payback period

The amount of time it takes to recoup the original investment.

Payback period The payback period is simply the amount of time it takes for the project to pay itself back. The payback period compares the total project costs to the revenue generated as a result of the project and calculates how long it will take for revenues to pay back, or equal, the initial investment. When comparing one project to another of similar size and scope, typically the project with the shortest payback period is chosen.

Discounted cash flow This goes back to the old saying that time is money. The discounted cash flow technique takes into account the time value of money to determine whether the potential revenue stream for the project is worth more than what it costs to produce the product or service of the project. The idea is straightforward. Money in your hand today is worth more than money you might receive tomorrow. Since you have access to the money today, you could invest it and make a profit, put it in the bank and draw interest, start a small business, and so on. Therefore, money you may receive tomorrow needs to be related to what it's worth today.

discounted cash flow

A financial calculation used to determine the project's worth or profitability in today's value. Used as a selection criteria technique when choosing among competing projects.

Discounted cash flow takes into consideration all of the potential future revenue streams related to today's dollar. As an example, $1,000 two years from now given a 7 percent interest rate per year is worth $1,145 (rounded up) today. This technique is used to compare projects of similar size and scope; typically, you'd select the project with the highest return on investment. If you were choosing between this project with a value of $1,145 and one with a value of $1,023, you'd choose the $1,145 project since it has the higher return value.

Cost-benefit analysis Cost-benefit analysis compares the costs to produce the product or service of the project to the financial benefits gained from doing so. You should consider all costs when analyzing the cost benefits, including the costs to produce the product, costs to market the product, and ongoing support costs. This is a simple decision tool. If the costs are lower than the expected return, the project will receive a go recommendation.

Internal rate of return Internal rate of return (IRR) is a very complex calculation that is best determined using a financial calculator. IRR calculates the rate you'd have to apply to the present value of the expected cash inflows (in other words, what the cash inflows are worth in today's dollars) to make the cash inflows equal the original investment. Generally speaking, the higher the IRR, the more profitable the project. IRR assumes cash inflows are reinvested at the IRR value.

internal rate of return (IRR)

The discount rate when the present value of the cash inflows, or the value of the investment in today's dollar, equals the original investment. Used as a selection criteria technique when choosing among competing projects.

It works like this. Say your initial investment is $10,000. Further, let's say the value of the future cash inflows in today's dollars equals $12,000. IRR calculates the discount rate you'd have to apply to the $12,000 to make it equal the initial investment of $10,000. (As I said previously, this is most easily determined using a financial calculator.) Internal rate of return, like the other techniques, compares projects of similar size and scope. Projects with the highest IRR are the projects that should be chosen. For example, Project A produces an IRR of 5 percent while Project B has an IRR of 6 percent. In this case, if the project size and scope are similar, Project B should be chosen.

Financial calculations are an easy way to tell the selection committee whether the project is going to be profitable, and they provide a basis to choose among projects. Some organizations set specific standards for the financial goals of a project. For example, the organization may automatically reject projects with an IRR of less than 5 percent. Or perhaps all projects must have payback periods of less than 18 months. If you're proposing a project that has an IRR of 3 percent, you know that it will not receive approval as soon as you do the calculation.

Selection Methods

Financial calculations are one method used to select projects and usually carry the most weight. Other methods of selecting projects include scoring techniques based on a series of questions or models that score company goals or project goals against criteria determined by the selection or review committee. Combining scoring methods with financial calculations gives you a very clear picture of which projects to choose. However, neither of these methods is an indicator of project success. You can have great financial numbers and high selection scores but still experience project failure. Good project planning will help you avert potential obstacles as will good follow-through and taking proper corrective actions at the right time. But we're getting ahead of ourselves.

Scoring models can take on many forms, including questionnaires, checklists, and complex models where weights are combined with scores. Table 3.1 shows an example of a simple weighted questionnaire.

In this example, the review committee members examine the various criteria against the project concept document and assign scores on a scale of 1–5 where 5 is the best score. The scores are totaled and then used to make a final determination regarding the project. The organization may have predetermined rules for project selection, such as one that says all projects with scores lower than 18 are automatically rejected.

Another example is shown in Table 3.2, which is a simplified weighted selection-scoring model. This table shows the same criteria as Table 3.1 but the criteria have been assigned weights according to the goals of the company or as defined by the selection committee.

The first column in this chart shows the weight the selection committee has assigned to each of the selection factors. The first entry determines whether the project will adequately address the problem or issue stated in the business justification section of the project concept document. Points in this case are assigned a value of 0–100. The first factor was given 90 points. The weight for this factor is 25 percent, making the final score 22.50 (90 points × 0.25). Each factor is assigned points, and the total score is calculated by adding all the scores together. Finally, all the forms are collected and all selection committee scores are added together for a final overall score for the project.

Selection can take several forms. Perhaps the selection committee feels that one of the factors is so important, say the customer satisfaction factor, that scores lower than 20 are an automatic rejection. Along the same lines, another method might look at total score. All projects with scores that fall below a certain number are automatically rejected. If the committee is choosing between projects of similar size and scope, projects with the highest score will be chosen.

Selection methods can also be used to prioritize projects. Financial calculations and scores can be used to rank projects in the order of most profitable, highest return, or greatest potential for market penetration, for instance.

Every organization has powerful members who seem to get what they want when they want it. There's some dynamic at work here that no one can explain, but if this particular person says, "I want Project A," Project A gets done (unless it is wildly out of the realm of possibility). While your selection committee may use several methods, or combinations of methods, to select projects, don't underestimate the political pull of some managers to get projects approved without much fanfare—maybe even without the approval of the selection committee.

Other Selection Criteria

Scores and financial impacts might be a big part of the picture, but there are other factors that should be taken into consideration when selecting projects as well. In fact, some of the things we'll talk about here could easily be added to a weighted scoring model and rated for selection purposes.

Strategic Plans

One of the issues that should be addressed regarding all projects concerns choosing projects that are in line with the organization's strategic plans and goals. In some cases, this might seem obvious. For example, say you work for a pharmaceutical company and someone proposes a project to research and develop a new allergy medication for hay fever sufferers. Since researching and marketing new drugs is the company's bread and butter, it's a no-brainer that this project will at least make it to the selection committee for review. Other reasons may exist that could kill the project in the selection stage, but it is fundamentally in keeping with the company's strategic plans.

Now let's suppose you work for a small pharmaceutical company whose focus is researching and developing medications for particular blood diseases. If the hay fever project were proposed to this selection committee…well, the person who proposed it would probably get a little visit from their manager to remind them of what the company focus really is. Chances are this project proposal would never make it to the selection committee because it wouldn't be in keeping with the organization's strategic plans.

Project requestors should be conscious of the overall strategic mission of the company prior to submitting a project proposal. Selection committees might use adherence to strategic plans as one of the criteria in their project selection models as well.

Risks and Impacts

Another area that concerns most organizations is risks and impacts. Risk comes in many forms, but what concerns the selection committee at this stage is risk to the company—be it financial risk, bad publicity, potential product flops and the like, or project risk, such as the potential failure to complete the project or incompatibility with their customers' business practices. A project that puts the company at risk financially will more than likely not be selected. But keep in mind that organizations have risk-tolerance levels just like you and I do. What may seem risky to one company may not be considered high risk at all to another. Be aware of the risk and impacts to the company and the risk-tolerance levels of the organization when submitting projects for selection. We'll cover risk much more in depth in Chapter 7, "Assessing Risk."

Constraints

Constraints limit the actions of the project team. Organizations may have pre-established guidelines (constraints) for project work estimates, budgets, and resource commitments. For example, perhaps the organization will not take on any project work internally with completion estimates longer than one year. The same type of restrictions may apply to budgets in that no projects in excess of certain dollar amounts will be approved, or there might be pre-established limits on the number of internal resources allowed for project work. Be aware of constraints that might kill the project before it's even started.

Other constraints may include things such as priority conflicts with other projects already in progress, actions or outcomes that would violate laws, regulations, or company policies, and lack of skills in the technologies needed to create the product of the project.

Lack of support from upper management or the project sponsor is another huge red flag. While this may not kill the project up front, it's something you'll want to watch for right from the beginning. Lack of support or commitment tells you right away that you're going to run into problems later on in the project. If you aren't getting much support for the project at this early stage, opt out if at all possible. We'll cover project sponsorship in the next section.

Feasibility Study

Some projects are much more complicated than the organization feels comfortable undertaking. However, the project has such merit that the selection committee doesn't want to just toss it out—in other words, the project sounds good on the surface but more information is needed before a go/no-go decision is made. In these types of situations, a feasibility study might be requested. The feasibility study is sometimes conducted prior to the selection committee review process in anticipation of their concerns, or it can come about as a result of a selection committee recommendation.

feasibility study

A preliminary study that examines the profitability of the project, the soundness or feasibility of the product of the project, the marketability of the product or service, alternative solutions, and the business demands that generated the request.

The purpose of the study is to find out more of the project details, including digging deeper into the business need or demand that brought about the project, and to propose alternative solutions. A feasibility study is generally needed when projects are complex in nature, are larger than the normal projects the organization ordinarily undertakes, require large sums of money to complete, or seek to do something brand new that the organization has never attempted before. Feasibility studies look at things like the viability of the product of the project, the technical issues surrounding the project or product of the project, and the reliability and feasibility of the technology or product proposed.

Feasibility studies should not be conducted by the same people who will make up the final project team. The reason is that project team members may already have formed opinions or have built-in biases toward the study outcome and will sway the results to line up with their biases. I know you would never do this, but you should watch for strong biases among the feasibility team members. If you see personal opinions starting to influence the study outcomes, voice those concerns so that the project gets a fair shake and the results and findings are accurately reported to the selection committee.

Some organizations hire outside consultants to conduct their feasibility studies. This is a great way to eliminate personal opinions from influencing the results of the study. Keep in mind, however, that if you hire a consultant to perform the feasibility study, you should not use that same consultant, or their company, to work on the project. Consultants will approach your project having their product or services in mind as the end result of the study (there are those personal biases again) if they know they're going to work on the final project.

The completion and approval of the feasibility study marks the beginning of the Planning process. Before we jump into Planning, though, we have a few more areas to cover in the Initiation process.

Meeting the Stakeholders

Stakeholders are people or organizations who have a vested interest in your project. You as the project manager are one of the stakeholders in the project. The majority of this book is about your role on the project, but, simply put, you're the one responsible for getting the project completed to the satisfaction of the customer on time, on budget, and within the quality constraints. Some of the other primary stakeholders you'll find on most projects are the project sponsor, functional managers, the customer, the project team, and suppliers or contractors who are critical to the completion of the project.

Stakeholders come from all areas of the organization and can include folks outside the organization as well. If your project involves producing products or services that are potentially hazardous, for example, or your industry has specific regulations it must follow, you'll need to include industry or government representatives on your stakeholder list also. Let's look at the role of the project sponsor first, and then we'll explore the responsibilities of some of the other stakeholders you'll have on your project.

Working with the Project Sponsor

We know that projects come about as a result of a need or demand. But someone has to propose the project and describe the results the project is intended to produce. Someone has to win the support of management and convince them to support this project and dedicate time and resources to it until the project is completed. That person is the project sponsor.

project sponsor

An executive within the organization who champions the project.

The project sponsor rallies support from the upper ranks and generates a lot of fanfare. The project sponsor finds supporters who'll pledge their involvement and resources and who understand the importance of the project. Finally, support is gained, the project is approved, and the hands-on work is passed off to you, the project manager. The project sponsor doesn't go away at this point but instead becomes a partner with you during the project lifecycle.

The project sponsor usually has the most involvement in the Initiation and Planning phases of the project. This person introduces the project, publishes the project charter, and serves as an advisor to the project manager throughout the project. The Executing and Controlling stages don't require as much involvement on the part of the sponsor except when problems arise. By this point in the project, if everything is going according to plan, meeting with the sponsor and keeping him updated on progress may be the extent of the sponsor's involvement until the celebration phase of the Closing process.

The project sponsor is your best friend, and you'll be doing yourself a favor by treating him as such. This is the person who will go to bat for the team when things aren't going well. This executive will steer you through the inevitable roadblocks that will arise during the course of the project and assist you in getting more resources or put pressure on suppliers to perform if needed.

The project sponsor will oversee all the project documents you produce and may assist you with the development of the scope and planning documents in particular. A project sponsor typically has the authority to make decisions and to settle disputes. If a problem cannot be resolved any other way, the project sponsor is the one who makes the final call.

In exchange for the support and trail-blazing on the part of the project sponsor, your responsibility as the project manager is to keep the sponsor informed. Don't wait even a minute to inform the sponsor of potential problems or issues. The project sponsor should be the first to hear about project issues or conflicts and should never hear about these things second-hand. Since the sponsor is generally an executive who has the authority to settle disputes and make decisions, don't hesitate to bring problems and issues to his attention to get matters resolved quickly. The sponsor has a vested interest in the success of the project and will work with you, not against you, to help resolve the problems.

Documenting Stakeholder Roles and Responsibilities

Each stakeholder has a different role in the project, and you'll want to clearly understand and document those roles. This will reduce confusion and serve as a reference for the project team when questions come up later in the project about who does what. This information should be filed in your project notebook so it becomes part of the project documentation. When the information is written down, it assures that everyone on the project understands what their role is. And there's no danger of forgetting the information since you've written it down. Remember Einstein's rule—you don't have to memorize things you write down or can look up. If you haven't gotten used to the idea of documenting yet, you will by the time you get to the end of this book. Documenting is going to become your second best friend after the project sponsor.

Try to keep the list of stakeholders to a reasonable number. For example, one representative from the supplier's company might be all you need to list. But you will want to include all the functional managers who will contribute deliverables or provide the services of their department to the project.

Some of these stakeholders will serve on a project oversight or steering committee that's charged with overseeing the management of the project. Not all stakeholders will serve on this committee. You should meet with the project sponsor, who chairs the oversight committee, to decide which stakeholders should be included in the steering committee. The purpose of this committee is to make decisions outside the realm of the project manager's day-to-day issues and to assure that the organization's resources are being applied correctly to meet the project goals and objectives. Remember that if controversy or conflicts arise among the steering committee members, the project sponsor has the final say in all decisions and has the authority to override the decisions of the steering committee if needed.

Make a list of stakeholders (include their names on your chart) and their responsibilities, similar to the example shown in Table 3.3, and include this in your project notebook.

Your stakeholder list should be more specific than the one shown in this example. I've outlined the generic responsibilities of each of these groups of stakeholders, but you'll want to list their actual responsibility in the project. For example, maybe one of the functional managers on your project will be responsible for installing a new piece of hardware. List that under the responsibility section of your chart. Keep in mind that you aren't going to know everything that's required of the stakeholders at this point, but what you do know should be noted. You'll have an opportunity later to update this chart and to provide additional documentation on responsibilities in the Planning process.

Competing Needs of Stakeholders

Since stakeholders come from various areas of the organization, they have competing needs and interests. This means that one stakeholder's concerns are focused on the aspects of the project that impact their department, information technology as an example, and that another stakeholder has completely different concerns. As the project manager, you'll have to balance these needs and concerns and use those communication skills we talked about in Chapter 2, "Developing Project Management Skills," to keep everyone informed and working together cooperatively.

Stakeholders have a lot of other responsibilities on their plate besides this project that will occupy their time and attention. And unfortunately, sometimes not all stakeholders are supporters of the project. They may not agree with the project, they may not like the project sponsor, they may think their own projects have much more merit than this project, and they may have other higher priorities and don't want to be bothered with project duties. There are dozens of reasons why a stakeholder may not be behind the project. Your job is to get to know the stakeholders and establish an open, trusting environment as soon as possible. If you make the extra effort to get to know the stakeholders and understand their issues and concerns, they're much less likely to cause problems later on. If they feel you are really trying to incorporate and address their concerns and you treat them with respect, they'll likely reciprocate. Get to know your stakeholders and the business processes they oversee, because this will help you make decisions later on regarding the scheduling of activities and resource requirements in the Planning phase.

Creating the Project Charter

We've covered a lot of information before getting to the project charter. The project's been proposed, outlined at a very high level, passed through a selection committee, and finally approved. You know who the sponsor is and by now are likely to know the primary stakeholders and have an idea of their role in the project. As you get further into the project Planning phase, more stake-holders may come to light whom you'll want to add to your stakeholder list. Now it's time to produce the project charter.

The project charter is an official, written document that acknowledges and recognizes that a project exists. It's usually published by the project sponsor but can also be published by another upper-level manager. It's important that the charter be published by a senior-level manager since it gives more weight and authority to the document and it demonstrates management's commitment and support for the project.

project charter

The official project kickoff document. It gives the project manager the authority toproceed with the project and commits resources to the project.

The charter contains several pieces of information about the project that are more in-depth than the project concept document but not as detailed as those found in the scope statement. As you can see, we've started at the 50,000-foot view with the project concept document, and now we're closing in a little tighter with the project charter by refining some of those elements even further. By the time we get to the scope statement, we'll know all the precise requirements of the project and what elements will be used to determine whether the project is successful at completion.

Before we get into the particulars of what goes into the charter, let's take a look at some of the purposes for the project charter.

Purposes for the Charter

The primary purpose of the project charter is twofold: It acknowledges that the project should begin and it assigns the project manager. Let's look a little closer at all the project charter purposes.

Acknowledges that the project should begin The charter announces to all the stakeholders that the project has received approval and been endorsed by upper management. It serves as official notification to the functional business units that their cooperation is needed and expected.

Commits resources to the project The project charter commits the organization's resources to the work of the project. This includes time, materials, money, and human resources.

Ensures that everyone is on the same page This may seem obvious, but you'd be surprised by how many projects get started without a project charter and very few requirements. Perhaps half of the stakeholders think the purpose of the project is to upgrade the network, and the other half think the purpose of the project is to move the servers in the computer room to a new location. That might be a stretch, but you see the point. When the purpose, objectives, and an overview of the project are written down and agreed upon, everyone understands the purpose from the beginning and confusion is eliminated.

Appoints the project manager In many cases, the project manager is known prior to the creation and publication of the project charter. However, the project charter serves as the official notification and appointment of the project manager. The project sponsor formally assigns authority and responsibility for the project to you, the project manager. This means that stakeholders are put on notice that you'll soon be requesting resources from their areas. Also, stakeholders and team members alike know that you're calling the shots on project issues. Does this mean that you're automatically a born leader and everyone is going to do what you say? No, just because you have the authority doesn't mean that people will respect (or respond to) that authority. We'll look at how to overcome these issues when we cover leadership skills in Chapter 10, "Executing the Project."

Provides an overview of the project and its goals The project charter is the first detailed stab at describing the project purpose, overview, goals, and high-level deliverables. While the concept document covered some of these things in a high-level fashion, the project charter goes into more detail.

All this points us back to good communication skills. A well-documented project charter keeps the team on track and helps maintain the focus on the purpose of the project. It helps keep the requirements definition, created in the Planning process, in line with the goals of the project.

Even though I stated earlier that the project charter is published by the project sponsor, don't be surprised if you're asked to actually write the charter contents. If you are asked to write the charter, be certain that you put the project sponsor's name on the document. Remember that the purpose for this document is to acknowledge the project, commit resources, and assign you as project manager. This needs to come from an executive who has the authority to direct people's work. You don't have that authority until the project sponsor appoints you.

In the case of the charter, you'll be exercising those written communication skills. In an upcoming section, you'll find a project charter template. While the template will provide you with the elements that should be included in the charter, you'll need to make certain the content within each area is clear and concise and easily understood by the recipients. (Refer to Chapter 2 if you need a review on effective communication techniques.) We'll discuss what goes into the project charter next.

Essential Elements of a Project Charter

In order to write a good project charter, you or the sponsor will need a couple of other documents at your disposal: the product description and the organization's strategic plan. Let's look at each.

Product description The product description, as you might suspect, is a document that describes the product of the project. The details and characteristics of the product or service of the project are contained in this document. This is not necessarily an official project document, but you certainly should put a copy in your project notebook. The product description is usually completed at roughly the same time as the project concept document but before the project charter. It will begin to give you clues to some of the objectives of the project.

product description

Lists the characteristics of the product including specifications, measurements, or other details that identify the product.

A product description should be clear and concise. If your project consists of manufacturing cases for personal handheld computers, for example, the product description would contain specific information as to size, color, materials, and other exact specifications that describe the product.

Strategic plan The strategic plan contains important information about the overall direction of the company. The project manager should consider this information in light of the project goals. For example, if the organization's strategic plan includes opening offices in three European cities within the next year, and your project includes upgrading the company's network, you'll want to consider the impact the three new offices have on your plan.

strategic plan

Describes the organization's long-term goals and plans.

The project charter has some elements that are similar to the project concept document, but the charter should contain more details. All project documents should have a General Information section that contains the project name, number, date, and perhaps fields for the date the document was modified or a version number, and the author. The remaining sections of the charter should include the following:

Project overview The overview includes the purpose of the project (which was documented in the project concept document) and also explains the reason for undertaking the project. It should also describe the product or service of the project and reference the product description. Attach a copy of the product description to the project charter or let others know where they can get a copy if they'd like one.

Project objectives Project objectives should include the factors that help determine whether the project is a success. For example, you've been charged with implementing a new imaging system in the processing area of your company. Your objectives for this project might read something like this: "Implement a new imaging system that integrates with our existing information technology systems and programs. Implement the new system without interrupting current processing work flows." We'll get into specific requirements and deliverables when we produce the Scope statement.

Business justification It's a good idea to reiterate the business justification for the project in the project charter. The concept document isn't officially signed off by key stakeholders, whereas the project charter is (we'll cover the importance of this shortly), so copy the information in the business justification section of the concept document to the charter. Remember that this section describes the problem or issue the project will solve. This includes describing the benefits to the organization of taking on the project and the impacts to the organization if it doesn't.

Resource and cost estimates If you have initial cost estimates, include them in this section. This section might include the cost of the feasibility study if one was conducted and the costs of the proposed alternatives. We'll establish a project budget and a resource management plan later in the Planning process that will go into detail regarding costs.

Roles and responsibilities Include a roles and responsibility chart like the one created in Table 3.3, with the names of the participants under each title. Remember that you'll have only one project manager and one project sponsor, but there might be multiple entries for functional managers, vendors, customers, etc. This is the section that officially gives you the authority to begin the project and secure the resources needed for the project.

Sign-off This section is very important. Include room for signatures from the project sponsor, key stakeholders, senior management, customers, and anyone else appropriate for this project.

Attachments Attach any other documentation that will help clarify the project, including the product description and the feasibility study.

Some Specifics on the Project Sign-Off

The project charter is not complete until it's signed off. Essential signatures include the project sponsor, the project manager, key stakeholders, senior managers, and the customer. Other signatures can be added as well. Confer with the project sponsor regarding who should sign the document if you're unsure.

Sign-off is important because it assures you that everyone who signs has read the charter and understands the purpose of the project and its primary objectives. Their signatures indicate that they agree with the project and endorse it. It also should mean that you can expect their cooperation on the project and participation in key areas when the time comes.

After obtaining all the signatures, your next step is to deliver a copy of the charter to everyone who signed it. At this time, I would also give copies to the remaining stakeholders (the ones who didn't sign the charter) for review. After delivery of the copies, the fun begins with the project kickoff meeting. First though, let's take a look at a project charter template that you can use for your next project. Modify this to suit your organization's needs and personal style. Oh, don't forget, a copy of the project charter goes into the project notebook as well. If you're also keeping documentation on the intranet for others to see, you should put a copy of the charter there as well.

Sample Project Charter

Let's pull all this together into a template format and see what a project charter might look like. As I mentioned, feel free to modify this to suit your needs. You might want to add your company logo at the top and use some color or shading. The example shown here is pretty bare bones just to give you an idea of what information you're gathering and reporting. Get those creative juices flowing and pretty this up a bit for your use.

Holding the Project Kickoff Meeting

The project has officially begun. The charter has been published and distributed, the project manager has been appointed, and you're ready for the next step—the project kickoff meeting.

The purpose of the kickoff meeting is to accomplish verbally what you accomplished in writing, that is, communicate the objective and purpose of the project, gain support and the commitment of resources for the project, and explain the roles and responsibilities of the key stakeholders.

Creating the Agenda

When you announce the meeting time and place, publish an agenda with the announcement. This will be the rule for all project meetings from here on out. It's always good practice to publish an agenda. Everyone knows what to expect from the meeting, and if you're expecting meeting attendees to come prepared with some type of information, note that in the agenda.

A typical project kickoff meeting agenda might look something like this:

The first thing to do is introduce the key players. Even if these folks have all worked together for quite some time, it doesn't hurt to allow everyone a minute or two to state their name and describe their role in the organization.

Next comes the project overview. Describe in your own words what the project is all about. Include the project purpose and the project objectives in your overview for the group. Then proceed to cover each section of the charter step-by-step and ask for questions when you get to the end of each section. Also ask for input and concerns as you cover each section in the charter.

Take some time when you get to the roles and responsibilities section. You want to make sure that everyone leaves this meeting understanding what's required of them during the course of the project. Now's the time to clear up any misunderstandings and get folks pointed in the right direction.

The closing agenda item for this meeting is a question and answer session. Allow everyone the opportunity to voice their questions and concerns. If questions arise during the meeting that you don't know the answer to, write down each question and let the person know you'll get back to them. Then follow up with a response as quickly as possible.

Questions you may encounter during this first meeting will include things like, "Can we really do this project?" "Can we meet the deadline?" "Do we have the resources for this?" "Whose bright idea was this anyway?" (this one's my favorite) and so on. Answer what you can and of course stay consistent with what's been documented in the project charter.

A well-documented project charter will get the project off to a great start. It will also make your job of developing the scope statement much easier. We'll look at scope statements in detail in Chapter 4, "Defining the Project Goals."

Terms to Know

• discounted cash flow
• feasibility study
• Initiation phase
• internal rate of return (IRR)
• payback period
• product description
• project charter
• project concept document
• project sponsor
• strategic plan

Review Questions

Answers