Identifying the initiator

Your first task in discovering your project’s underlying justification is to determine who had the original idea that led to your project (this person is called the project’s initiator). Project success requires that, at a minimum, you meet this person’s needs and expectations.

Identifying your project’s initiator is easy when they are the person who directly assigns it to you. More likely, however, the person who gives you the project is passing along an assignment they received from someone else. If your project has passed through several people before it reaches you, you may have difficulty determining who really had the initial idea. Not to mention, the original intent may have become blurred if people in the chain purposely or inadvertently changed the assignment a little as they passed it on.

To determine who came up with the original idea for your project, take the following steps:

1. Ask the person who assigns you the project whether they originated the idea.
2. If that person didn’t initiate the idea, ask the following questions:
   • Who gave them the assignment?
   • Who else, if anyone, was involved in passing on the assignment?
   • Who had the original idea for the project?
3. Check with all the people you identified in Step 2 and ask them the same questions.

4. Check the following documentation that may confirm who originally had the idea:

   • Minutes from division-, department-, and organization-wide planning and budget sessions
   • Correspondence and email referring to the project

   • Reports of planning or feasibility studies

     A feasibility study is a formal investigation to determine the likely success of performing certain work or achieving certain results.

   In addition to helping you identify the people who initiated your project, these written sources may shed light on what these people hope to get from it.

5. Consult with people who may be affected by or are needed to support your project; they may know who originated the idea.

Be as specific as possible when specifying your project initiator. In other words, don’t write “The sales department requested promotional literature for product Alpha.” Instead, write “Mary Smith, the sales representative for the northeast region, requested promotional literature for product Alpha.”

Be sure to distinguish between drivers and supporters as you seek to find your project’s initiator (see Chapter 4 for more information about drivers and supporters):

• Drivers have some say when defining the results of the project. They tell you what you should do.
• Supporters help you perform your project. They tell you what you can do.

For example, the vice president of finance who requests a project to upgrade the organization’s financial information systems is a project driver. The manager of the computer center who must provide staff and resources to upgrade the organization’s information systems is a project supporter.

Sometimes supporters claim to be drivers. For example, when you ask the manager of the computer center, they may say they initiated the project. In reality, however, the manager authorized the people and funds to perform the project, but the vice president of finance initiated the project.

Determining who is contributing funds to support the project

People who contribute funds to support project activities are called project owners or sponsors (see Chapter 11 for more on these important project stakeholders). These people never contribute funds to support a project unless they expect to benefit in some way from the project’s end results. Identify them and their specific project expectations early in the life of the project, and communicate with them frequently throughout the project to determine whether their expectations change.

Recognizing other people who may benefit from your project

Although they may not have initiated the idea, other people may benefit from your completed project. They may be people who work with, support, or are clients of your project’s drivers, or they may have performed similar projects in the past. They may have expressed interests or needs in areas addressed by your project in meetings, correspondence, or informal conversations.

Identify these other people as soon as possible to determine what their particular needs and interests are and how you can appropriately address them. These additional stakeholders may include people who

• Know the project exists and have expressed an interest in it
• Know it exists but don’t realize it can benefit them
• Are unaware of your project

Identify these additional stakeholders by doing the following:

• Review all written materials related to your project.
• Consult with your project’s drivers and supporters.
• Encourage everyone you speak to about the project to identify others who may benefit from it.

As you identify people who can benefit from your project, also identify people who strongly oppose it. Figure out why they oppose your project and whether you can address their concerns. Take the time to determine whether they may be able to derive any benefits from your project, and, if they can, explain these benefits to them. If they continue to oppose your project, make a note in your risk-management plan about their opposition and how you plan to deal with it (see Chapter 10 for how to analyze and plan for project risks and uncertainties).

Distinguishing the project champion

A project champion is a person in a high position in the organization who strongly supports your project; advocates for your project in disputes, planning meetings, and review sessions; and takes necessary actions to help ensure that your project is successful.

Sometimes the best champion is one whose support you never have to use. Just knowing that this person supports your project helps other people appreciate its importance and encourages them to work diligently to ensure its success.

Check with your project’s drivers and supporters to find out whether your project already has a champion. If it doesn’t, work hard to recruit one by looking for people who can reap benefits from your project and who have sufficient power and influence to encourage serious, ongoing organizational commitment to your project. Explain to these people why the success of your project is in their best interest and how you may need their specific help as your project progresses. Assess how interested they are in your project and how much help they’re willing to provide. (Flip to Chapters 4 and 11 for more information on project champions.)

Considering people who’ll implement the results of your project

Most projects create a product or service to achieve a desired result. Often, however, the person who asks you to create the product or service isn’t the one who’ll actually use it.

