Real third party root cause

Over on the IT Skeptic website, the ITIL Wizard provides the best advice that you can find for free on the internet. Recently he was asked this question:

Dear ITIL Wizard,

Our problem is this: We are being expected to conduct root cause on problems that impacted us but which are owned and maintained by 3rd parties who will also have their own Problem and Incident teams. This means spearheading investigation and exploring ways to remedy problems at another company! It's like sorting out your mate's wife's gambling addiction because it's making YOU have to fork out for John's beers whenever you go out! No, John should be telling YOU what he's doing to sort the problem out.

So, how does the below sound.

--We still raise a problem ticket to track the root cause investigation, but is updated as and when we get information about company b's own root cause investigation.

--If we need to conduct a Major Problem Review on an incident then we start one of our own and review how WE handled the incident before it was sent to company B, and simultaneously ask Company B to conduct one of their own into how they handled the incident etc and when they complete it they send it to us and we amalgamate the two in some way.

Yours or anyone elses thought on this would be ace.

Cheers
Vespasian

Here's the Real ITSM view:

The primary function of root cause analysis is to apportion blame.
The primary function of outsourcing to suppliers is to transfer blame.
So any root cause analysis should (a) determine where the blame lies and (b) if it lies with those conducting the analysis or their mates, then re-allocate it to a supplier. That's what suppliers are for. Clearly they don't save us any money over building everything in-house, so their purpose is to take the blame when we break it.

The book Introduction to Real ITSM says:

The top priority is of course to minimise damage to the IT department, which is the role of Damage Management.
To do this, Real ITSM defines a Damage Control function. This group has the skills and tools for the “Three Ds”: Divert attention, Direct blame and Defend IT.
...
7.4.2 Direct blame
IT should test the resilience of relationships.
• Blame suppliers. Most vendors or service providers will take one for the team in order to protect revenue
• When called in to explain to senior executives make sure to mention unclear and changing user requirements
...
8.1 Buck Manager
A buck can be defined as any detectable or discernable accountability that has significance for the management of the IT department or their staff or the operation of the department, and evaluation of the impact an accountability might cause to the department.
Real ITSM organisations operate on the principle of functional and hierarchal (horizontal and vertical) buck passing.
For effective functioning of the IT organisation, it is essential that the buck not be allowed to stop, at least not within the department.
...
It is the Buck Manager’s role to ensure smooth passing of the buck through and out of the IT department (known as “give a flying buck”). This involves
• passing the buck directly
• running interference for anyone else passing it
• identifying and sharing potential buck targets
...
9.5 SFA
The primary metric of Real ITSM is SFA, or Service Faults Accepted. SFAs are those outages or other service impacts that are acknowledged as being the responsibility of the IT department. SFA should be as low as possible and trending downward.
Service Faults can be attributed to a number of causes that do not contribute to the SFA count, such as:
• external service providers e.g. telco, cabling company, power company, cleaners
• users
• gods, malevolent spirits or ghosts