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?
—DennisTo: 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
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”)
Example RACI chart |
Matrix Mania
- Documenting cross-departmental workflow responsibilities.
- Defining high-level responsibilities for new positions.
- Creating detailed, cross-referenced job descriptions.
1. Cross-departmental workflow responsibility
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.
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/Role | Pos. A | Pos. B | Pos. C |
---|---|---|---|
Role 1 | |||
Duty 1.1 | R | S | A |
… | A | R | B |
Duty 1.N | I | R | A |
Role N | |||
Duty N.1 | CS | R | A |
Duty N.2 | AR | C | I |
Coding
For the purpose of building position descriptions, I typically expand the number of involvement types to allow finer grained distinctions.
Code | Involvement | Definition |
---|---|---|
R | Responsible | performs the work |
B | Backup | performs the work in the absence of the Responsible party (provides fail-over redundancy) |
S | Supporting | assists Responsible party in performing work |
A | Approving | authorizes and approves work, ultimately accountable |
C | Consulting | provides input before/during work |
I | Informed | notified 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 Dispatch, 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.
Recent Posts
How Small Businesses Can Use Business Process Management Software?
Introduction Imagine a tool that transforms chaos into order, a magic wand for your small business's processes. That's Business Process [...]
Continuity of Operations: Business Continuity Planning for Small and Medium Businesses
Continuity of Operations Planning (COOP) stands as a strategic endeavor in organizational settings, aimed at guaranteeing the seamless execution of [...]
Common Mistakes to Avoid When Developing Standard Operating Procedures
Introduction Standard Operating Procedures (SOPs) are internal company documents that outline instructions for employees to carry out various tasks [...]