Outline:

What is Role Modeling?

Role Modeling (RM) is a business engineering technique which leads to a responsive, goal-oriented organizational structure and effective work processes. It provides

RM provides a simple but powerful paradigm for thinking about how an enterprise works. It differs from other business engineering techniques in several significant ways:

Role Modeling describes the roles involved in performing the work of the organization. A role has a cohesive set of responsibilities; a purpose for existing. A Role Model shows how roles collaborate to fulfill their responsibilities.

A role may be filled by a person, group, organization, team, or even an automated system, and each of those entities may fill many roles. In fact, a role may be filled by another role. RM draws a major part of its power by separating the "what" of a role from "who" is filling the role at any particular point in time. That separation allows teams to come together to discover the nature of the work which must be done to meet the demands placed upon them by their sponsors, without regard to organizational turf issues, and then figure out how the roles must be filled.

For example, an application development group and a data management group were faced with complaints that the results presented to the customer were not based on the correct source data the customer assumed it to be. Each group thought that the other group was responsible for quality assurance. In building their role model they easily agreed on the need for a quality assurance role. As they fleshed out the responsibilities of that role it became clear that it had to be filled by a team with representation from both organizations. The team was then further described in terms of the roles (and responsibilities) of its members.

A team of the sort just described is a virtual team; a cross-organizational grouping of individuals for a common purpose. Most large organizations depend heavily on virtual teams, but their existence is largely ignored in formal planning and descriptions of organization structure and accountability. RM gives virtual teams their due. It supports (and empowers) the full richness of cross-organizational interaction and collaboration.

The lines connecting roles in a role model represent collaborations; dependencies of one role upon another. All of the roles connected to a role by lines, either in or out, represent the stakeholders of that role. The stakeholders of a role naturally form a virtual team which is responsible for determining the fate of the role. Any changes to the role's responsibilities are made according to the needs and timing of the stakeholders. Thus role models have built within them the capacity to describe and account for change. Furthermore, roles which may seem distant on ordinary organization charts are seen to be quite close if, in fact, they interact operationally. The impact of a change and the scope of approval needed to institute it can be negotiated directly from the model. We use the term responsibility domain when concentrating on responsibility for defining how and by whom a role is assisgned responsibilities.

How are Role Models Developed?

The Problem Statement

Role models are initially developed in facilitated sessions by representatives of a responsibility domain. When starting from scratch, the participants first identify the domain by developing a problem statement. The problem statement gives the reason the domain exists and also bounds the modeling session; a model is sufficiently detailed and correct when it meets the completion criteria set forth in the problem statement. Any time the model needs to be updated the problem statement should be revisited. Updates can frequently be undertaken without the need for a facilitator.

Use Cases

Once the problem statement is in hand, the participants brainstorm the names of use cases which characterize the operational requirements of the domain. A use case is simply an example of an event or trigger which the domain must handle, together with the expected outcome and any preconditions for the example. For instance, the use case "In-stock order" may be triggered by the event "Customer phones a request for two blue gizmos", with the precondition that enough gizmos are on hand and an expected outcome that the customer will receive the gizmos within two days. Use cases are highly specific, not generic, so that they can provide specific intuition as to how things must work. At this stage, only the name of the use case is needed.

Brainstorming is kept brief. Usually dozens of use cases will be identified, but there is no need to ensure complete coverage at this time. Just naming use cases helps the participants understand the scope of the problem domain as seen by other members of the team.

RRC Cards

The participants then brainstorm the names of roles which may be of interest to the domain. As with use cases, neither precision nor complete coverage is necessary.

