Branimir Valentic If you’ve ever had a chance to run a project or an organizational unit, I’m sure you remember usual confusion with who is doing what. Many tasks need to be completed and a lot of people are involved who need to get the results that are expected, so you had better start managing your team. Other colleagues are also stakeholders of that team, so the easiest way to get your organization in order is to document the roles and related responsibilities.
The same principles apply with ISO 20000 implementation. A lot of processes, tasks and activities make up your ISO 20000-based Service Management System (SMS). Sooner or later, if they are not properly documented, you can expect confusion. Let’s see how to avoid such a situation.
What is required?
As with some other standards, ISO 20000 has direct requirements related to the roles in the scope of the SMS and their responsibilities:
- Top management and management representative – as with other management systems, the standard sets direct requirements for top management roles. Additionally, a management representative is still a requirement in ISO 20000. Besides this, top management has to appoint that person, and the management representative is responsible to appoint process managers (with their responsibilities) for all processes in the SMS.
- Framework of authorities, roles and responsibilities – this means that you need to define (and put into practice) how roles and respective authorities and responsibilities will be put in place. ISO 20000 requires that you implement all processes and that you define roles belonging to those processes. One of the approaches would be to define processes, describe activities for particular process and roles belonging to them. This, of course, will go together with their responsibilities and authorities.
- Assigning roles in scope of the process – while setting up the SMS, the standard has direct requirements to apply defined roles and their responsibilities relating to all the processes you implement.
As you can see, the standard makes sure that defining and assigning roles does not remain undefined. Since it’s a requirement, use the opportunity to benefit the SMS and your organization.
How to do it?
There is no general answer on this question because every organization is different. What is perfect for one company can be unacceptable for another one. So, if “copy/paste” doesn’t work – how do you approach definition of roles and their responsibilities, for the SMS?
From experience, here are a few elements you need to consider while setting up your ISO 20000-based ITSM organization:
- Know your organization – which services you support, which people you have, what are their skills/experience, and how their capabilities best suit your requirements.
- Avoid conflict of interest – for example, avoid situations where the same person both opens a change and authorizes it, or even confirms implementation and closes it.
- Combining several roles in one person – that’s must-have for smaller organizations. It’s nothing unusual, but be careful because some roles are well-combined in a single person while others can be counterproductive (the article What ITIL roles can be combined in one person? will provide you with more details).
- Sponsorship – IT Service Manager (or Management representative) needs to have top management as a sponsor. So do various roles within the scope of the SMS’s services. There will be many situations where a sponsor has to stand behind their own people in order to achieve service level targets, customer satisfaction, IT service efficiency…
So, now you know who will be doing what, but the question is: “How to document it?” I have seen some attempts to create huge RACI matrices (a matrix used to define Responsible / Accountable / Consulted / Informed) for a particular activity within the scope of the process. See the article ITIL / ISO 20000 RACI matrix – How to use it to clarify responsibilities to learn more about the RACI matrix). This could be the right approach for really small organizations. But, if we talk about small-to-medium and, particularly, larger organizations such an approach will probably not be enough. Or, if you really insist on it, it will be too complex for practical use.
Since the standard requires that all processes are documented, it’s an excellent opportunity to include role descriptions, including related responsibilities and authorities. Namely, during the process description, you’ll describe activities within the scope of the process. While describing these activities, you need to include responsible parties for certain activities. Once you describe activities for the process, you can list all relevant roles for that process and define their responsibilities. That will make your process completely defined, with everything will in one place.
Make it work for you
While running some consultancy projects, I noticed huge differences between the start and end of the project. In the beginning, some of the roles in an SMS, were undefined (or, at least, not defined clearly). That had an effect on other processes like the activities of other people’s roles. Once we “cleaned-up” the situation by defining and documenting processes and their responsibilities, everyday activities started to move in the right direction.
The right direction means that IT services delivered according to the Service Level Agreement (SLA) and that had the consequence of creating a satisfied customer. Once my customer realized this, defining and documenting roles and responsibilities were not seen as a bureaucratic task. On the contrary, they were now seen as a profit generator. Who needs more reason than that?
This Project Plan for Implementation of the Service Management System can help you make your ISO 20000 implementation process easier.
