The objective of participant identification is to identify all the project participants so that expectations can be understood and managed.
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.  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 .
 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:
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:
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. 
 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).
The Agile Revolution
Guiding Principles: Customers and Products
Guiding Principles: Leadership-Collaboration Management
An Agile Project Management Model
The Envision Phase
The Speculate Phase
The Explore Phase
The Adapt and Close Phases
Building Large Adaptive Teams