Project 2012: Day 41
In last weeks CTO post we discussed complexity, and how as senior technologists it’s our role to deal with this complexity. One of the biggest areas you’ll find this complexity is in just how many systems there are to manage, and because of their interdependencies, who is responsible for any given system.
True Story: Back in the day I work in IT Support for Nokia in Camberley, just outside of London. There were two support teams, the R&D Team where I worked, and the Ops Team. The Ops Team were so named because they ostensibly had responsibility for the manufacturing plant, whereas the R&D Team as you’d expect, looked after our R&D facility.
Actually the demarcation had other nuances. E.g. the Ops Team looked after the network (then 10Base2), servers, & printers whilst we looked after devices, OS’s and Apps.
The issues that caused the most contention between the teams: Printing. Printing had an interdependency on the application, the desktop OS, the network, the server OS, and the printer. It was no-one’s responsibility, and it was everyone’s. The demarcation between the team made it easy to avoid finding the root cause.
I’ve remembered this lesson throughout my career, as an IT consultant and solution architect, a strategist, manager, and now CTO.
Fortunately the way to resolve complexities like this, and avoid teams spinning wheels, is relatively simple (although not necessarily easy). I use a tool called the RACI, or more correctly, the RASCI chart.
Here’s how it works:
For every component (process or system) of your architecture you allocated the person/group Responsible. However, you also identify who they’re Accountable to. Who they can call on for Support. Who they should Consult prior to doing anything, and who they should Inform of progress.
I commonly use a spreadsheet for the RASCI, as this allows you to make the chart visible with conditional formatting. This also allows you to pivot on people and see over and under allocation.
There are two ways that you can use the RASCI. The first is to list the systems/processes as rows in the first column, with the names of the individuals/groups as subsequent columns. Then use the letters RASCI at the appropriate intersecting cells. E.g.
The other way is to similarly list the systems etc. in the first column, but to have Responsible, Accountable, Support, Consult, Inform as the subsequent column headings.
Personally I prefer the 2nd approach as this is typically a smaller table, and clearer. Also this method allows you to:
- Put a conditional formatting on blank cells in the Responsible and Accountable columns. This makes it very easy to see if you have gaps.
- Filter on names in the responsible column to check for over-allocated resources
- Filter on the other columns to list the systems that people should be consulted on etc.
Guidelines
- Every system/process needs a person responsible and to whom they are accountable.
- Each system/process should have no more than one person responsible. I.e. if you have a double up, split the tasks onto two rows and allocate these to two separate individuals
- Wherever possible, use individual roles or peoples names. Only use groups in the Consult & Inform columns
Apply this to your scope of responsibility and be amazed at the clarity this provides. You’ll quickly identify the risks in your business, understand where the inefficiencies are, and help communicate responsibilities and accountabilities effectively. Both to your team, and other important stakeholders.
Such a simple tool. So underused.