Tension Between IT, Business Analysts Causing Problems

Loraine Lawson

I'm the mother of a five-year-old girl and I'm often surprised at the number of social nuisances between her and her friends. Most of the time, my job consists of offering guidance about what is and isn't nice and to occasionally ask, "How would you like it if someone treated you that way?"

Rarely, there's a tricky situation -- like a bully who just wants to be mean to the youngest, weakest kid - but most of the time, the basic precepts of kindness and treating-others-as-you-would-like-to-be-treated go a long way in navigating the treacherous waters of the playground social scene.

I'm beginning to think these precepts would go a long way in the business world, too.

Now, I know it's probably insulting to suggest to adults that they need to go back to playground basics. I mean, adult life is more complicated. This isn't play -- it's the real world. And, doggone it, there's more at stake!

Exactly. All the more reason why we should not, as adults, be acting like five-year-olds, especially in the server room. And yet, this is exactly what seems to be happening between business analyst and IT administrators, according to this recent post, written by Joe McKendrick for Informatica's Perspectives blog.

McKendrick's post focuses on how the tension between business analysts and IT administrators affects data integration. "Just as they say success is 10 percent inspiration and 90 percent perspiration, it can also be said that the success of a data integration project is 10 percent technology and 90 percent chemistry," McKendrick wrote. "And when I say chemistry, I'm not talking about hydrocarbons and nitrates, but the chemistry of people."

A recent TDWI report, "Bridging the Divide: Aligning Analytical Modelers and IT Administrators," inspired McKendrick's post and much of his piece summarizes its findings.

Get this: Analysts are spending upwards of 50 percent of their time basically doing things the IT department could and should assist with, because of the power struggle between business analysts and IT administrators, according to the report.

Business analysts feel the IT department puts up roadblocks that prevent them from getting the data they need. The IT department, for its part, believes it's "safeguarding" the corporate data and ensuring reliable operations, and suspects the business analysts are just being fickle with their requests.

When did "safeguarding" start to mean keeping the data away from those who are supposed to access and use it?

McKendrick's piece gives a great overview of the paper -- really, enough, I think, to get the big picture. But I did download the whole 14-page paper, which noted there are "many incidents that trigger conflict" between these two groups. The most common three are:

  1. Runaway queries
  2. Analytic data sets
  3. Scoring processes

All of this bickering hurts businesses in three major ways, according to the report:

  1. Timeliness suffers.
  2. Model quality suffers. Not surprisingly, business analysts who have to fight IT for information perform fewer iterations of their models, which, of course, leads to very real business problems.
  3. Inefficiency and waste increase. Obviously, if analysts are spending part of their time doing IT's job, guess what's not being done? That's right: the business analysis.

The study attributes this to a culture clash of two distinct cultures: the business culture and the IT culture. And neither side respects how the other side does its job.

 

To be fair, the IT department has some legitimate concerns about security and operational efficiency.

 

Still, I can't help but think IT is a little more to blame than the business. Let's be honest here. We've all known IT admins who wield power by withholding or outright denying information simply because they can. They expect business people to do some serious sucking-up before they offer any help, and heaven help you if you dare go over their head.

 

They're like Dwight, from The Office -- they're power hungry and believe they are the most important person on the team. In their mind, everyone else is expendable. Meanwhile, the rest of the office sees them as capricious and petty dictators.


 

Unfortunately, many businesses and organizations are at the mercy of these server-room dictators because they haven't bothered to cross-train within the division or, worse, they've hired an entire group of people with the same bullying mindset.

 

In the past five to 10 years, business people have become more tech savvy, which means they don't have to put up with this mentality. Unfortunately, this report suggests companies now are paying two people to do the same job -- and only one of them is really doing it. McKendrick noted analysts are spending "upwards of 50 percent of their time accessing, exploring, and manipulating data-tasks that the IT department could assist with."

 

The author of the TDWI report, Wayne Eckerson, offered five suggestions about how to make these two teams play well together. His suggestions include finding a liaison between the two; fostering dialogue through socialization, meetings and formal dialogue; seeking compromises; training, including a buddy system; and implementing virtual sandboxes.

 

You can read his full descriptions starting on page seven of the report.

 

Those are all good suggestions. Again, I'm reminded of a recent conflict between my dragon-obsessed daughter and her friend, who wanted to play mommy and baby. I suggested that, as a compromise, they could play both games by being a dragon family. It worked out fabulously and remains a local favorite.

 

But sometimes, you run into a kid who is just a bully and more interested in power plays than playing. I still don't have a really good solution for dealing with that kid. My best plan is to stay close and be involved, even sitting down to actively participate in the children's play to make sure it's safe and fair for everyone.

 

This works really well -- for five-year-olds.

 

But will a similar approach work as well for adults? It depends, and I honestly think solving this problem depends more on IT than the business. If everyone's willing to keep playing and work through disagreements, I'm sure cross-training and virtual sandboxes will help tremendously.

 

