A project achieves success by delivering suitable value to various stakeholders—people or groups that are actively involved in a project, are affected by its outcome, or can influence its outcome (Project Management Institute 2004; Smith 2000). Begin your quest for success by identifying these stakeholders and what is important to them. "Value" could translate to time savings for a corporate department, market dominance for a commercial software vendor, or increased productivity for a user. Look for stakeholders both inside and outside the development organization, in the categories shown in Table 4-2. Stakeholders can be involved in a project in many different ways (McManus 2005).
Table 4-2. Some Internal and External Stakeholder Categories
Internal | External |
---|---|
Project manager | Direct and indirect user classes |
Program manager | Procuring customers |
Product manager | Regulatory bodies |
Executive sponsor or funding authority | Auditors |
Project team members, including analysts, developers, testers, and technical writers | Standards certification bodiesGovernment agencies |
Quality assurance | Subcontractors |
Infrastructure support staff | Prime contractors |
Company owners or shareholders | Suppliers of materials, information, and services |
Marketing | Maintainers or users of related products |
Manufacturing | Business partners |
Finance | Venture capitalists |
Legal | The general public |
Sales | |
User support and help desk staff |
Next, perform a stakeholder analysis to reveal the expectations each stakeholder group has for the project. Identify each stakeholder’s interests, or win conditions (Boehm and Ross 1989; Brackett 2001). Interests include financial benefits, specific time to market, required functionality, performance targets, usability, reliability, or other quality characteristics. Then evaluate how the project will be affected if each interest is or is not satisfied. The project might not be able to fully satisfy everyone’s interests. This analysis will help you determine which interests are the most compelling. Table 4-3 illustrates a simple template you can use to document essential stakeholder information. You could store this stakeholder profile table in the project charter (see Chapter 7).
Table 4-3. Simple Stakeholder Analysis Example
Stakeholder | Major Benefits | Attitudes | Win Conditions | Constraints |
---|---|---|---|---|
Executives | Increased revenue | See product as an avenue to 25% increase in market share within 1 year | Richer and more novel feature set than competitors have | Maximum budget = $1.4 million |
Manuscript Editors | Fewer errors in their work | Highly receptive, but reluctant to go through extensive retraining | Automatic error correction capabilities; ease of use; high reliability | Must run on existing low-end PCs |
Legal Aides | Quick access to data | Resistant unless product is keystroke-compatible with current system | Ability to handle much larger database than current system; easy to learn | No budget available for retraining |
Also assess the relative influence each stakeholder has on the project’s decisions. Some stakeholders might wield great political power. Others could dictate essential features, impose restricting constraints, or be a potential source of substantial revenue. Still other stakeholders can serve as blockers to break down barriers that confront the team. Key stakeholders are those who can strongly influence the project’s decisions—and those whom it’s most important to satisfy.
Expect to encounter conflicting stakeholder interests. Finance might want the lowest possible unit cost for the product, although the development team wishes to use expensive, cutting-edge technologies to meet stringent performance demands. Different market segments will value different combinations of time to market, feature richness, and reliability (see Chapter 5). Identifying your key stakeholders will help you to resolve such conflicts as they arise and to negotiate win-win solutions that maximize benefits for the greatest number of stakeholders.
Overlooking important stakeholders, which means you’re simply lucky if they view the project as a success.
Some years ago, my small software team was building an information system for a large corporation’s research division. The stakeholder who represented our primary user group naturally wanted us to address just his department’s needs. However, we identified other departments as also being important stakeholders. This led us to include functionality that made the system valuable to additional user classes. The key stakeholder wasn’t thrilled about the extra time it took us to deliver "his" application. But the stakeholder analysis helped us make the right strategic choices to best leverage the company’s investment in this project.
Because of the many project decisions that lie ahead, it’s essential to determine your key decision makers and to define a decision-making process very early in the project. Groups that must make decisions need to select an appropriate decision rule (Gottesdiener 2001). Some possible decision rules include:
Voting, majority rules
Reaching unanimous agreement
Achieving consensus
Delegating the decision to a single individual
Having the person in charge make the decision after collecting input from others
There is no single correct decision rule, but every group needs to select one before they confront their first significant decision. Participative decision making generates more buy-in to the outcome than does unilateral decision making, which often is done by people with insufficient information about the problem being addressed.
3.141.192.183