Grid Position: Get your team RACIng (Part 1 of 2)

Inbox


To: Keith
From: Dennis
Subject: FWD: new address
I got an address update from a client at the general mailbox. Should this be Ellen's job to update the database?
—Dennis

To: Keith
From: Kathy
Subject: FW: Account Assistance
I occasionally receive these e-mails when someone can't log on to the website.  Should I send these to you now?
---------- Forwarded message ----------
...

Recently my e-mail inbox has received a nearly daily dose of messages like these. In my current engagement as interim CIO for a small service organization, my responsibilities vary widely, from the strategic—defining technology platform strategy, designing staffing structure and hiring and on-boarding permanent IT staff—to the mundane—ordering hardware, troubleshooting database glitches, and, in this case, restructuring responsibility for organizational data flow.

Whose Job Is It?

For a variety reasons, it simply wasn't clear in this organization who was responsible for what, even for routine, everyday tasks like updating contact information or dealing with customer account resets. Recent high staff turn-over in key administrative positions, which drained significant tacit knowledge from the organization, created part of the confusion. This was exacerbated by the lack of standard operating procedure documentation, the maintenance of which was not an organizational expectation. In addition, the creation of brand new positions that had not existed before, and the recent adoption of several new information systems, including the core enterprise database, added to the ambiguity, as any settled order that may have existed before had been disrupted.

I knew that these representative e-mail messages identifying this lack of clarity were just the tip of the iceberg. It wasn't just Ellen who needed to update the new address in the enterprise database, but also Mark in the billing system, Eric in the CRM, and Bob in the marketing platform. In fact, these updates should be made in three additional databases, since in this small organization, like many others, these systems weren't integrated. Moreover, the typical employee wasn't even fully aware of the data needs of his or her colleagues.

As a result, staff members were spending a lot of time just figuring out who should be working on routine requests. Unfortunately, this was mostly handled ad hoc, as the need arose, without thought to putting a system in place to capture commitments so that the next time the same question arose, there wouldn't need to be yet another discussion about responsibility. The upshot was a lot of time wasted and avoidable errors made. There was no way this organization could achieve high performance when it consistently misfired on routine matters. Granted, in this particular example, automated data exchange among key information systems would go a long way to increase organizational efficiency, but it would still not address the underlying problem of lack of defined responsibility, with more misfires being the inevitable consequence.

A Common Problem?

Too many organizations aren't "firing on all cylinders" because it's unclear who has responsibility for even routine work. This keeps them sputtering along in fits and starts with entirely avoidable consequences in lost productivity, lost revenue, frustrated employees, and alienated customers.

In many of these organizations, figuring out whose job something is something of a black art. Nearly every organization has position descriptions that one should think would answer this question. Usually, however, these job descriptions were written for a job posting to describe the job to potential candidates. Given that primary purpose, position descriptions are typically only updated when hiring somebody new and only written in enough detail to attract and screen candidates. With the speed at which business changes, that means they are almost immediately out of date. Further, for any moderately complex organization with interdependent workflows, typical job descriptions do not provide the level of specificity to be a sufficient guide to determine responsibility for work involving hand-offs among multiple positions.

Tune Up Time

The approach I took in this organization was to involve the stakeholders in building responsibility matrices, a method I've had success with in negotiating and apportioning responsibilities in past organizations in which I've worked. A responsibility matrix has the advantage of showing the interrelationship for work among positions at a glance. It reveals interdependencies and builds understanding about workflows that cross positional and departmental boundaries, something siloed job descriptions typically don't accomplish. Moreover, if constructed properly, a responsibility matrix can be easily converted into detailed position descriptions, providing both shared understanding and individual accountability. (In the next Process Pragmatist post, I'll present a method and a template for doing just this.)

RACIng Ahead

This approach is built on the RACI matrix, which codes responsibility in a grid. Typically, position titles are listed as column headers across the first row. Tasks, decisions, or in the variant I typically use, job duties, are listed one per row down the first column. In each cell, a code is recorded noting the type of involvement the given position has for the given task, decision, or duty.

The RACI acronym derives from the classic involvement types:
  • Responsible: performs the work ("the doer")
  • Accountable: approves the work ("the buck stops here" )
  • Consulted: input sought before/during work with 2-way communication ("in the loop")
  • Informed: kept up-to-date after work completed with 1-way communication ("in the picture")
