Alpha of external project roles
In the system scheme of the project, the alpha of external project roles/stakeholders refers to those project roles for which the supra-system of the target system of the project is their target. The team (internal project roles) is represented by a separate alpha. Stakeholders have two meanings: their actual roles and sometimes an agent playing a role. So be careful not to confuse the needs of Prince Hamlet with the needs of Vasya Pupkin, who is playing the role of Prince Hamlet today (in speech, they can both be "stakeholders," so it is better to use "external project role" to discuss their needs).
External project roles provide the opportunity (keep track of the types: the alpha of commercial opportunity was just mentioned!) for the project to be completed; they support it financially or can prohibit it (for example, the external project roles "regulator," "supervisor," "inspector"). The success of the target system (keep track of the types: the alpha of realizing the target system was mentioned!) is determined precisely by the external project roles because the target system is the one in which their role interests/preferences are maintained.
Project roles can be performed by groups of performers (for example, 30,000 users of a software application with 30,000 sales, or 1,000 viewers of a sports match), each group can be represented by some "template of a project role," or even a team member (for example, responsible for promotion/marketing), responsible for representing the diverse interests of external roles and defending their compliance both to the team and to other external project roles.
A good practice is to immediately divide the alpha "external project roles" into separate sub-alphas of individual project roles and keep track of the state of each of these sub-alphas separately. And usually these sub-alphas start from fifteen, not three or five! Remember: at any moment of the project, the number of external project roles is one more than the number of identified project roles — and this one will be an endless source of surprises.
Here are the states/milestones for external project roles (and remember that it could be about a newly created MVP, or some version/increment of the system, or even about a specific feature within the system as a "micro-project"):
- Recognized: external project roles are identified; the key ones are represented; responsibilities of role representatives/performers are defined.
- Represented: performers of external project roles have agreed to responsibility; representatives of some organizational units have been empowered; the approach to collaboration is agreed upon; work practices are supported and respected.
- Involved: representatives/performers of external project roles help the team; representatives respond to requests in a timely manner and offer solutions; changes are communicated promptly.
- In agreement: minimal expectations/preferences are agreed upon; representatives/performers of external project roles are satisfied with their involvement; the contribution of external project roles benefits the project; priorities are clear; perspectives of the team and external project roles are balanced.
- Satisfied for deployment: feedback from external project roles is available; the system is ready for deployment at its operation site.
- Satisfied in use: feedback on the use/operation of the system is accessible; the system meets expectations/preferences.
Project roles coincide with actors (specific organizational units that perform these roles) at the moment they are played. Individuals-actors can perform several roles in the project, and several people may play one role. The leading practice that catalyzes the cooperation of actors during the qualitative performance of their roles is leadership. People in the team should carry out leadership not only to establish cooperation within the team (and a team of one person — oneself, "organizing oneself," "being a leader of oneself," "working together/befriending with oneself," as well as teams of many people, and even teams of many large organizational units-companies) but also with the necessary representatives/performers of external project roles to involve the external individuals relative to the team in the project and assist in promoting all alphas of the project according to their states.
When documenting external project roles, it is a good idea to use a table from the "Systems Thinking" course; this table was presented when roles were discussed. Let's remind it:
Number of Role Role practice Role performer Role performer’s position Role performer’s organization Role performer’s skill in this role Subject of interest Preference Agent’s strategy
In addition, external project roles are not only taken from the supra-system to the target system but also from the supra-system in the creation chain. Moreover, they often include organizations in the creation chains because at some point in the creation chain, it doesn't matter to the team what happens there with this chain: "they are not members of our team, but interaction is necessary" — that’s it, these roles fall into "external project roles" since design is usually carried out not in the abstract but within the framework of the work of some team. And if the CEO considers all 8,000 people of some holding company "our team," then the team of some small project of five people in this holding will consider the roles of this CEO quite external (if they consider them at all).