Typically, project roles/stakeholders are concerned by a number of characteristics of systems and related projects—and these characteristics are called role/stakeholders concerns (less commonly, interest, sometimes even driver as “what is important”). Cost, performance, maintainability, system functions and features/opportunities, shelf life, security/safety, and so on can be a concern. Any characteristic of a system or project, typical of many projects or unique only to a particular project, can be a concern.
Usually there are a lot of projects associated with the system, not necessarily exactly one project in the sense of classical project management, the work of one team. In one project, the system can be conceived, in the second designed, in the third manufactured, operated in the fourth, then resold, continued in operation in the fifth, upgraded in the sixth, continued in operation in the seventh, and liquidated in the eighth. There can be a project’s roles in any of these projects. For example, we already consider the project roles of the people who will operate the system when we conceive and create it. If we make a video game, we take the role of the player into account right away, even though it may be many years before the game is released-and it is unclear who exactly will play this role, there could be millions of players in the future.
In systems thinking, we regularly think about the future “as if it already exists”, which is normal. To say that “I don’t know what the system will be, because the system does not yet exist” is ignoring the engineering experience of mankind. All systems projects start with the fact that the system does not yet exist, and they are already thinking about it!
Thinking about how (most importantly, by whom! By people in what roles!) the system will be operated, which does not yet exist, which is barely conceived—this is normal, it is just necessary, this is where you need to start thinking about the system at all! If the system will not be operated, then why make it at all! And if it will be operated, by whom, by what project roles/stakeholders? We do not need to specify the particular performer of the role, but the role itself should be specified! Roughly speaking, you have to tell everything about Prince Hamlet even before the performance, and it doesn’t matter who exactly will perform the role afterwards: it’s the role you care about, not the performer. Though the skill of the performer is important, yes. But it would be worse if it was the skill of the wrong role!
Different roles have different role preferences for concerns. If the common concern of buyer and seller project roles is price, then the buyer’s role preference is to minimize price, and the seller’s role preference is to maximize price. To realize/implement their concern preferences, project roles have some kind of activity-driven intention **—**and this is where people are usually very inventive, and can set in motion a completely unobvious chain of actions, even with strictly positive preferences (concern: headache, preference: no headache; intention: cut off head—no head, no headache). The intention may also include the involvement of other roles, which may involve some very different practices—and these other roles may be performed by the same actor/performer/collaborator, or by some very different people (and they may even get paid for it!). This finally confuses the situation, but the concepts of “role performer”, “role”, “concern”, “preference”, and “intention” should be enough to deal in detail with all sorts of situations involving people’s behavior in projects.
If having opposite preferences in the same concern roles are performed by the same person, this situation is called a “conflict of interest”; it is a very common situation (think of the saying “let the fox guard the henhouse”: the fox itself believes that he will balance his preferences for eating the chickens and for guarding the chickens from eating them by others. People on the outside will have a different opinion. The conflict of interest from inside the head of the bearer of this conflict is poorly visible, but well visible usually to other participants in the project. To himself, the person with the conflict of interest seems to be an expert, deeply familiar with his various roles, and therefore making “well-informed decisions”. But no, these decisions do not seem to other participants in the situation “balanced”).
The positivity of the project roles is not necessary. Just preferences “negative heroes” and “anti-clients” are counted in projects with the opposite sign—to prevent thieves from stealing, murderers from killing, terrorists from committing a terrorist attack.
Project roles are exactly the roles. John Doe plays the role of a husband in the project of one system, a buyer in the project associated with another system (and at this point he can both continue playing the role of a husband, if the purchase is associated with the role of a husband, and the husband can disappear for this time—just as Prince Hamlet disappears while the actor playing him plays the role of Otello in another play, or even just sleeps at home, taking a break from the theater), and a patient in the project associated with the third system.
These are activity roles; they are not “observers”, as in physics! Observers in physics do not change anything in the world, they may have a concern, but there is no preference and no activity-driven intention to realize that preference. They are simply noting facts. In this respect, “analysts” are usually like observers: they don’t need to do anything, they just need to understand something and prepare an "objective report. No preference (“objective”, exploratory view)—no activity-driven intention to change lives toward the realization of a preference. Do you want to make the role-player an analyst a real figure, just rename him an engineer, and he won’t start “to offer” something to the people taking responsibility, and “to decide”, to make engineering decisions, to take responsibility. Role the “understander for himself” becomes a project role, an activity role. You can call a role a project role, an activity role, a functional role, an organisational role—it doesn’t matter at all, they are all synonyms, it’s just that with these different words you will accentuate different shades of meaning. We will remind you of this synonymy more than once. If an “analyst” offers something as a recommendation—it is no longer an “analyst”, it is a “syntheticist”, a recommendation has to be created, this is not analytical work! Positions are often derived from their typical roles. If the position is “analyst”, don’t expect people in those positions to do synthesis work. If they do, it will be “in spite of”, in violation of culturally conditioned agreements. This is not to say that there is no such practice as “systems analysis”, but performing role “analyst” would better be assigned to the same person who does both system/architectural synthesis, and that person-engineer would have the authority and responsibility to make synthesis decisions, not just "responsibility and authority to check and understand. The activity-based approach: got it - now do it!
Don’t confuse positions and roles: a person in an engineering position can play the role of a manager all day long and vice versa. Job descriptions describe positions, but roles are described by the description of the practices they perform, which are usually handbooks of some discipline. According to what handbook does a person who is in an engineering position base his or her thinking on? If, according to the “operations management” handbook, he or she plays the role of operations manager, and the position will only be needed to get his paycheck in time from the administration’s point of view. Positions are essential when you are “measuring swords”: the power, the authority to dispose/direct your own and others’ work, equipment, and other resources. But if it’s a question of how exactly to put on one’s thinking cap, then “positions” become secondary, and there has to be an examination of roles. Roles think and act; positions only “exercise authority”!
If the person in the project/activity role does not like something in the system or the project that deals with this system, or, on the contrary, likes it (there is a concern in the system, and in this concern he has preferences)—he begins to do something, he does not just observe, he realizes his preferences, he has an activity-driven intention [1]. And if he does not do anything, he is simply ignored; he then has no role, no action that he performs in relation to the system or the project of its creation. If someone simply passes by the window of a design bureau, then he clearly plays no design role in the project on which that design bureau is working.
Usually people are engaged in some of their usual activities, and then another system appears (or can appear) in their life—to some people this system gives new opportunities (for example, users in project roles, or members of the development team who are excited about the new project as an opportunity to make money), to some people it hinders (and these people will play the role of competitors or supporters of some political or religious idea. No doubt they will actively play these roles and ingeniously implement their preferences!).
[1] Here we turn to the “pragmatic turn” in philosophy, Pragmatism (Stanford Encyclopedia of Philosophy)
*An excerpt from Systems Thinking course