Jim Harris recently blogged The Road of Collaboration in which he makes a case for business and technology sides of a company to come together and walk the middle road towards greater collaboration. Although this joining of forces would be an optimal scenario, overcoming the fundamental prejudices that some non-technical people have against their technical counterparts makes it difficult to walk hand-in-hand.

When things go wrong on a project, as they inevitably do during development, testing, or – spotting Murphy’s Law here – at some point in production, the first place most business users look to troubleshoot is within the technology.  This theme is lampooned to another of Harris’ articles, the Pirates of the Computer: The Curse of the Poor Data Quality in which bad data quality gets blamed on the system, the process, and seldom is fixated on the user.

And why should it?  After all, everything worked fine the day before and now it doesn’t.  Something outside of human error must have failed and this “something” naturally relates back to the hardware, the software, or some inconsistent gremlin that slipped into the servers to wreak havoc. Trouble tickets are opened, the IT support staff is called, and the resource-intense analysis that lasts for hours (or maybe even days) commences.

We all logically know that the technology is sometimes the cause, and sometimes it’s not. We know that problems can and do come from where we least expect it or – heaven forbid –  may even be due to us and our own fat fingering,

But even when knowing this, the first person the users blame is the IT guy.  If not the “guy”, then the software application which is really the same thing as blaming IT.   Remarkably, this scenario occurs even when IT has minimal input into a product other than hardware support, such as a “buy versus build” solution where the vendor’s product is the real culprit of data issue.  So we must ask ourselves: why does the IT guy get scapegoated for these errors, guilty until proven innocent?  Regardless of the real cause behind bad data, this process takes up time on both sides of the fence, causes frustration against “broken software” and “inept users,” and leads to animosity that shoves collaboration out the window.

There are workarounds to this, but it’s not easy. For starters, we probably need to understand why the IT guy gets the blame.  Although there are many factors, two of the main sources seem to be Fear of the Unknown and Mistrust of Technology.

We talk about fear of computers (cyberphobia) which is really just fear of the unknown. Although not as common as in the past, it is particularly prevalent for those who are not familiar with computers and loathe the advancement of computers in society that shifts the way “things have always been done.”

We all know someone who is reluctant to adopt new systems; new only complicates things, and people who are not comfortable with changing their old habits will reflexively jump at the first sign of trouble.  To them, the culprit must be the new technology.

Similar to a fear of the unknown is a Mistrust of Technology in general. With news about viruses, constant hotfixes, and the overall chaos surrounding rushed product roll-outs, it’s no doubt that computer systems get a bad rap.

This is not completely unjustified–in a 2008 article on IT Systems failure , software failures were cited as the number one reliability issue in an organization, followed by network failures, performance degradation, and the failure of physical components.

All systems have the potential to collapse, seemingly without warning, so it’s no wonder that the first place people point their fingers is the IT department.

With these factors in mind, organizational teams may be able to take some action.  For example, to mitigate the fear of the unknown, users should be encouraged to become familiar with their software of choice through training, tutoring, online forums, and even one-on-one mentoring.

Overcoming the prejudice of unreliable technology is a bit more difficult, especially when users believe they have the hard evidence to back up these prejudices. The goal here is to prevent finger-pointing so communications channels between the users and the IT staff should be maintained with chatter before escalation truly begins.

Sometimes the problem is a quick fix and that having an on-site dialogue can save frustration well in advance. By turning our focus against the task at hand rather than blaming the IT guy, we increase the level of patience, open-mindedness, problem-solving and flexibility within a team. This can go a long way towards walking the road of successful enterprise collaboration and ridding the IT department of the curse that haunts them at every network failure.