In my last Column, “Large Scale Contracts” (www.bptrends.com/large-scale-contracts), I looked at a common set of business processes, with which many readers will be familiar – contracting for services. To be specific, I looked at large scale, high value contracts, such as those issued by public sector organizations for outsourcing of services over a long period. To develop, start, manage and end such contracts it is necessary to form collaborative teams in which each member brings to the table specific expertise. Such teams typically include a mixture of company staff from multiple departments, external consultants to provide specialist advice, and subcontractors to provide key operational services.
In other words, large-scale service contracting is done by virtual teams, and falls into the domain of Virtual Team Planning (VTP). VTP is an approach to process description, management and re-use that is specifically designed for collaborative work spanning multiple organizations. The relationship of VTP to other work management techniques is shown in Table 1.
In case you are not familiar with the acronym RACI, here is the Wikipedia description, somewhat simplified for clarity:
A RACI matrix … describes the participation by various roles in completing tasks or deliverables for a project or business process. It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes.
Those who do the work to achieve the task. There is at least one role with a participation type of responsible, although others can be delegated to assist in the work required.
The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible. In other words, an accountable must sign off (approve) work that responsible provides. There must be only one accountable specified for each task or deliverable.
Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication.
Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication.
Very often the role that is accountable for a task or deliverable may also be responsible for completing it (indicated on the matrix by the task or deliverable having a role accountable for it, but no role responsible for its completion, i.e. it is implied). Outside of this exception, it is generally recommended that each role in the project or process for each task receive, at most, just one of the participation types. Where more than one participation type is shown, this generally implies that participation has not yet been fully resolved, which can impede the value of this technique in clarifying the participation of each role on each task.
In other words, RACI helps you understand what different people are responsible for in a team. In my 25-year experience of designing and managing collaborative processes, RACI is a critical enabler of efficient, effective and successful collaboration.
RACI and VTP
RACI is a natural part of the VTP approach. VTP lets you describe collaborative work as Plans with a very simple structure, “Stage-Role-Activity-Deliverable”:
- Each Stage of a Plan represents a specific goal of the Plan, shared and agreed by the Roles (responsibilities) assigned to that Stage – in other words, guiding principles are fundamental to Plan structure and negotiated by those who help achieve them.
- Each Role in a Stage may, or may not, have Activities in the Stage. Effort can be specified for an Activity (which may produce deliverables) along with the Day Rate of the Role that carries it out, which provides Effort Cost (both total and remaining) for an Activity. Start Date and Deadline can also be specified for an Activity, which makes it possible for all concerned to see a timeline (GANTT/burn down) view of progress in real time.
- Each Activity may, or may not, produce Deliverables. Qualifying information can be attached to deliverables, such as Maximum Financial Impact, Likelihood and Importance. Maximum Financial Impact is multiplied by Likelihood to generate Expected Financial Impact, and Likelihood is multiplied by Importance (as per traditional risk management) to generate an Impact Score. Since Maximum Financial Impact may be negative, you can use deliverables to represent risks, issues and costs as well as benefits and revenues.
A key underlying principle of VTP is transparency. You can place boundaries around deliverables at multiple levels (to protect visibility of documents, for example), but the structure of Plans is open to all involved. This makes guiding principles and economic drivers clear to all concerned, and ensures that full status information is always up to date in real time.
VTP also helps you understand the different aspects of leadership that are key to success, by breaking it down into “Levels of Control”:
- Internal to work process
- Responsible (in RACI terms)
- Refines initial process
- Facilitates/monitors process and its evolution
- External to work process
- Accountable/Informed/Consulted (in RACI terms)
- Refines deliverables
- Defines key Roles/Interactions/Activities
- External to work process
- Overall sponsor
- Defines key deliverables/metrics
In practical terms, VTP is implemented as follows:
- Management control – managers create and manage one or many Plans representing projects, ventures, or other types of initiative:
- A Plan is made up of Stages, representing shared goals.
- Each Stage has Roles, representing responsibilities.
- A Role may have Activities, representing outcomes.
- An Activity may produce Deliverables to make the outcomes concrete.
- Executive control – product owners, stakeholder representatives or higher level managers use dashboards showing progress of multiple Plans to align multiple programmes of work towards organizational objectives (note that executive control may well be exerted by someone who is not technically an “executive” in organizational terms).
- Strategic control – executives use specific views taken from the above dashboards to make decisions on organizational objectives.
RACI just drops out for each Activity, without any extra work being necessary:
- Responsible – The Role to whom the Activity is assigned
- Accountable – The first Role in the Plan as a whole (typically played by the manager who created the Plan)
- Consulted – Roles Responsible for deliverables used as inputs to the Activity
- Informed – Other Roles in the same Stage as the Activity that are not Consulted
Further, a higher and equally critical level of RACI also drops out for the Plan as a whole:
- Responsible – The first Role in the Plan as a whole (typically played by the manager who created the Plan)
- Accountable – The higher level (Executive) manager to whom the Responsible manager reports
- Consulted – Roles Responsible for deliverables in the Plan as a whole
- Informed – Other Roles in the Plan
RACI and BPMN
By contrast, suppose you try to model collaborative work using a mainstream BPM approach – i.e., using the BPMN notation. How can you capture the critical RACI aspects for each Task?
Responsible is easy – that's the swimlane in which the Task sits. However:
- It is not possible to show who is Accountable
- It is very unclear who is Consulted, since inputs to the Task may be indirect – i.e., even if outputs from feeder Tasks are shown, the feeder Tasks may be much earlier in the flow or separated from the Task in question by intermediary Tasks
- The only way to show who is Informed is to create empty swimlanes, which just looks wrong.
With regard to the higher and equally critical level of RACI, for the process as a whole:
- It is not possible to show who is Responsible
- It may be possible to show who is Accountable
- Consulted is available only if every Task in the process has its full outputs explicitly shown, which is often not done
- It is not possible to show who is Informed.
What this boils down to is that BPMN is the wrong choice for modelling of collaborative processes, since the RACI matrix critical for success cannot be shown.
VTP was developed to solve a single problem. How can you make collaborative, cross-boundary work repeatable? Unless you do this, you can't make it efficient or effective. The other work management techniques shown in Table 1 have had enormous success in making routine work and a limited form of collaborative work (i.e., internal work based on creation of a document set) repeatable, but the vast amount of work that falls outside this scope is untouched by mainstream process and project notations and tools. In particular, techniques such as RACI for improving collaborative work that have been widely accepted cannot be integrated with process-based management without use of VTP.