External and internal roles
Conceptually, functional/project/stakeholder roles can be divided into external and internal in relation to the team of engineers directly creating the system (with teams of creators throughout the creation process being more complex, as each time it is necessary to understand which project is exactly referred to).
Internal roles are the roles of the project team (classic engineers or not so classic ones - doctors, teachers, various managerial specializations, marketers, etc.), and external roles are all the others that are not part of the project team but have an influence on the project or are influenced by it. A typical external role is "user", who would rather be called by his role in his domain - player, patient, eater, as well as payer, contractor, inspector, and so on.
A good analysis of external roles in large-scale sales (for example, engineering equipment - unlike retail sales of toy machines) is given in Neil Rackham's book "Major Sales Strategy"[1]. In this already very old (1989) book, it is stated that in a large organization, behind the simple word "client" there may be various roles - and each of them needs to be treated differently. So, stating "our clients are clinics" for more than thirty years is not the best practice. In real life within this clinic, many different roles are revealed - doctor, nurse, manager, IT specialist (and a few more different ones!), lab technician, patient, and usually invisible investor-owner. When saying "our clients are clinics", whom did you have in mind? For each of them, different questions need to be answered, materials presented at different levels of detail, the system praised differently, competition approached differently, negotiations conducted differently at different stages of the sale. Therefore, try to refer to external roles not in relation to the team (here a totally general word will come out by default "client", like "all these outside people"), but how they are called in their activities, in their teams.
We recommend abstaining from using certain words that are commonly used in such cases, and which hide entire bundles of roles with very different role preferences in various important characteristics of systems:
- User - call them as they call themselves in the project roles of their projects. If it is about a game, it is a "player". If it is corporate software, there are usually many different people involved, playing various roles - and for these different roles, one will have to consider very different important characteristics, they cannot be united under the term "user". The key here is that the role is named after the key method of work performed by the role holder. If the role involves playing computer games - it's a player, if it involves medical care - it's a doctor, if it involves financial matters - it's a financial specialist. A simple check: does the name contain a specific domain, a method specialization? Not just "user", because for the "user" the domain is unclear, the method is not applied from a specific domain, but just a general method, it is too abstract for productive discussions! Ground yourself! The words should sound like they come from a specific domain, not general methodological terms!
- Buyer - usually there is a beneficiary (someone who benefits from the purchase), purchaser (a legal aspect of the agreement), payer, trusted person (e.g., a courier receiving the purchase), expert (someone who selects the product) and so on. All these roles need to be considered in various capacities, taking into account their different role interests in various important characteristics.
... You get the idea. The words "customer" or "client" are also suspicious - often there are people with conflicting preferences behind those terms. A financial client wants the lowest price and therefore minimal features, while an engineering client wants maximum features and therefore maximum price - and they have conflicting preferences on price and features. Combining them under "client" will not provide much that can be done with this information, each aspect needs to be considered separately in the project.
External people-in-roles/stakeholders are often inaccessible. For instance, if you have 10 thousand players of your mobile game, each with the role "player". But until the game program is written and nobody is playing the game yet, then there are no players. Remember: if someone, let's say "John Doe"::organizational capability/ "constructive object", is not playing a hobbit::role/ "functional object", then there is no hobbit in the physical world at that moment! In such cases, when "the players' roles do not exist, no one to ask, they will be there at some point," external roles are assigned to be represented by team members.
A quarter of a century ago, the persona method, described in Alan Cooper's book "Inmates Are Running the Asylum"[2] in 1999 was used for this purpose. Personas were modeled instead of roles, focusing on agents/actors playing the roles - characters/persons (persona). This method suggested creating a typical portrait of a product user and having someone from the team play that role, like in a theater. For example, "a single mother, 32 years old, living on the outskirts of a small town, using her tablet for household finances". However, in recent years, there has been criticism of the persona method, as its focus was not on modeling the role and work methods of the role to identify role interests, but on modeling non-essential characteristics of the agent performer, weakly related to the essence of the matter, i.e., to the subject of interest of the person-in-role. This is a typical mistake: dealing with the agent, rather than identifying the working method of the agent, his role, interests of the role.
It's as if recommending to describe Hamlet in more detail in terms of weight, height, eating habits, clothing preferences (thus describing not the role but an agent who could play Hamlet) and hoping that this would provide a more accurate answer about his role preferences when he asks his role question "to be or not to be". Clearly, this is psychologically convenient for the team. It is crucial that the project team develops the system not as one convenient "for themselves," because this will lead to a conflict of interests - the system that is easier to develop will be convenient for them, but as one that is convenient "for others." Developing a system for a "broad Hamlet" is much better than for "me, although I have never been Hamlet, but I am ready to portray him because I understand." However, from the perspective of modeling the role interests, this is a dead-end, although to succeed, the system must satisfy precisely the role interests!
It is better to abstract from the fact that "a single mother lives on the outskirts of a small town" and instead of "user," call her "home financial manager" - and this will filter out all the areas of interest of the single mother, all the areas of interest of a resident of a small town, which is correct, they will only distract from what is important. If there are any specific characteristics of the performer/actor to consider, they should be treated as features of another role of that actor, not the agent-actor itself. For instance, for individuals with poor eyesight (important characteristic: accessibility, interface accessibility), it is necessary to provide a large font in the interface (preference). However, it is understood that the roles "home financial manager" and "poor eyesight" have different important characteristics, and these characteristics will be reflected in the functionality and design of the system differently.
There might even be a conflict of interest identified (different preferences on one subject of interest/important characteristic for one performer of the role). A home financial manager wants to see a lot at once on a small screen, while someone with poor eyesight needs a large font - maybe not everything fits on the screen with this font, scrolling might not be convenient, but at least everything is visible! What will be the font size in the end - for the visually impaired, or for the home financial manager? Who will win in this conflict of interests? Various solutions can now be proposed. For example, a screen magnifier for the font (many items on the screen, but the magnifier allows something to be seen in a normal size for the eyes), adjustable font size (each home financial manager and visually impaired performer of the role will adjust the font size to their own preference), etc.
All modern methods of modeling external roles in a project (e.g., the Jobs To Be Done method[3]) try to simultaneously improve the accuracy of substantive role and role work method modeling to precisely define role interests and preferences (necessary success, so satisfying those preferences - is crucial), as well as enhance the psychological credibility of this representation for the project team, because it is psychologically easier to "help a person" rather than "satisfy what is described by the model." For this, various experts in the field are invited to personal meetings, focus groups are organized for potential performers of the required external role, and team members themselves try to gain the necessary experience and play the role of external roles.
Methodologies for modeling and "personal representation by live individuals" of various external roles in the project are discussed during the development of the system usage concept (description of the functionality of such a system that brings benefit during its operation). The development of the system usage concept is conducted with methods that involve developers::role. In addition to the usage concept, developers/designers::role also develop the system concept, perform design tasks with a level of detail sufficient for manufacturing, produce the system (using the internal production platform, the "factory," the conveyor built by the engineers of this platform). Developers/designers::role do a lot more, and they are usually considered the main actors concerned with satisfying the interests of external project roles, especially user roles (as mentioned before, there can be multiple roles, named more specifically after their domain).
Nevertheless, not only developers are concerned with satisfying the interests of external roles, but all team roles participating in the project. For example, architects::role also model external project roles, as they are concerned about satisfying their interests in terms of specific architectural characteristics that developers may overlook. For example, developers of a server system can be concerned about certain product features that require too much computing power for one "player," the task of an architect is to remember that there will be many such "players". Therefore, the architect goes to model what he is told by the marketing department (expecting a hundred, a hundred thousand, or a hundred million "players"). Subsequently, the architect and developers will be engaged in productive conflict, and developers are likely to incur a technical (architectural) debt, i.e., work that they need to do to satisfy the interests of the players not only in terms of functionality but also in terms of the players' (the "player base's") interests in the accessibility and performance of the servers (these "accessibility" and "performance" are architectural characteristics), and the representative of the "player base" (all players in general, different from a single player and representing the clientele) will be the marketing department. The architect is likely to consider developers as an external project role, the team manager considers developers and architects (or a whole team of architects) to be full-fledged team members.
A telling example is a team of engineers who suddenly requested to include a local lawyer in the team. The motive: in negotiations, the agent playing the role of a lawyer acted as if he were working against the team of engineers, rather than being a team member! The team's calculation: after formally including the lawyer as a team member, he will primarily consider the interests of the engineers, not the interests of some other "supervisors" or whoever he considers, representing and advancing the interests of the engineers against these "supervisors," ignoring the engineers' interests.
"- How much is two times two? - Are we buying or selling?" This should always be kept in mind. In the web of organizational relationships, it is easy to get tangled without understanding (which is an emphasis on modeling, documented modeling) work methods, roles, subjects of interest, and interests. Who does::agent represents in what::agent interests are the main concern.
What turns out to be critical is not so much the external or internal aspect, but the thorough documentation of all identified subjects of interest, followed by the fulfillment of tasks to coordinate and satisfy the interests based on this list of subjects of interest as a checklist - and all the while bearing in mind that interests arise from culturally conditioned roles, not the specific agents who perform the roles, many interests will not be publicly stated but may appear in private negotiations (and this is good, as if everyone talks to everyone, it is poor architecture, poor project modularity, there is more on this in the "Systems Engineering" and "System Management" courses).
In any case, missing both external and internal roles always need to be played out somehow in the project, organized by competent individuals with qualifications, not random available performers of these roles, otherwise the success of the system will be in question. It is understood that the success of the system is determined by the agreement of roles (something about the Danish kingdom, "Prince Hamlet" understands), and not the agreement of role performers (about the Danish kingdom Vasya Pupkin, who was asked to play Prince Hamlet, knows nothing)!
If the role of a music connoisseur is performed by a deaf person, he will perform the role poorly - and his agreement with a piece of music will mean nothing and guarantee no success for the music. If a professional in Operational Management performs the role of an engineer-architect, his agreement with the system structure means a lot when it comes to administration but means nothing in system engineering - as the agreement of a qualified role actor in systems engineering is needed. The agreement of an experienced performer of the operation manager role, masquerading as an engineer in this case, does not count in his favor.
The failures/unsuccess of many projects are often explained by solutions being made by inexperienced performers of professional roles (though they have full authority to make decisions about any role, this explains what happens, but does not justify it).
If someone finds it difficult to imagine the abstract "Prince Hamlet" (yet this is necessary), they should at least come up with a person: imagine a typical performer of this role. In any case, avoid thinking that all people-in-roles are similar to yourself-in-role. All people-in-roles are unique, and experienced role performers have a lot of experience playing the corresponding role, plus they often have more time to perform their role in your project than you - unless you are a professional in that role. However, if you are a developer, your chances of performing someone else's external role well are close to zero (the best model of a cat is another cat, preferably the same one, get someone with similar mastery, not broad knowledge about the mastery). Special efforts need to be made to represent external roles in the project: conduct focus groups, talk to stakeholders, study the literature, and so on.
The same can be said about you: within your traditional roles, in which you have mastery, you will have more time to perform them and more experience in performing those roles than the performers of other roles. If it's not the case, and in your project "bakers bake pies, and cobblers make boots," your project is in danger, and this danger originates from you.
A boss is not a role, it is authority to make decisions. A decision will be taken, but will be bad if the boss lacks the mastery in the method of role work. Check the boss's mastery in performing any activity, in engaging if not in the position, then at least in a passing engagement in the role, to demonstrate mastery. Ask them simple check questions (e.g., "by which method did you reach this result? In which textbook can I find the reasoning that led you to this decision?"). Of course, you will have to decide: do you love the project more or the boss. If you love the boss more, then well, with the project, which will be ruined due to role incompetence/unqualification of the boss-agent (an agent who holds an organizational position).
Hope that helps! Let me know if you need further clarification or assistance.