Devil’s Triangles in Service Management, and how to avoid them
Jan van Bon
Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery
Devil’s Triangles lead to poor cooperation between parties. And the customer – the user organization - usually is the victim. A systematic approach to service management helps you prevent the devastating effect of Devil’s Triangles.
In service management, a Devil’s Triangle indicates a relationship between three parties, where cooperation fails[1]. Each of these three parties has its own interests, leading to a failing system (the triangle).
A Devil’s Triangle originates from badly coordinated relationships between at least two of the three parties. The failure of the cooperation then manifests itself in communication and coordination problems, leading to poor performance.
You’ll recognize most of the examples, but do you recognize the solution?
Supplier and users
One of the most familiar examples of a Devil’s Triangle is the one between the customer, the supplier, and the user (see diagram below). A conflict of interest may arise between the customer, his supplier and his own users. The red dotted arrow indicates the relationship where things go wrong. The black shadow indicates the requirement of a governing task.
Example The customer outsources a service provision task on the basis of costs, and informs the users that the service will “finally” be provided properly. To comply with the agreement, the supplier does indeed deliver the service at a lower cost. He thereby serves the intended interests of the customer, but he also cuts into the functionalities or the performance of the service. The users lose functionalities or performance characteristics that they were depending on.
BIM and ITSM
A well-known example from the IT world is the conflict between Business Information Management (BIM) and IT Service Management (ITSM), see the diagram below.
BIM staff often feel "part of the user organization", while they actually are also internal solutions teams, with their own contribution to the "information processing" facility domain. But just try to make them accountable for it... Have you ever seen an SLA for a BIM team?
The IT (service) managers have learned to behave much more like internal service providers, however, they are often put on a distance, being partly outsourced or having less communication and contact with the user organization. Although the separation of duties that provides the basis for the distinction between BIM and ITSM is a valuable intervention in itself, practice often causes problems.
Example BIM administrators regularly try to interfere with the choices that fall within the ITSM domain, and they tend to "do it themselves". Just try to deny all BIM staff access to the production environment and you’ll know where it hurts... The opposite also happens a lot: IT managers setting up a functional specification, a task that is clearly reserved for the discipline of BIM.
These situations clearly fail in terms of separations of duties and can cause a continuous battle between BIM and ITSM, where it again is the customer who falls victim to the situation.
Application management and systems management
Another Devil’s Triangle involves Application Management and Systems Management (or 'systems administration', see diagram below). Application management is a regular part of ITSM, just like the rest of technology management, but the contrast between these domains is often emphasized and used as a reason for making an organizational split. And it is just that, where many of the current issues between business and IT originate from.
Application management goes way beyond software development and should be merged with the management of the rest of the infrastructure. In practice, there are often huge gaps in terms of organization and culture. Modern techniques such as agile and DevOps may contribute to a better partnership here and there, but there often is still a huge gap between these domains.
Example A service is a supported facility. In IT this relates to software programs running on computing systems in network environments. Experts in the field of software development usually focus on developing new software functionality. Experts in the domain of platforms and networks usually focus on the continuity of the production environment, offering the information processing facility to the customer. This often leads to two very different types of IT experts that do not understand each other very well. The systems management staff sees new versions of software as a disruption of their stability, introducing continuity risks. The development staff sees the other party as an obstacle in their desire to deliver new functionality to the business. DevOps provides a modern strategy to attack this, focusing on the cooperation between ‘Dev’ and ‘Ops’. Unfortunately, DevOps also introduces new risks to the discipline of information processing, when the urge to deliver new functionality becomes a dominating factor, tilting the IT organization to a set of parallel IT providing systems, ultimately creating an undesirable complexity in IT. This can only be solved in a sustainable way, if all involved parties learn to focus on the integrated service, in the best interest of the customer.
Outsourcing
The diagram below illustrates a Devil’s Triangle in outsourcing. The red dotted arrow again indicates the relationship where things go wrong.
If the agreements between the customer and both suppliers (‘external solutions teams’) do not provide for seamless cooperation, problems will arise soon enough. As soon as the demarcation line between both suppliers is no longer completely clear or satisfying for at least one of them, situations will arise where issues "fall between two stools", and these issues will bounce back and forth between the two suppliers.
"This one is for you…."
"No, it’s in your domain…."
The customer is then the victim of his own (defective) arrangements.
Because both suppliers focus on different interests and objectives, the resulting service will not fit well with the interests of the customer.
Example A customer has outsourced a service component “cloud hosting” to supplier 1. This supplier has optimized the agreement with his own revenue model, where computing volume and maintenance costs are the major drivers. A second service component "application management" has been outsourced to supplier 2. This supplier has optimized the agreement for "support time spent", because that’s his business model. An issue involving the cloud conditions of supplier 1, with an effect on the hours spent by supplier 2, will now lead to a conflict of interest between the two suppliers. The client then becomes the victim.
Devil’s Triangles may also originate from conflicts of interest between internal solutions teams.
Multiple sourcing
If a single sourcing situation causes a Devil’s Triangle, what do you think will happen when you get involved in the multiple sourcing situation that is becoming regular business nowadays?
If it is difficult to make conclusive agreements about two partial assignments in a service, then it may be clear that this is much more difficult with three partial assignments. The left diagram in the diagram below illustrates that the number of potential drama relationships then jumps from one to three.
With four partial assignments, the number of potential Devil’s Triangles doubles from three to six. For five assignments, this then jumps to ten. How many suppliers do you have? Five? Ten? Twenty? Even more? As long as these suppliers provide services that have little to do with each other, that's not so bad, but what if those services fall within one and the same discipline? What if they fall within an Enterprise Service Management approach? Solving all these Devil’s Triangles will soon become your full-time job….
This puts an increasingly heavy burden on the customer's directing skills. Managing three, four or five suppliers is still going to work, but if they all point to each other, a great deal of coordination violence is required to keep the service going. The result is a reactive organization that is spending all its energy on repairing what went wrong.
The number of Devil’s Triangles grows much faster than the number of parties involved in a multisourcing situation.
Cause & Solution
There are various causes for Devil’s Triangles in outsourcing, also applying to most of the other situations. The 5 main causes and the associated solutions for all these Devil's Triangles are described in a USM white paper, which is too long for a LinkedIn blog. You can read the full white paper at the USM Portal (or click the image below).
[1] Devil’s triangle also is a nickname for the Bermuda triangle – a mysterious region in the North Atlantic Ocean where ships and aircraft seem to disappear without a trace
A Process Driven Leader
4 年Excellent article, nice work!?
Lead - Integrated Platform & Release Management, Dynamics Transformation Program
4 年Good one. Thanks for sharing Jan!
Service Management Consulting & Delivery, IT Project Management
4 年lovely article. Could someone please guide me on how exactly to read the text in the boxes? They are very significant to the narrative, but more often than not, i am unable to read the top line as it is cut off BUT refuses to scroll in all but one of the boxes. I am missing a point, maybe a trick, but please do help. Also, this is an area covered under SIAM, if I am not mistaken. While I understand this could happen in a SINGLE Vendor situation also, the fact that some of the "internal" teams are also delivering services to the customer, MUST not be forgotten. ONLY when there is "equality" among the vendors in their tasks and a clear cut responsibility for the client too (Yes, right, CLIENT!), will there be situations that can be handled. Else we end up with the "not mine, yours..." situation, all the time. I remember we having faced this situation at one client, but there was a over arching vendor that was in charge of the other vendors. While this was working, i still feel the SMO should be run by the client himself/herself.?
?? Highly Regarded ITSM Expert ?SME in CMDB, Configuration Management & IT Service Management to transform IT Operations
4 年Thanks for sharing this Jan! These issues commonly inhibit progress yet are rarely realized or properly addressed.
Advanced Consultant @ Capegemini Engineering | PMP, ITIL, MCITP, Google Cyber Security Professional
4 年Thank you Jan van Bon. Awesome?