Its not news that business and IT departments within a company dont always get along. Its rare to find a geek or a suit out there that cant list off one or several examples of their earnest work being thwarted by “those other guys.”
Yet, most people will tell you there is more to the picture than incompatibility, some noting problems as simple as a language gap.
“Sure, youre both speaking English, but the same words may mean different things to the IT and business sides of the organizations,” said Jeff Bates, founder of Slashdot.org and vice president, editorial of OSTG.
Bates gives a recent example of a colleague who was presented with a report that had the words “My Sequel” throughout it.
“Obviously, this report writer had a conversation with someone discussing MySQL and didnt understand it was an abbreviation. But, its indicative of the language barriers that can occur when both sides make assumptions.”
Personality differences come into play, too, from differing motivations to disparate needs from their jobs.
“We did a survey of developers about their motivating factors, and the majority of them said that they felt their work was akin to writing a song or telling a story. This plays out in the corporate environment, too. IT will often think its the right thing to do to maximize the functionality of a new tool, when business just wanted a specific solution,” said Bates.
Bill Hewitt, former Novell executive recently turned CEO of Kalido, summed up the differing ideal work environments for IT and business folks.
“IT wants to have a centralized role that they can control; business wants to have a decentralized role with complete flexibility,” said Hewitt about the culture gap between the teams.
Yet, beyond these leveled playing fields, there are times that even the best, brightest and most well-intentioned business person can approach their IT department the wrong way.
Worse than causing offense or exacerbating animosities, its counterproductive to the shared goals of both teams.
eWEEK spoke to a batch of IT managers, business analysts and others with related expertise about exactly what these things are.
More than a blame game or all too easy finger-pointing, their specific examples of ways business can hinder IT progress lends insight to the age-old conundrum of why so many projects fail.
Next Page: Lacking a long-term plan.
Lacking a Long
-Term Plan”>
1. Lacking a long-term plan
“Fix this. Its broken,” is one of the most commonly spoken interactions between business and IT units of an organization, and by many accounts, the first place communication breaks down.
“One of the reasons there is distrust between the two groups is a result of tone. Just fix it, people will say. The tone of it and the general imperative nature says I dont really care about this. I just want you to fix it. It implies a basic disrespect of the actual operation, to not care enough to understand why something is broken. Theres a difference in the curiosity and follow-through of business and IT guys,” said Bates.
This is also a source of aggravation for many a techies, who are then handed the burden of finding a badly-defined solution.
“Part of the problem people have is that theyre not really sure where they want to go. They know something hurts, but not enough time is spent on what not hurting would look like. Theyre focused specifically on fixing a pain. That articulation of the end state helps people step back and break down the work you need to do to achieve that goal. … Most projects fail because there isnt that clear understanding,” said Kathleen Barret, consulting manager for the Requirements Management/Business Analysis Center of Competency within BMO Financial Group and president of the International Institute of Business Analysis.
This lack of a long-term vision of an IT solution leads to many disappointing outcomes.
“Both sides of the house assume theyre experts at what theyre doing. Build me a house, a business person will say, and the IT side will say they can have it ready the next day. But what they got was a lean-to and not a castle, because they werent able to articulate what it was that they wanted,” said Glenn Brûlé client solutions executive for ESI and a member of the board of directors for the IIBA (International Institute for Business Analysis).
Rushing Projects
2. Rushing projects along, sometimes unnecessarily
Right after Fix this. Its broken, the next most commonly heard by business to IT teams is We need this ASAP.
“The most obvious communication breakdown is instilling a sense of urgency where there may not be one. Everything is urgent, if were not completing it today, the world may blow up tomorrow. At the end of the day, we learn many of these things could have waited. Its kind of like the blinders leading the blinders,” Brûlé said.
Furthermore, IT often hears “ASAP” from innumerable sources.
“Business units often have this idea that theyre the only people in the entire world that IT is working with, when IT is also supporting enterprise-wide problems,” said Brûlé. “If we need it in a month, asking IT to have it in 15 days is a good way to end up disappointed with the results.”
Business jobs are aligned around numbers and deadlines, but for IT units, this is only secondary to the juggling they need to do on a daily basis.
“At any given time, our IT group of four to five people has 80 odd things in the queue. Theyre dealing with the internal network, cell phones, telcos plus maintaining the entire network while trying to get the spyware off the machine in the next department as well as making sure the Oracle server stays up. A project in IT is never finished; it needs upgrading and b-licensing. Its never a you finish it, you walk away thing,” said Bates.
Next Page: Not knowing what they dont know.
Not Knowing what They
Dont Know”>
3. Not knowing what they dont know
Nobody in IT expects business to know how to rewire a faulty router or upgrade a server system, IT managers expresses again and again, but they did expect them to know where their technology prowess dropped off.
“Business guys tend to think of problems in terms of the technology that theyre familiar with, not understanding the magnitude of the IT process,” said Hewitt.
A simple do this can mean hours, weeks or even months of work on the IT side, where ASAP often only translates to how much business is willing to compromise to get a project moving on schedule.
“The issue with rushing projects goes back to the basic lack of understanding of whats going on and not knowing all the moving parts. Running a large-scale Web site is very different from running your desktop. When someone says they want something right now, many IT guys dont even know how to begin to explain what would be involved,” said Bates.
When business makes demands on technology they dont fully understand, worse than stepping on ITs toes, they show a lack of respect for their work and their process.
“Often people on the business side think that because theyve done some amount of research on a technology that its the right solution. When presented with reasons that no, it may not be the correct answer, it can become a very defensive situation,” said Bates.
Bates gives the example of other work environments, where groups wouldnt think of interfering in each others processes.
“Lets take for example a chemistry company. Would the business unit come in and tell the chemists how to do their jobs? No, it wouldnt happen. Within the IT environment, theres not always that respect and understanding, or giving credit for their technical wherewithal, practice with and full knowledge of a technology,” said Bates.
Among the worst offenses is taking technology decisions entirely out of the hands of the IT department, often causing hours and months of agony on the part of the people required to maintain a bad system.
“Business often has a tendency to go out on their own and buy software thats not necessarily the best, leading to integration, proliferation and maintenance issues down the road. This is not to suggest that IT should have 100 percent centralized control over these purchases, but often there is the view that it is not an IT decision to make,” said Eric Dorr, senior research analyst at The Hackett Group, a strategic advisory firm.
Blaming IT
4. Blaming IT for project failures
By most accounts, projects fail within organizations almost as often as they succeed. At the end of the day, someone has to take the blame for the failure, and all too often, this failure to deliver is dumped on IT.
“It gets a bad rap. I think theres a perception that IT is the cause of many failed projects, and they often get the blame,” said Bates.
In psychology, there is an outcome called the “self-fulfilling prophecy,” which, in effect, states that in expecting something false to be true, these expectations are often met.
Applied to ITs bad rap among many business folks, Brûlé says its unsurprising that business can allow themselves to feel continually disappointed. The approach is flawed, he argues.
“We take the approach that its ITs job to solve things, and business job to conduct business. IT has gotten a bad rap for not being able to product the deliverables that everyone expects, sort of an I know youre going to screw it up mentality. There are very low expectations,” said Brûlé.
“They may not realize that their dictates will affect other areas of the organizations, or understand the overarching implications. Theyre hoping to find all the solutions in one place when both parties are really at fault.”
Check out eWEEK.coms for the latest news, reviews and analysis on IT management from CIOInsight.com.