Suppose your organization’s director of sales and marketing wants to increase annual sales by 10 percent in the next fiscal year. This person decides that developing and introducing a new product, XYZ, will allow them to achieve this goal. However, they won’t actually go to all your organization’s customers and sell them XYZ; their sales staff will. Even though they didn’t come up with the idea to develop XYZ, the sales staff may have strong opinions about the characteristics XYZ should have — and so will the customers who ultimately buy (or don’t buy!) the product.

To identify the real users of project products and services, try to do the following early in your project planning:

• Clarify the products and services that you anticipate producing.
• Identify exactly who will use these products and services and how they’ll use them.

After you identify these people, consult with them to determine any additional interests or needs they may have that your project should also address.

Determining your project drivers’ real expectations and needs

The needs that your project addresses may not always be obvious. Suppose, for example, that your organization decides to sponsor a blood drive. Is the real reason for your project to address the shortage of blood in the local hospital or to improve your organization’s image in the local community?

The needs your project must satisfy to successfully achieve its purpose are termed your project’s requirements.

When you clearly understand your project’s requirements, you can

• Choose project activities that enable you to accomplish the true desired results (see Chapter 6 for information on identifying project activities).
• Monitor performance during and at the end of the project to ensure that you’re meeting the real needs (see Chapter 14 for more information on how to track a project during performance).
• Realize when the project isn’t meeting the real needs so that you can suggest modifying or canceling it.

When you’re initially assigned a project, you hope you’re told the products you’re supposed to produce and the needs you’re supposed to address. However, often you’re told what to produce (the outcomes), but you have to figure out the needs yourself.

Consider the following questions as you work to define your project’s requirements:

• What needs do people want your project to address? Don’t worry at this point whether your project actually can address these needs or whether it’s the best way to address the needs. You’re just trying to identify the hopes and expectations that led to this project in the first place.
• How do you know the needs you identify are the real hopes and expectations that people have for your project? Determining people’s real thoughts and feelings can be difficult. Sometimes they don’t want to share them; sometimes they don’t know how to clearly express them.

When speaking with people to determine the needs your project should address, try the following techniques:

• Encourage them to speak at length about their needs and expectations.
• Listen carefully for any contradictions.
• Encourage them to clarify vague ideas.
• Try to confirm your information from two or more independent sources.
• Ask them to indicate the relative importance of addressing each of their needs.

The following scheme is useful for prioritizing a person’s needs:

• Must have: The project must address these needs, at the very least.
• Should have: The project should address these needs, if at all possible.
• Nice to have: It would be nice for the project to address these needs, if doing so doesn’t negatively affect anything else.

See whether your organization performed a formal cost-benefit analysis for your project. A cost-benefit analysis is a formal identification and assessment of the following (see Chapter 3 for details):

• The benefits anticipated from your project
• The costs of:
  • Performing your project
  • Using and supporting the products or services produced by your project

The cost-benefit analysis documents the results that people were counting on when they decided to proceed with your project. Therefore, the analysis is an important source for the real needs that your project should address.

Confirming that your project can address people’s needs

Although needs may be thoroughly documented (see the preceding section), you may have difficulty determining whether your project can successfully address those needs. On occasion, companies fund formal feasibility studies to determine whether a project can successfully address a particular need.

Other times, however, your project may be the result of a brainstorming session or someone’s creative vision. In this case, you may have less confidence that your project can accomplish its expected results. Don’t automatically reject a project at this point, but do aggressively determine the chances for success and the actions you can take to increase these chances. If you can’t find sufficient information to support your analysis, consider asking for a formal feasibility study.

If you feel the risk of project failure is too great, share your concerns with the key decision-makers and explain why you recommend not proceeding with your project. See the discussion of risk management in Chapter 10 for more information.

Uncovering other activities that relate to your project

Your project doesn’t exist in a vacuum. It may require results from other projects, it may generate products that other projects will use, and it may address needs that other projects also address. For these reasons, you need to identify projects related to yours as soon as possible so you can coordinate the use of shared personnel and resources and minimize unintended overlap in project activities and results.

Check the following sources to identify projects that may be related to yours:

• Your project’s stakeholders
• Centrally maintained lists of projects planned or being performed by your organization
• Organization-wide information-sharing vehicles, such as newsletters or your organization’s intranet
• Your organization’s project management office (PMO)
• Upper-management committees responsible for approving and overseeing your organization’s projects
• Your organization’s finance department, which may have established labor or cost accounts for such projects
• Your organization’s procurement department, which may have purchased goods or services for such projects
• Your organization’s information technology department, which may be storing, analyzing, or preparing progress reports for such projects
• Functional managers whose people may be working on such projects

