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?
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.
Tune Up Time
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|
- 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|
|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
|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|
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|
For the purpose of building position descriptions, I typically expand the number of involvement types to allow finer grained distinctions.
|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|
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.