Devil’s Triangles in Service Management, and how to avoid them

Devil’s Triangles in Service Management, and how to avoid them

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.

The devil's Triangle with supplier and user
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.

The devil's triangle with BIM and ITSM

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.

The Devil's triangle with Application Management and Systems Management

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.

The Devil's triangle with two suppliers

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 Devil's Triangle with three or more suppliers
 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).

USM White papers can be downloaded at https://usm-portal.com/shop/?lang=en


[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



Gordon Crowe

A Process Driven Leader

4 年

Excellent article, nice work!?

回复
Sreejith Rajagopal

Lead - Integrated Platform & Release Management, Dynamics Transformation Program

4 年

Good one. Thanks for sharing Jan!

回复
Srivas Melkote Kainkaryam

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.?

回复
Bryon Zimpfer

?? 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.

Krishna Prasad Krishna Kripa

Advanced Consultant @ Capegemini Engineering | PMP, ITIL, MCITP, Google Cyber Security Professional

4 年

Thank you Jan van Bon. Awesome?

回复

要查看或添加评论,请登录

Jan van Bon的更多文章

社区洞察

其他会员也浏览了