Laying the Groundwork for a Service Management Approach (Part 3 of 6)
Part 1 of this series introduced a methodology for fostering a service management approach at the technical team level and covered the first step in this methodology – defining the team’s mission. Part 2 went over the second step – defining the activities that must be performed to accomplish the mission. This entry covers the third step – defining the roles that people fill to perform the activities. Additionally, we'll then combine the activities defined in the previous step with the roles defined in this step to come up with a RACI matrix.
Figure 1 - approach to providing basic IT organizational documentation
Roles
Defining roles within a team can be trickier than you might think, especially within the world of government and military. Many organizations in which I have worked have not had occasion to view their team members from this particular perspective, seeing people instead through the lens of job titles, statuses gained from years of service, membership in privileged groups (“she’s a domain admin”), or contract labor categories.
For our purposes, however, we need to view the team members with an eye towards the activities defined in the previous step of this exercise. If different team members perform different activities, or perform the same activity as others but at a higher administrative level or greater boundary, we have different roles. The roles *may* correspond to a job title, but may not – two people with different corporate titles may have identical job responsibilities and therefore occupy the same role. A role may certainly be occupied by only a single person – a manager, for instance.
As a consultant, deriving the list of roles is a matter of interview – usually with the manager or team lead. When I do this, I first go over what a role is – a person or persons that perform(s) (or at least can perform) identical activities. Then I ask them to provide a list of roles and give them a leading idea based on what I’ve seen so far (“Take Sam, for instance – would we call him a senior firewall administrator?”). Starting the talk this way sparks thought – if Sam is a firewall admin, then there are people who are not firewall admins – what do we call them? And if Sam is a “senior” firewall admin, then there must be “junior” ones. Before you know it, you’ve got a list of roles.
The last thing to do is to go through the team members one by one and assign them to roles. This important exercise often reveals the existence of additional roles. I can’t tell you how many times it has come out at this stage that so-and-so actually has root privileges, while no one else does, making so-and-so something beyond a senior admin. The conversation during this phase is something like “So Pat has the exact same level of access and responsibilities as Sam, right? Okay - we'll plug him into this role.”
And that’s it for the roles! It is useful to take notes related to the description of these roles and the things that differentiate them, as this sort of text may go into a document that spells out the roles, if the client wishes to receive the information in that way.
One thing of note is that the conversations that take place during this stage lend themselves very well to a role-based administration discussion, and possibly just-in-time administration. See “ITIL and the DoD RMF Part 3 or 3” for a bit more on that topic. Now let's combine the activities and roles into a RACI matrix.
A RACI matrix gets its name from the four letters - Responsible, Accountable, Consulted, and Informed - and is a tool used to identify who does what within an organization or (more commonly) a process. Information about these is readily available, and I will not go into more detail about what they are here.
Developing a RACI is a foundational skill for any process consultant, and creating one requires a high degree of interaction between the consultant and the client. I have found the greatest success by scheduling a session with the client to go through an already-created RACI that can be analyzed line-by-line and modified/approved. Putting a blank RACI in front of a client and trying to fill it in from scratch is not the best use of your client's time (or yours!).
The roles part of the RACI should already be done, as the client has already worked with you to define these. That leaves just two things - the activities and the assignment of the R-A-C-I values. Activities were defined in the large sense in the previous step of this methodology, but more detail is needed for the RACI.
For example, during the Activities discussion we used a client operating system image development team as a model, and Lab Management was one of the supporting activities identified. On the RACI, though, just "Lab Management" may not suffice, and we may have to dive deeper into what goes into lab management by interviewing the lab manager and anyone else she may identify as a good source of input. By so doing, we may come up with a more detailed list of activities like so:
- Lab asset management
- Lab configuration/change management
- Lab capacity management
- Request lab resources
- Review/approve lab resource requests
- Lab Active Directory management
- Lab AV/security management
- Lab SCCM management
- Lab SQL management
- Lab storage/backup management
- Lab network management
Every one of the core and supporting activities, and perhaps external influencing processes, will need to be broken down into a higher degree of detail for the purposes of the RACI. I prefer to come up with a comprehensive list of detailed activities and fill out the RACI prior to meeting with clients about it - it is easier to go over something and approve or edit items than it is to come up with items from nothing.
Once you're ready, a RACI review session must be led - three or four hours of going line by line and deciding if the activity is needed and, if so, assigning the R-A-C-I to it across the listed roles. You may need to add roles outside of the immediate organization, especially for the Consulted or Informed (or both) sorts of things. Vendors, for instance, may be consulted in some matters, but do not represent a specific role within the team.
Figure 2 - an example RACI matrix
The RACI developed will be a living document, and should be put under configuration control and assigned a periodic review date.
In the next article of this series, we'll take a look at the detailed methods used by the team to accomplish the various activities they perform.