Just by looking at the sheer number of ITIL functions and roles may leave you wondering – how do you fit a limited number of IT staff into so many roles? It’s obvious that one person will act in several roles, but how do you optimally combine them? Of course, it all depends on the size of your organization, and which ITIL processes that you’ve implemented, but none of that changes the fact that some roles fit well together, and some of them don’t.
ITIL roles that fit together within the Service Lifecycle
Figure 1: ITIL roles that can be managed by a single person, and the relationship between role and ITIL Service Lifecycle.
The Business Relationship Manager role is responsible for managing and maintaining good relationships with customers, and most importantly, ensuring that the Service Catalogue is adequately meeting customer needs. Because part of customer relationship is agreeing upon and respecting agreed Service Levels, the Service Level Manager and Business Relationship Manager roles fit well together. The Service Level Manager’s focus is more oriented toward initial negotiations of service levels, but that makes him a good candidate for Business Relationship Manager, as he will be very familiar with the customer’s needs.
Risk Manager and Service Continuity Manager are both oriented toward the future, looking for the best possible outcome in case of undesired events. They fit well together, as both roles are responsible for risk management, threat identification and mitigation, and ensuring minimum / or acceptable impact on service delivery in case those events actually occur. The difference is that the Service Continuity Manager is focused on Force majeure and disaster scenario events, and the Risk Manager is focused on risk assessment of individual assets and their vulnerabilities. However, even with those differences, these two roles can easily be filled by a single person.
The Capacity Manager’s responsibility is ensuring that all infrastructure and services (if provided externally) are able to deliver performance and capacity within agreed levels, in a cost-effective manner. These responsibilities match nicely with the Availability Manager role, adding responsibility for meeting the agreed service availability. Both roles include planning, measuring, analyzing and improving of available resources against agreed and expected service levels; however, Capacity Management is concerned with personnel resources as well (e.g., overnight backup not completed, as there was no technician to change tapes), and Availability Management is not. As both roles include monitoring / measuring performance of individual service components, this might be a perfect match to include the Problem Management role as well, as the Problem Manager’s main task is to prevent incidents from happening, and minimize the impact of incidents that do happen. Having insight into individual service components’ status should be a good argument for fitting the Capacity and Availability Manager roles within the Problem Manager role.
The responsibility of maintaining information about assets, Configuration Items (CI) and their relationship is upon the Service Asset and Configuration Manager. This very important, yet laborious role is very similar to the Knowledge Manager‘s role, whose responsibility is to maintain information about knowledge available. That similarity in processes justifies the decision to share those two roles within a single person.
And, as I mentioned before in an earlier post Incident Management: How to separate roles at different support levels, another good role-sharing fit is Incident Manager and Service Desk Manager. Even though the Service Desk Manager has a slightly larger scope of responsibilities, what those two roles have in common is the aim to resolve incidents as soon as possible. In general, Service Desk is the place where all incidents will be reported; therefore, it makes perfect sense to try and resolve them on the spot.
Combining roles is a challenge for both smaller and larger companies. Obviously, smaller companies are de facto forced to fit as may roles as humanly possible into a single person, as there is no alternative. Larger companies may have the luxury of splitting roles among as many persons as they find fit; however, with so many ITIL roles available, it may not be wise to dedicate a single person to ever single role just because you can. If you are so fortunate as to have all necessary personnel available to take all the roles, think about the workload across the lifecycle. For example, if you don’t plan on releasing new services on a daily basis, do you need one Test Manager and one Release Manager? (Note that you shouldn’t combine those two roles, so please continue reading to find out why.)
In my opinion and experience, combining ITIL roles is always an option, as long as you take workload and common sense into consideration.
ITIL roles that shouldn’t be mixed together within the Service Lifecycle
While these are good examples of a single person acting in a multi-role environment, there are some obvious and less obvious role combinations that should be avoided.
The obvious role combination that should be avoided is service Test Manager and Release Manager. While the Release Manager is responsible to plan, control and release a service into the live / operational environment, the Test Manager is responsible to perform all necessary testing to ensure that the service deployed meets requirements. It’s an obvious conflict of interest, as the Release Manager will strive to get the service operational as soon as possible, while the Test Manager will always want to take as much time as possible in order to test the service properly.
A less-obvious role combination that ITIL experts commonly agree should be avoided is Incident Manager and Problem Manager. The Incident Manger is responsible to handle an incident in a way that will result in fast incident resolution or workaround. The Problem Manager, on the other hand, is not interested in quick fixes, but rather on the root cause of the incident – which may take much more time than any Incident Manager is ready to accept.
Another less-obvious combination of ITIL roles that should be avoided is making a Service Owner (any) Process Owner as well. The Service Owner is responsible for delivering the service in question (e.g., e-mail service) within agreed service levels. A Process Owner (e.g., Change Management, Incident management, Service Portfolio Management, etc.) is responsible for ensuring that the process in question is fit for its purpose and is run in an optimal way. As Process Owner, this person is in charge of all other services he does not own for that particular process, and may start looking at other services through “Service Owner glasses,” which should be avoided if possible.
Combining ITIL roles – if at first you don’t succeed, try again
Just remember that ITIL is best practice framework with logical and easy to follow structure. Combining multiple roles for one person should be done using common sense – you wouldn’t appoint the same person to report to himself, or approve his own recommendations, budget, and technical solution, the same way you wouldn’t appoint a wolf to guard the sheep. Combining ITIL roles is a challenge, and it takes time and experience to understand and foresee potential pitfalls certain role combinations may bring upon you. On the other hand, you can use that time to notice and change eventual “bad fits” that may already exist. Just don’t be afraid to make a change; if anything, ITIL is all about the change.