By Rickysmithcmrp (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons
Example RACI chart

Matrix Mania

In this organization, I adapted the responsibility matrix for three applications: 
  1. Documenting cross-departmental workflow responsibilities.
  2. Defining high-level responsibilities for new positions.
  3. Creating detailed, cross-referenced job descriptions.

1. Cross-departmental workflow responsibility

For the workflow coordination issue highlighted in the e-mail messages at the beginning of this article, I built a responsibility matrix that identified specific workflow procedures. I entered procedures as questions surrounding responsibility arose. As a stakeholder group, we negotiated and assigned responsibility. To capture our work, I expanded the traditional RACI chart to include not only the procedure, but the Trigger, System, Documentation Link, and other Notes to build a shared reference table.

Workflow responsibility Matrix

Procedure System Trigger Pos. A Pos. B ... Notes Doc. Loc.
Create new employee accounts Active Directory HR provides hiring information R I
Disable departing employee accounts Active Directory CFO provides departure information R I
Create new constituent records CRM New inquiry received R
Update constituent contact information CRM Customer provides update R
Deactivate constituent records CRM Customer requests removal R

Key

Procedure Name of procedure (action - object)
System Primary system & module used in this procedure
Trigger Event or schedule prompting procedure execution

2. High-level position responsibilities

For the newly restructured IT positions I mentioned, we took a different approach from the traditional RACI matrix as a first pass. Because so much service and knowledge work is interdependent, I typically specify duties in detail to avoid misunderstandings. However, these were brand new positions, so we were starting from a somewhat ambiguous understanding of position boundaries. To ease into the process of negotiating those boundaries, I started at a more general level of describing the work and then, with the staff members, assigned involvements. Only then did we break each high level description down into process and procedure-level duties, repeating the exercise of assigning involvement.

For this first pass, we only assigned one involvement code: primary responsibility ("R"). Since we were dealing with positions with overlapping responsibilities but for different types of technical systems, I transformed the matrix to list high-level responsibilities described in terms of process areas and a list of systems. The process areas were entered one per row in the first column. Across the first row, I listed the type of system. In each cell, we entered a code for the position title which held the "R" for the corresponding process on the given system.

Process Area Production Systems Support Systems Infrastructure Systems
Policy Development Position A Position B Position A
Policy Enforcement Position A Position B Position C
User Training Position A Position B Position A
User Support Coordination Position C Position C Position C
User Support Level 2 Position A Position B Position C
Financial Management Position A Position A Position A
Vendor Management Position A Position B Position C
Asset Control Position C Position C Position C
Procurement Position A Position B Position C
Installation Position C Position B Position C
Administration Position A Position B Position C
Maintenance Position C Position B Position C
Enhancement Position A Position B Position C
Troubleshooting Position A Position B Position C
Repair Position C Position B Position C
Decommissioning Position A Position B Position C

Once that high-level understanding was achieved, we pursued a more detailed breakdown of duties in a more traditional format, as described next.

3. Detailed position descriptions

A useful variant of the RACI grid that I have used for the generation of position descriptions places one duty on each line, grouped together into functional roles.

Duty/RolePos. A   Pos. B   Pos. C
Role 1
Duty 1.1RSA
...ARB
Duty 1.NIRA
Role N
Duty N.1CSRA
Duty N.2ARCI

Coding

For the purpose of building position descriptions, I typically expand the number of involvement types to allow finer grained distinctions.

CodeInvolvementDefinition
RResponsibleperforms the work
BBackupperforms the work in the absence of the Responsible party (provides fail-over redundancy)
SSupportingassists Responsible party in performing work
AApprovingauthorizes and approves work, ultimately accountable
CConsultingprovides input before/during work
IInformednotified after a decision or action is taken

Many other useful variants provide additional alternatives codings that may be useful given the dynamics of different organizations.

Part 2 Preview

In the next Process Pragmatist post, I'll dive deep into #3 by presenting a step-by-step procedure for creating a responsibility matrix with a group of stakeholders and give away an accompanying tool that automatically generates position descriptions.


How do you keep your organization firing on all cylinders? Let me know what techniques you find effective for apportioning and communicating responsibility among team members using the Comments section below.

No comments:

Post a Comment