Practice: Participant Identification

Practice Participant Identification

Objective

The objective of participant identification is to identify all the project participants so that expectations can be understood and managed.

Discussion

Project participants comprise any individuals or groups that are part of the project community: from customers of the product, who can influence the project and determine requirements; to executives who provide funding and assume some managerial oversight of the project; to the core project team members who work to deliver the product.

There are three broad categories of participants: customers (which could include end users, their managers, the product manager, and the executive sponsor), project team members, and stakeholders. [8] In this book, the term "stakeholder" will be used for internal participants, such as managers who are not direct customers of the product, and external participants such as vendors .

[8] Some people may be concerned that customers aren't included in the project team. They are part of the overall "team," but they have different responsibilities from the delivery team. In the final analysis, whether you think of customers and developers as a single team or two teams isn't nearly as important as the degree of collaboration and interaction between them.

From a broad-brush perspective, customers provide requirements, project team members build the product, and stakeholders contribute constraints. Customers are those participants who use the product to create value for themselves or their organizations. Project team members are the developers and managers who are actively involved in delivering the product. Stakeholders provide constraints, compliance requirements, and resources (vendors). For example, the audit staff dictate certain process and control compliance requirements, while the financial department may require certain reports from the team. External regulatory agencies may impose product testing constraints.

Author Rob Thomsett proposes three levels of participants (whom he calls "stakeholders"), each with a different potential degree of impact on a project:

• Critical: These are the participants who can prevent your project from achieving success before or after implementation; in other words, the showstoppers.
• Essential: These participants can delay your project from achieving success before or after implementation. In other words, you can work around them.
• Nonessential: These participants are interested parties. They have no direct impact on your project, but if they are not included in your communication, they can change their status to critical or essential (Thomsett 2002).

Identifying a project's participants is a project management task that is very easy to talk about and often most difficult to do well. Project team after project team has been blindsided by unidentified participants coming forth to bury the project with unforeseen information or political agendas .

But identifying and managing participants has another subtle, but important justificationit helps improve teamwork. According to Carl Larson and Frank LaFasto (1989), "external support and recognition" of the team by the organization contributes to success, or more precisely, lack of that support is a cause of failure. A development project doesn't operate in a vacuum ; it operates within a larger organizational environment. When that wider organization withholds recognition, resources, or support, development teams will feel isolated and abandonednot an atmosphere that makes for effective work.

A list of project participants might include:

• Executive sponsor: the person (or group of people) who champions the product and makes key decisions about the product's goals and constraints
• Project manager: the person who leads the team charged with delivering the results
• Product manager: the person who leads the team responsible for determining what results to deliver
• Lead engineer: the person who guides the technical aspects of the team's delivery
• Management: a potentially wide range of individuals who can be in charge of participant organizations; may have budget or technical decision-making authority or influence over the project outcomes
• Customer team: the individuals, both full and part time, who are charged with determining features that need to be built and prioritizing them
• Project team: the individuals, both full and part time, who are charged with delivering results
• Suppliers: external companies or individuals who provide services or product components
• Government: regulatory agencies that require information, reports, certifications, and more

Nearly all of the above roles are self-explanatory or, as in the case of project and product managers, are explained throughout this book. However, one role does need a further bit of explanation herethe lead engineer role. Any role like that of project manager or lead engineer can be interpreted from a perspective of either a command-control or a leadership-collaboration management style. Since many people have less experience with the latter, they tend to interpret the words "lead" and "manager" from a hierarchical, control-oriented perspective. But the lead engineer's role is much like the project manager'sto guide, to steer, to facilitate knowledge sharing, to encourage collaboration, to participate in team decision making, and, periodically, to be the final arbiter of critical technical decisions. The same person may also fill both the lead engineer and project manager roles when he or she has the right combination of skills and experience.

The more complex the participant group, the more time project managers must spend managing expectations, getting critical project decisions made, and keeping the project from being pulled in too many directions. Identification is the first step in integrating various participants into the project community. [9]

[9] Identifying the right project participants in product development efforts, and getting them involved at the right time, is critical. For example, software licensing decisions can impact design, so waiting until the later stages of a software project to include the legal department can cause delays at the end. A great reference on this topic for software product developers is (Hohmann 2003).