Branimir Valentic
October 18, 2017
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.
As with some other standards, ISO 20000 has direct requirements related to the roles in the scope of the SMS and their responsibilities:
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.
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:
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.
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.