Emphasizing your project’s importance to your organization

How much importance your organization places on your project directly influences the chances for your project’s success. When conflicting demands for scarce resources arise, resources usually go to those projects that can produce the greatest benefits for the organization.

Your project’s perceived value depends on its intended benefits and people’s awareness of those benefits. Take the following steps to help people understand how your project will support the organization’s priorities:

1. Look for existing statements or documents that confirm your project’s support of your organization’s priorities.

   Consult the following sources to find out more about your organization’s priorities:

   • Long-range plan: A formal report that identifies your organization’s overall direction, specific performance targets, and individual initiatives for the next one to five years
   • Annual budget: The detailed list of categories and individual initiatives that your organization will financially support during the year
   • Capital appropriations plan: The itemized list of all planned expenditures (over an established minimum amount) for facilities and equipment purchases, renovations, and repairs during the year
   • Your organization’s key performance indicators (KPIs): Performance measures that describe your organization’s progress toward its goals

   When you review these documents, note whether your project or its intended outcome is specifically mentioned.

   In addition, determine whether your organization has made specific commitments to external customers or upper management related to your project’s completion.

2. Describe in your brief statement of justification how your project relates to the organization’s priorities.

   Mention existing discussions of your project from the information sources mentioned in the preceding step. If your project isn’t specifically referenced in these sources, prepare a written explanation of how your project and its results will impact the organization’s priorities.

Occasionally, you may have a hard time identifying specific results that people expect your project to generate. Perhaps the person who initiated the project has assumed different responsibilities and no longer has any interest in it, or maybe the original need the project was designed to address has changed. If people have trouble telling you how your project will help your organization, ask them what would happen if you didn’t perform your project. If they conclude that it wouldn’t make a difference, ask them how you can modify your project to benefit the organization. If they don’t think your project can be changed to produce useful results, consider suggesting that the project be canceled.

Organizations are consistently overworked and understaffed. Spending precious time and resources on a project that everyone agrees will make no difference is the last thing your organization needs or wants. More likely, people do realize that your project can have a positive impact on the organization. Your job, then, is to help these people consistently focus on the valuable results your project has to offer.

Being exhaustive in your search for information

In your quest to find out what your project is supposed to accomplish and how it fits into your organization’s overall plans, you have to seek information that’s sensitive, sometimes contradictory, and often unwritten. Getting this information isn’t always easy, but following these tips can help make your search more productive:

• Try to find several sources for the same piece of information. The more independent sources that contain the same information, the more likely the information is to be correct.

• Whenever possible, get information from primary sources. A primary source contains the original information. A secondary source is someone else’s report of the information from the primary source.

  Suppose you need information from a recently completed study. You can get the information from the primary source (which is the actual report of the study written by the scientists who performed it), or you can get it from secondary sources (such as articles in magazines or scientific journals by authors who paraphrased and summarized the original report).

  The further your source is from the primary source, the more likely the secondary information differs from the real information.

• Look for written sources, because they’re the best. Check relevant minutes from meetings, correspondence, email, reports from other projects, long-range plans, budgets, capital improvement plans, market requirement documents, and cost-benefit analyses.

• Speak with two or more people from the same area to confirm information. Different people have different styles of communication as well as different perceptions of the same situation. Speak with more than one person, and compare their messages to determine any contradictions.

  If you get different stories, speak with the people again to verify their initial information. Determine whether the people you consulted are primary or secondary sources (primary sources tend to be more accurate than secondary ones). Ask the people you consulted to explain or reconcile any remaining differences.

• When speaking with people about important information, arrange to have at least one other person present. Doing so allows two different people to interpret what they hear from the same individual.
• Write down all information you obtain from personal meetings. Share your written notes and summaries with other people who were present at the meeting to ensure that your interpretation is correct and to serve as a reminder of agreements made during the meeting.
• Plan to meet at least two times with your project’s key stakeholders. Your first meeting starts them thinking about issues. Allow some time for them to think over your initial discussions and to think of new ideas related to those issues. A second meeting gives you a chance to clarify any ambiguities or inconsistencies from the first session. (See Chapter 4 for more information on project stakeholders.)
• Practice active listening skills in all your meetings and conversations. See Chapter 15 for information on how to practice active listening.
• Wherever possible, confirm what you heard in personal meetings with written sources. When you talk with people, they share their perceptions and opinions. Compare those perceptions and opinions with written, factual data (from primary sources, if possible). Discuss any discrepancies with those same people.

Making your objectives clear and specific