An index card is created for each role. As the role names are read off, if anyone does not have a notion of what the role represents, the team pauses to develop a simple statement of the overarching responsibility of the role, and places it on the card. (Note that if a role isn't questioned at this stage, different participants may be making different assumptions about its meaning. That ís perfectly OK. The process is self-correcting.)

The cards, known as RRC cards, for Role, Responsibilities and Collaborators, are dealt out to the participants, with no particular concern for aligning roles with the participants who might eventually fill them.

Role Playing

The participants then pick a use case to start with. The first use case should be one that represents a   "main path" responsibility of the domain, such as filling an order. The definition of the use case is fleshed out in some detail, including clear statements for the trigger, preconditions and expected outcome. The preconditions for this first case should be selected to keep the case simple, avoiding exceptional conditions and unusual events.

Then the fun begins. The use case trigger is read and the facilitator asks which role handles the trigger. In the case of a phone order, for example, the sales associate role may take the call. The participant holding the sales associate RRC card identifies the role and checks that the card includes a responsibility empowering or requiring it to take calls. If that responsibility is not clearly within the scope noted thus far on the card, a responsibility is added to the card. The cardholder then determines what role (or roles) must be triggered next in order for its responsibility to be met. That role or roles would then be listed in a "Collaborators" column on the card and the collaborator(s) would be triggered.

Participants role-play the roles of the cards they hold, illustrating how the roles collaborate to meet the needs of the use case. In the process, they discover the need for new roles, and ways to improve, refine or replace the roles theyíve identified thus far. They mark up the RRC cards freely, tearing up cards which become too complicated and replacing them with several simpler ones as they gain deeper insights into the task at hand.

Iteration

In practice, this process of role playing, discovery, and design proceeds iteratively through several stages of formality. At first the participants just talk it through, holding up their cards as they say what they'd do, without bothering to actually write on the cards. They might also go to a whiteboard and quickly sketch out a diagram of the sequence of roles and their interactions. As they become satisfied with their design they update their cards.

Scenarios

The entire sequence of steps from the use case's initial trigger to the desired outcome is called a scenario. Once the participants are happy with the way their roles collaborate to meet the needs of the use case, they make a clean pass through the role play while a person designated as a scribe captures the scenario in a scenario log.

Ta Da!

They now have:

Incremental Enhancement

Now it is time to test the model with another use case. You might think that another use case will generate an entirely different model, with potentially no resemblance to the one developed thus far. But that is where this technique differs so fundamentally from conventional process modeling. RM focuses on roles, not tasks. The roles must be designed so that they are up to all of the tasks their domain must handle. Brainstorming roles generally gives an amazingly good first cut at a stable model. As additional use cases are tried, the model will get richer and more refined. The roles, however, will tend to stabilize, with fewer modifications needed as each new case is tested.

To achieve that sort of stable design, the participants go through a process which builds their confidence in the model. The first use case gave them a rough idea of how the model, and the distribution of roles and responsibilities it conveys, could meet the needs of a "bread & butter" use case. The exercise undoubtedly raised as many questions as it answered. Their focus now shifts to gaining a deeper understanding of how the model can really support their needs. They discuss which kinds of problems the model seems to leave unsolved and pick (or formulate) a use case which is likely to trigger one of the most fundamental problems or areas of least confidence. They then apply that use case's trigger and trace its effects through the model. Just as they did in their initial role-playing, they repair their model as they encounter problems and discover ways to handle them. Once satisfied, they document the scenario associated with the new use case. If the changes in the model affect the way an earlier use case was handled they also update its scenario.

The process of testing additional use cases and refining the model continues iteratively until the model is rich and stable enough to meet the needs of the problem statement.

Team building

The somewhat mechanical description we've provided of role modeling thus far may give you the impression that this is a coldly analytical process. Nothing could (or should) be farther from the truth. In practice, role modeling is not nearly as dispassionate as the description above may imply. The participants are keenly invested in the outcome of the model and the way in which its roles and responsibilities will serve their own organizational and personal goals and ambitions. They are constantly checking that the responsibilities invested in a role are realistically achievable, given the charter of the role and the actual information, resources and collaborative commitments the model shows the role will have available to it. The modeling formalism does tend to keep focus on the nature of the work and the need for collaboration, rather than issues of personality. It builds trust through understanding of each participantís perspective and needs.

Taming Complexity

What keeps this from becoming horribly complicated? Several things:

The Bigger Picture

An RM engagement might typically involve a few half-day sessions a week for several weeks. The time between sessions is used to great advantage by the participants to check with their constituencies and ensure good communication, feedback and involvement. Most of the mechanics of documentation and consistency checking are also best handled between sessions, so that they don't impede the creative processes and enthusiasm generated during a session.

For many applications, a word processing application such as Microsoft Word can be used to document the content of the RRC cards, the use cases and the scenarios. As a model grows, Roleware^tm documentation aids and tools can be introduced. Roleware^tm eases the development, dissemination, and maintenance of integrated models.

Models developed independently by different teams can be reconciled by forming a team responsible for each area of overlap. The issues they have in common define their responsibility domain. They can proceed to model it, treating the originally-overlapping domains as their sponsors and negotiating solutions which best meet the needs of all stakeholders. That is how role modeling grows from the bottom, top and middle to eventually form a unified picture of an enterprise, its organizations, and its processes.

[ Welcome ] [ Up ]

For further information send mail to info@rolemodeling.com
If you havequestions or comments about this web site please submit a  feedback form or send mail to webmaster@rolemodeling.com.