How to describe roles in a process-oriented way

AKV + VMI = combine activities and roles from different perspectives

Both AKV and VMI link activities and roles — i.e. what needs to be done with who does it. But the approach of both methods differs from one another: The AKV logic starts with the role and assigns activities to it; the VMI logic starts from the activity and assigns the roles to it.

When (first) describing activities, both logics provide important impulses from different perspectives:

• The AKV logic starts from the questions: What activities does the role carry out? What powers does the role have? What outcome is the role accountable for?

• The VMI logic starts from the questions: Who is responsible for the process step? Who is involved in the implementation? And who should be informed about this?

Since the logics focus on different questions, it is worthwhile to consider both equally when creating a process.

Describe roles using an AKV matrix

An AKV matrix is often used to describe roles. The acronym AKV stands for tasks, competencies, responsibility. How are these elements to be understood?

Tasks are the recurring activities that a role performs. Competencies, on the other hand, can be understood as two different things. On the one hand, the question of the competencies of a role can be aimed at its powers. On the other hand, competencies can mean the skills that a role owner must have in order to fulfill the role.

Competence as a skill or authority

Competencies are often found as skills in job advertisements. These not only describe what the person does and which area they are responsible for, but also what they should be able to do about it.

This type of description of competencies tends to come in the form of a reformulated task list. This can be illustrated using the role of the bus driver as an example: In order to be able to perform his task, the bus driver must be able to drive a bus. The example shows that understanding competencies as abilities only offers added value if the skills are linked to measurable criteria. In this example, this could be a corresponding driver's license.

For everyday working life, describing competencies as powers has a clear advantage: It makes clear what decisions a role owner can make. Ideally, clear powers empower a role to achieve the goals that are their responsibility.

Responsibility and authority must go hand in hand

The powers of a role must always match its responsibilities. Let us imagine the role of the personnel developer, who is responsible for training employees. If it does not have the authority to register employees for training measures and to spend the necessary funds, it will never be able to live up to its formal responsibility in reality.

Define responsibilities with a VMI matrix

Another important concept is that of the VMI matrix. The acronym VMI stands for responsible, involved and to inform. In English, we also speak of RSI — short for responsibilities, support, information.

VMI in project and process management

In project management in particular, the VMI matrix is used to clearly assign responsibilities for individual work packages and tasks. Ideally, the VMI matrix is continuously updated as the project progresses, so that all project participants are constantly aware of who is responsible for which tasks. A similar goal is being pursued with the use of the VMI concept as part of process management. However, VMI is rarely consciously used as a tool in the context of process management; however, it is often used implicitly.

As a reminder, the changing responsibility for carrying out individual process steps is an essential core characteristic of processes. In addition to this responsibility (V), the description of process steps is often accompanied by information about who is involved in carrying out the process step (M) and ideally also who needs to be informed about the implementation (I). It is precisely this — often neglected — information that enables a smooth process flow across all interfaces.

In both project and process management, VMI describes a type of involvement that makes it clear who is responsible for a task, who is involved and who needs to be informed.

All roles contribute equally to success

Whether a person is responsible, involved, or informed says nothing about how important the role is to the process. Another example to illustrate: In a production plant, the responsible production employee manufactured the ordered parts in accordance with the process description and stored them in the intended storage location. They are now lying there, first for one day, then for two days, then five days — because no one has informed logistics.

A successfully completed process step therefore does not necessarily mean that the entire process is successful — especially for processes that are only carried out rarely and that are not automated. In order for such a process to be carried out successfully, the person responsible for the subsequent step must be actively informed about the implementation of the previous process step.

As a rule of thumb, the more important it is that someone is informed that a process step has been carried out and the less automated such notification is, the more clearly this should be documented in the process description. This can even go so far that informing another role is listed as a separate process step.

Task lists are not suitable as role descriptions

In practice, some organizations use a lot of energy and resources to describe roles. If there are still ambiguities among employees, they are astonished: Who is now responsible for what exactly and why are the parts produced on the farm again for days without anyone from the logistics department being informed? How could this happen when the tasks and responsibilities can be clearly found in the role descriptions?

The reason for this is often a lack of process orientation in role descriptions. In fact, various tasks are collected in these. However, these tasks have no comprehensible connection to the tasks of other roles. Instead of the role description, a decontextualized task list was created, which does not clearly define which steps exactly in which processes and which roles should be informed about them.

6 steps for a process-oriented role description

In order to ensure transparency about the relationships between tasks, even within role descriptions, tasks should be described as process-oriented as possible. Since process descriptions contain a variety of activities, which are also listed in role descriptions, the following procedure is useful in practice to record roles:

1) Write down what is being done

2) Put activities in the right order

3) Assigning responsibilities

4) Determine the type of involvement, i.e. who is involved or needs to be informed

5) Optional: include informing specific roles as an independent process step

6) Create a separate role description for relevant roles

This procedure creates role descriptions that are closely based on the day-to-day activities of role owners. Role and process descriptions are moving closer together and ensure clear tasks and responsibilities.

One major challenge is to identify whether it is necessary to create a separate role description. It can help to ask yourself whether the role must be endowed with certain powers that are not apparent in the process. In technical roles, authorizations and powers are often an essential part of the role title.

Regularly reconcile processes and roles

Processes and roles change over time. New process steps are added, others disappear, and the way a process step is carried out changes. Role owners get new tasks, other tasks change responsibilities.

Describing roles in a process-oriented manner right from the start helps to avoid contradictions — especially in the job description. In addition, role descriptions and process descriptions should be continuously compared with each other. This is the only way to prevent conflicting task descriptions and responsibilities from developing over time — and employees having to decide whether they stick to either the role description or the process description.
----
Read part I here >> What roles are there in process management and why they are so important