But if someone's just a power-hungry bully, then compromise is not where their interest lies. I once learned the hard way that the only way to deal with a bully is to stand up to the bully.

 

In this case, I suspect it's going to take the CIO being willing to supervise, referee and insist on fair play. And if that doesn't work, then someone's going to have to be willing to replace the bully with a real team player.



Add Comment      Leave a comment on this blog post
Oct 15, 2008 4:22 AM Ching Ching  says:
I had the opportunity to work on both sides of the fence: the IT and the business. The IT would have a bigger share of the "blame" factor, plainly because of their "know all" illusion. In my time as a system administrator and database administrator, I have seen many IT person whose standard reply is "Can't be done" - just to shut out any further requests unless you are in the VP and above positions.There is often the request-minton (badminton rehashed) - business seeking help to drum up a report and IT asking what the business wants- just to get the standard "First we need a job number to investigate and this will take up to 3 working weeks ". Hence as a business now, I ask for raw data - that takes a 3 working days with a week of reminder. Reply
Oct 15, 2008 12:02 PM Mark Heumann Mark Heumann  says:
There are many kinds of business analysts, and this focuses on only one kind. Nonetheless, the poster puts her finger on a reality: the lack of civility in relations between IT people and business analysts. I am one of the latter. I'm 60 years old, male, with a Ph.D. in English and many years' experience in documentation and high-level business analysis. My worst encounters with IT folks have been with male 30-somethings who rose to power out of the ranks of the object-oriented developers who were recruited in the '90s. Their attitude is, simply, "I know OOP, so I know it all." They assume that their elders are old COBOL programmers and therefore treat them with contempt. Reply
Oct 15, 2008 12:38 PM Frits Bos Frits Bos  says:
Ah, so what you have discovered is that the territorial squabbles about sandbox controls have established the neural pathways that make the business world squeak.No, let's get to the point here: the core problem is that the company is not project focused. Many companies have competing silos. An IT department that fears it is going to be outsourced might be uncooperative when a business analyst keeps changing requirements because it might reflect unreasonable effort (= cost) that is asked for only because it is in-house. That does not justify the attitude but it might explain the attitude: background information is missing from the article.If the company is well managed and top-down projects are spawned consistent with corporate goals and objectives then the BA's will be an integral part of the initial requirements elicitation and final acceptance QA (according to the V-model concept). Within the project context scope is defined based on requirements and the charter presumably then incorporates the role of these BA's to maintain and validate the requirements. This holds true for in-house effort as well as outsourcing or procurement (COTS) initiatives (in which case vendor features may require adaptation by the vendor or by the customer depending on the BA's judgment). A project manager worth their salt will understand the BA being a business-centric participant and the developer being a techno-centric participant that will naturally clash from time to time. Facilitation and arbitration should resolve differences: conflict is healthy and leads to better result if managed from a common good paradigm.Snotty coders with limited business skills are no reason to fuel conflict: pity the poor buggers for digging into a status quo. I still fondly remember an advertisement in which a gravestone was used, enscribed with "Here lies the mind of John Doe who, at age 30, stopped thinking." Reply
Oct 16, 2008 3:09 AM Sandra Noble Sandra Noble  says:
Im not understanding the distinctions being made. I have been a business analyst for years and I consider myself to be an IT person. I actually did computer programming in my past life. From my perspective, the role of the business analyst is to be the liaison between business and technology. Business analyst or systems analyst positions are needed precisely because the business and IT have different cultures and perspectives. So, thats a given. But the business analyst is part of both groups Reply
Oct 16, 2008 5:23 AM Speech Man Speech Man  says:
As a consultant who gets called in to help plan and re-align projects relevant to this article, and as someone who deals with both sides of the fence - I've seen both extremes, but mostly it is the paranoid/protective mentality of IT that feeds the beast. Sales training would help these know-it-all's most IMO. When they're looking for work they'll certainly need some.I would also take this opportunity to remind those in this now sterotypical Information Technology mind-set...Companies are not run by IT people, companies are run by those who fire IT people. Reply
Oct 18, 2008 12:42 PM Mark McLaughlin Mark McLaughlin  says:
It's the BA's task to fit the business requirements with the IT requirement and that often leaves them between a rock and a hard place. BA's should communicate priorities, but not necessarily set them even if they change from time to time. The BA should never be put in the position of where they are viewed as "wrecking a project" by changing requirements. In order to keep that from happening, the BA must insist on a governance process that transcends requirements elicitation, decomposition, and implementation. After more than 20 years of having been personally squeezed by the IT department/project manager and the departments with generating the requirments, I can without reservation say that any time I was ever abused it was because I either overstepped by responsibility to identify and analyze the requirements or it was perceived that I had. In both cases, the results have been rather unpleasant, even though they were never career ending. It never killed me, but rather made me stronger and better BA as a result. Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.