You need to be crystal clear when stating your project’s objectives. The more specific your project objectives are, the greater your chances are of achieving them. Here are some tips for developing clear objectives:

• Be brief when describing each objective. If you take an entire page to describe a single objective, most people won’t read it. Even if they do read it, your objective probably won’t be clear and may have multiple interpretations.
• Don’t use technical jargon or acronyms. Each industry (such as pharmaceuticals, telecommunications, finance, and insurance) has its own vocabulary, and so does each company within that industry. Within companies, different departments (such as accounting, legal, and information services) also have their own jargons. Because of this proliferation of specialized languages, the same three-letter acronym (abbreviated “TLA”) can have two or more meanings in the same organization! To reduce the chances for misunderstandings, express your objectives in language that’s familiar to people of all backgrounds and experiences.
• Make your objectives SMART, as follows:
  • Specific: Define your objectives clearly, in detail, without ambiguity or room for misinterpretation.
  • Measurable: State the measures and performance specifications you’ll use to determine whether you’ve met your objectives.
  • Aggressive: Set challenging objectives that encourage people to stretch beyond their comfort zones.
  • Realistic: Set objectives the project team believes it can achieve.
  • Time sensitive: Include the date by which you’ll achieve the objectives.
• Make your objectives attainable. Make sure that you and your team believe you can influence the success of each objective. If you don’t believe you can, you may not commit 100 percent to achieving it (and most likely you won’t even try). In that case, it becomes a wish, not an objective.
• Identify all objectives. Time and resources are always scarce, so if you don’t specify an objective, you won’t (and shouldn’t) work to achieve it.

• Be sure drivers and supporters agree on your project’s objectives. When drivers buy into your objectives, you feel confident that achieving the objectives constitutes true project success. When supporters buy into your objectives, you have the greatest chance that people will work their hardest to achieve them.

  If drivers don’t agree with your objectives, revise them until they do agree. After all, your drivers’ needs are the whole reason for your project! If supporters don’t buy into your objectives, work with them to identify their concerns and develop approaches they think can work.

Probing for all types of objectives

When you start a project, the person who makes the initial project request often tells you the major results they want to achieve. However, they may want the project to address other items that they forgot to mention to you. And other (as yet unidentified) people may also want your project to accomplish certain results.

You need to identify all project objectives as early as possible so you can plan for and devote the necessary time and resources to accomplishing each one. When you probe to identify all possible objectives, consider that projects may have objectives in the following three categories:

• Physical products or services
• The effects of these products or services
• General organizational benefits that weren’t the original reason for the project

Suppose that your information technology (IT) department is about to purchase and install a new software package for searching and analyzing information in the company’s parts-inventory database. The following are examples of objectives this project may have in each category:

• Physical product or service: The completed installation and integration of the new software package with the parts-inventory database
• The effect of the product or service: Reduced costs of inventory and storage due to timelier ordering facilitated by the new software
• A general organizational benefit: Use of the new software with other company databases

An objective is different from a serendipity (a chance occurrence or coincidence). In the previous example of the new software package, consider that one project driver won’t be completely satisfied unless the software for the parts-inventory database is also installed and integrated with the company’s product-inventory database. In this case, installing the system on the company’s product-inventory database must be an objective of your project so you must devote specific time and resources to accomplish it. On the other hand, if your stakeholders will be happy whether you do or don’t install the software on the second database, being able to use the software on that database is a serendipity — meaning you shouldn’t devote any time or resources specifically to accomplishing it.

Determining all project objectives requires you to identify all drivers who may have specific expectations for your project. See Chapter 4 for a discussion of the different types of stakeholders and tips on how to identify each one.

Anticipating resistance to clearly defined objectives

Some people are uncomfortable committing to specific objectives because they’re concerned they may not achieve them. Unfortunately, no matter what the reason, not having specific objectives makes knowing whether you’re addressing (and meeting) your drivers’ true expectations a lot more difficult. In other words, when your objectives aren’t specific, you increase the chances that your project won’t succeed.

Here are some excuses people give for not defining their objectives too specifically, along with suggestions for addressing those excuses:

• Excuse 1: Too much specificity stifles creativity.

  Response: Creativity should be encouraged — the question is where and when. Your project’s drivers should be clear and precise when stating their objectives; your project’s supporters should be creative when figuring out ways to meet those objectives. You need to understand what people do expect from your project, not what they may expect. The more clearly you can describe your actual objectives, the more easily you can determine whether (and how) you can meet them.

• Excuse 2: Your project entails research and new development, and you can’t tell today what you’ll be able to accomplish.

  Response: Objectives are targets, not guarantees. Certain projects have more risks than others. When you haven’t done a task before, you don’t know whether it’s possible. And, if it is possible, you don’t know how long it’ll take or how much it’ll cost. But you must state at the outset exactly what you want to achieve and what you think is possible, even though you may have to change your objectives as the project progresses.

