Role and stakeholder in Role play simulation

In the version 3 role play simulation (RPS) design worksheet, Roni pointed out the distinction between roles and stakeholders. At other occasions, people asked,

In designing RPS, should I use a generic title (such as managing director) or give the role a name, e.g. Mr. Wealth Goldstein?

Any answer to this question has to meet the design objective? What are the purposes of the RPS and who are the target players (or learners) of the RPS?

The world is never a single dimension. Even a really elementary class of business school, students should be aware that a CEO is a human. Beyond the work place, s/he, like everyone else, is faced with other ups and downs in life - marriage problems, family commitments, health and so on. CEO also relaxes and goes to pub with colleagues. CEO also builds friendship, beyond the professional encounters at the workplace. By giving a role a proper name, interactions among persona in the RPS are more realistic and potentially have more learning opportunities to be discovered and leveraged upon.

This is this distinction to lead us to develop the independent concepts of "stakeholders" and "persona". In our terminology, stakeholders are viewpoints from a single professional related point of view. CEO, secretary, president, activists in Green movement and factory works are stakeholder view points. These present a set of public and private agenda, with influences from the circumstances in the scenario. Roles, as in a story, are characters in the RPS.

In order to create an effective role play, these stakeholder viewpoints are represented by personals in the role play (or simply roles). Roles have additional characteristics beyond representing the stakeholder viewpoints. Roles live in the RPS. Roles have personality. Roles has "fresh and blood".

Another important consequence of introducing this separation is that when we create a RPS, we concentrated on articulating the stakeholders viewpoint at an earlier stage, select those most relevant to learning objectives and create the scenario around typical issues. If we stop here, the RPS will be fairly "blend". By combining several stakeholders into a role, or by using several roles to represent a stakeholder viewpoint, the RPS sudden becomes much more playable. Players may have to fight the conflicting issues represented by the multiple stakeholders represented by the role, or need to align or fight for "stage time" between other roles who have similar stakeholder viewpoints. As the players bring in their previous personal experiences, the role play will develop differently at each run. Moderating/assessing a role play is not, and have never been, the same as the tedious process of reading the almost the same poorly written exposition of the same viewpoints as many times as the number of students in your class. AND the players learn better in authentic situation too.

One additional benefit of this design is the potential of creating roles with different levels of "importance": must have, critical, good to have and fillers. When combined with a flexible team size structure, this multiple levels of importance of roles created a large solution space for allocation of players into roles. The software, hence, can support the tedious task of allocating players into roles. This reduces a significant work load at the beginning phase on the RPS and will let teachers/instructors concentrate on their real job of leading the learners through the experience.