Supporting Someone Else's Network

Comment | Print | RSS

• Login to Rate

When troubleshooting technology problems between two partnering organizations, it's normally not a difficult task to determine the point where your troubleshooting ends and the other company’s begins. Typically, the demarcation point is a network component, server, or piece of software.

But sometimes that line becomes blurred when troubleshooting alongside a sister company or close strategic partner. In some cases, it's prudent to lend a helping hand to other companies that you rely on. IT managers must be very cautious that overreaching your troubleshooting boundary doesn't become a regular occurrence.

At more than one company I've seen IT service "borrowing” become so common it threatened the partnership. This usually happens when there are newly established subsidiary companies or smaller, yet critical, partners that don't have staff up to the level of technical experience that's needed to operate enterprise-class equipment.

When I worked for a large medical center, this happened on a regular basis. The medical center would form strategic partnerships with local hospitals and independent physicians' offices. Much of this inter-organization collaboration required integration with systems so patient data could be easily and safely transferred between each separately managed site. This meant forming VPN tunnels and connecting servers and software to share information. Unfortunately, many of these smaller outfits had IT staff but weren't familiar with more sophisticated tools that larger hospital IT staff regularly relied on. I'm fine with offering a helping hand in these situations -- if they're infrequent. But when you end up supporting another IT department, it's not a good position to be in.

CIOs need to aware of overextending troubleshooting resources, because it can affect business critical operations. While employees are burning hours working on other people's problems, your own problems sit idle. It may be the case that your partnerships are so critical that they justify the time. But more likely than not, CIOs have budgeted under the impression that standard demarcation points are in effect, and you shouldn't be wasting resources on a network that you're not responsible for.

This also highlights the need to involve CIOs and senior IT management -- and in some cases, IT staff-- in the early stages of forming these types of partnerships. That way, IT is able to have its say and get a better understanding of IT capabilities and division of responsibilities on both sides. If it is determined that sufficient skillsets are on both sides of the line, then a traditional troubleshooting methodology can be used.

If not, CIOs need to make sure it is understood that they’ll need extra resources to get the partner company up to speed. In healthcare specifically, with so many remote physician offices, it is a near certainty that IT resources are going to need to be sent out to those satellite offices. Failing to plan for that type of expense can undermine the partnership and the bottom line.

If you don’t prepare, you'll find yourself either troubleshooting someone else's network without the resources and budget, or attempting to explain why a strategic partnership failed due to lack of IT cooperation. No CIO can afford either of those possibilities.