Stanley E. Portny - Project Management For Dummies

Agreements and contracts: Documentation of agreed-upon intentions and expectations between multiple parties. Examples include: Fixed-price contracts : These contracts define a deliverable and a price to be paid for that deliverable. As long as the project scope adheres to the contractually defined scope, the price does not change. Changes to scope are handled through change orders. Time and materials contracts : T&M contracts require each hour spent working on the project to be logged and invoiced to the client, including any materials or expenses required to satisfy the contract. These contracts often contain a not-to-exceed clause. This clause specifies the maximum number of hours to be invoiced to the client, assuming scope has not changed, before a new contract for any remaining or additional work is executed. Change orders : We all hope to be able to foresee every possible “gotcha” that could arise before our projects even begin but, alas, hope is never a winning strategy. When scope changes, change orders capture the nature of the change and any associated budget, schedule, or resource implications. See Chapter 14for more on this.

Other artifacts: Some artifacts don’t fit into one of the previous buckets, but are useful and add value, nonetheless. Examples include: Bid documents : Help to answer necessary questions to enable an informed procurement decision, including request for information (RFI), request for quotation (RFQ), and request for proposal (RFP). Requirements document : Depending on the type of project, this is often broken down further into a business requirements document, functional requirements document, and technical requirements document. See Chapter 5for more on this.

Table 3-1notes topics in this chapter that may be addressed on the Project Management Professional (PMP) certification exam and that are also included in A Guide to the Project Management Body of Knowledge , 7 thEdition ( PMBOK 7 ).

TABLE 3-1Chapter 3 Topics in Relation to the PMP Exam and PMBOK 7

Chapter 4

IN THIS CHAPTER

Compiling your project’s diverse stakeholders into a stakeholder register

Identifying your drivers, supporters, and observers

Using an effective format for your stakeholder register

Determining who has authority in your project

Prioritizing your stakeholders by their levels of power and interest

Often a project is like an iceberg: Nine-tenths of it lurks below the surface. You receive an assignment and think you know what it entails and who needs to be involved. Then, as the project unfolds, new people emerge who may affect your goals, your approach, and your chances for project success.

You risk compromising your project in the following ways when you don’t involve key people or groups in your project in a timely manner:

You may miss important information that can affect the project’s performance and ultimate success.

You may insult someone. And you can be sure that when someone feels you have slighted or insulted them, they’ll take steps to make sure you don’t do it again!

As soon as you begin to think about a new project, start to identify people who may play a role. This chapter shows you how to identify these candidates; how to decide whether, when, and how to involve them; and how to determine who has the authority, power, and interest to make critical decisions.

A project stakeholder is any person or group that supports, is affected by, or is interested in your project. Your project’s stakeholders can be inside or outside your organization, and knowing who they are helps you

Plan whether, when, and how to involve them.

Determine whether the scope of the project is bigger or smaller than you originally anticipated.

You may hear other terms used in the business world to describe project stakeholders, but these terms address only some of the people from your complete project stakeholder register. Here are some examples:

A distribution list identifies people who receive project communications. These lists are often out-of-date for a couple of reasons. Some people remain on the list simply because no one removes them; other people are on the list because no one wants to run the risk of insulting them by removing them. In either case, having their names on this list doesn’t ensure that these people actually support, are affected by, or are interested in your project.

Team members are people whom the project manager directs. All team members are stakeholders, but the stakeholder register includes more than just team members.

As you identify the different stakeholders for your project, record them in a stakeholder register. Check out the following sections for information on how to develop this register.