• Excuse 3: What if interests or needs change?

  Response: Objectives are targets based on what you know and expect today. If conditions change in the future, you may have to revisit one or more of your objectives to see whether they’re still relevant and feasible or whether they, too, must change.

• Excuse 4: The project’s requestor doesn’t know what they specifically want the project to achieve.

  Response: Ask them to come back when they do. If you begin working on this project now, you have a greater chance of wasting time and resources to produce results that the requestor later decides they don’t want.

• Excuse 5: Even though specific objectives help determine when you’ve succeeded, they also make it easier to determine when you haven’t.

  Response: Yep. That’s true. However, because your project was framed to accomplish certain results, you need to know whether your project achieved those results. If it didn’t, you may have to perform additional work to accomplish them. In addition, you want to determine the benefits the organization is realizing from the money it’s spending.

Understanding the types of limitations

Project limitations typically fall into several categories. By recognizing these categories, you increase the chances that you’ll discover all the limitations affecting your project. Your project’s drivers and supporters may have preset expectations or requirements in one or more of the following categories:

• Results: The products and effect of your project. For example, the new product must cost no more than $300 per item to manufacture, or the new book must be fewer than 384 pages in length.
• Timeframes: When you must produce certain results. For example, your project must be done by June 30. You don’t know whether you can finish by June 30; you just know that someone expects the product to be produced by then.
• Resources: The type, amount, and availability of resources to perform your project work. Resources can include people, funds, equipment, raw materials, facilities, information, and so on. For example, you have a budget of $100,000; you can have two people full time for three months; or you can’t use the test laboratory during the first week in June.
• Activity performance: The strategies for performing different tasks. For example, you’re told that you must use your organization’s printing department to reproduce the new users’ manuals for the system you’re developing. You don’t know what the manual will look like, how many pages it’ll be, how many copies you’ll need, or when you’ll need them. Therefore, you can’t know whether your organization’s printing department is up to the task. But at this point, you do know that someone expects you to have the printing department do the work.

Be careful of vague limitations; they provide poor guidance for what you can or can’t do, and they can demoralize people who have to deal with them. Here are some examples of vague limitations and how you can improve them:

• Timeframe limitation:
  • Vague: “Finish this project as soon as possible.” This statement tells you nothing. With this limitation, your stakeholders may suddenly demand your project’s final results — with no advance warning.
  • Specific: “Finish this project by close of business June 30.”
• Resource limitation:
  • Vague: “You can have Laura Webster on your project part-time in May.” How heavily can you count on her? From Laura’s point of view, how can she juggle all her assignments in that period if she has no idea how long each one will take?
  • Specific: “You can have Laura Webster on your project four hours per day for the first two weeks in May.”

When people aren’t specific about their constraints, you can’t be sure whether you can honor their requests. The longer people wait to be specific, the less likely you are to adhere to the limitation and successfully complete your project.

Looking for project limitations

Determining limitations is a fact-finding mission, so your job is to identify and examine all possible sources of information. You don’t want to miss anything, and you want to clarify any conflicting information. After you know what people expect, you can determine how (or whether) you can meet those expectations. Try the following approaches:

• Consult your stakeholders. Check with drivers about limitations regarding desired results; check with supporters about limitations concerning activity performance and resources.
• Review relevant written materials. These materials may include long-range plans, annual budgets and capital appropriations plans, cost-benefit analyses, feasibility studies, reports of related projects, minutes of meetings, and individuals’ performance objectives.
• When you identify a limitation, be sure to note its source. Confirming a limitation from different sources increases your confidence in its accuracy. Resolve conflicting opinions about a limitation as soon as possible.

Addressing limitations in your scope statement

List all project limitations in your scope statement (which we describe earlier in this chapter). If you have to explore ways to modify your project plan in the future, this list of limitations can help define alternatives that you can and can’t consider.

You can reflect limitations in your project in two ways:

• Incorporate limitations directly into your plan. For example, if a key driver says you have to finish your project by September 30, you may choose to set September 30 as your project’s completion date. Of course, because September 30 is the outside limit, you may choose to set a completion date of August 31. In this case, the limitation influences your target completion date but isn’t equivalent to it.
• Identify any project risks that result from a limitation. For example, if you feel the target completion date is unusually aggressive, the risk of missing that date may be significant. Your goal is to develop plans to minimize and manage that risk throughout your project. (See Chapter 10 for more information on how to assess and plan for risks and uncertainties.)