Complete ITIL implementation will bring around 40 new roles to organizations but it is not practical to do so even for a big organizations. The reason is that some processes are not best suited for the existing structure, and that the cost of change will perhaps exceed the selective process selection and unnecessary increase the cost of implementation without adding any value.
While larger enterprises boast of a good chunk of ITIL roles manned by dedicated resources, smaller organizations (if they end up implementing processes in service design, transition and operation), might choose to go in for the full array of roles, with resources handling multiple roles concurrently. Having dedicated resources requires deep pockets, and a bottomless pit of budget reserves, which is unusual these days.
ITIL publications do not explicitly talk about people holding either a single role or multiple roles. But the implication is that a person will take over one role, and not multiple ones.
There are three different categories for the combination of role: conflicting roles, roles with synergy and roles which does not care about conflicts or synergy.
In ITIL, if the outcome of one role is influenced negatively by the other, it qualifies as a conflict. Or, if the objective of one role has elements that tend to alter the thinking of the other – now that’s a conflict.
The combination of two or more roles which ends up benefiting one or multiple processes. A producer, who also directs the movie, is more likely to optimize spending and sweat over all directorial details to ensure box office success. Whether it succeeds or tanks is different topic to discuss another day.
There are a number of role combinations which falls under don’t-cares. They neither conflict, nor add synergy.
ITIL roles that conflict
Incident and Problem Manager
This is a classic role conflict in ITIL. Many organizations identify the same person to do both the roles without realizing what is at stake.
An incident manager’s objective is to drive toward resolution at the earliest–either through a temporary workaround, or a permanent solution if available. A problem manager is hell-bent on getting to the root of the problem. He’s interested in the source of the problem, and unless and until a permanent solution is not in sight, he doesn’t care about any temporary fixes.
In theory, and in practice, it’s pretty obvious that both the roles require people who are oriented quite differently. Yet it’s a common practice to club these two conflicting roles.
Release Manager and Service Test Manager
A release manager has an objective to release software or implement hardware equipment as per customer requirements/architecture. In PMI methodology, he would be called a project manager, as the activities involved are similar, i.e., initiation, planning, execution, control and closure.
One of the sub-activities of release management is testing the release package before it’s deployed. A service test manager is appointed to oversee the test activities and report on the observations found.
It’s not uncommon to see a release manager being given the responsibilities to manage build, test and deploy activities. I have a problem when a release manager works as a test manager as well.
The test manager’s job profile includes testing the built package, verifying if the functionalities are as per design and whether the release meets customer expectations. Whereas a release manager wants to complete the project on time–and within budget as always.
If the two roles are combined, there is every chance that the test manager’s role can be compromised. Suppose the release is running on a tight schedule, and a minor flaw is identified which may not impact anything directly. A test manager who is also a release manager might overlook it for the benefit of the other role he’s playing.
In all activities, a tester must be a different person. In ITIL, another popular conflict on the same lines is the process manager playing the role of a lead auditor. This should not be allowed, for the organization’s own good.
Process and Service Owner
A process owner owns the process (like incident management), and is responsible for ensuring that it’s fit for purpose intended. A service owner likewise owns the service but is responsible for the delivery.
This conflict is rather indirect. A process owner, who owns the service as well, is adapted involuntarily to the service he owns, and to a certain extent, starts looking at services through the lens of the service he owns.
Being a process owner, his scope extends to other services that he may not own. So, when he tries to apply the process to another service whose genetics are quite different, it may feel like tailoring a suit for Kevin James, and asking Johnny Depp to don it.
ITIL roles that synergize
As I mentioned earlier, the combination of two or more synergistic roles benefits the other.
Risk and IT Service Continuity Manager
A risk manager is tasked with identifying, assessing and controlling risks. An IT service continuity manager ensures the service is able to perform at minimum service levels if a disaster happens.
Both the roles are aligned, in the sense that they are proactive, but they also look toward the future, getting ready to minimize the unintended effects.
Each would help the other in contributing with specific intel that helps both the process overall.
Configuration and Knowledge Manager
A configuration manager identifies, records, controls and verifies records of configuration items. A knowledge manager does a similar set of activities with available information, and knowledge.
Knowledge management is relatively new to many organizations, but configuration management has existed for a while. However, a knowledge manager need not re-invent the wheel to plan the management of information and knowledge.
In this case, configuration management can lend a hand, and synergize knowledge management activities for the better.