I don't much like sweeping generalizations, but here's one I think is true: Everyone agrees IT is an integral part of the business, almost any business. Imagine anything getting done at your company without the systems that make it easy to communicate with your coworkers and customers, and the systems that store and analyze your data. Any company without those things is doomed to fail.
Earlier this year, I cited comments from Ajei Gopal, CA's executive vice president of technology products, who dismissed the popular call for better alignment of IT and the business. He said:
Alignment is a horrible word because it's a term that suggests IT and business are two different parts that need to be aligned. [IT is] something that's core to the business. They are fundamentally intertwined.
Yep, he's right. So why, when IT and non-IT business units obviously need each other so much, do they often find themselves at loggerheads? Gartner's Mark McDonald writes on his blog about six common IT practices that can contribute to bad feelings (if not misalignment) between IT and the business. Interestingly, all were considered best practices at one time or another and some still are.
Many of them date back to the days when IT's primary job was building out core transactional systems. Now, writes McDonald, "IT systems process more than transactions; they automate complex business processes, provide business intelligence and provide direct support to customers and suppliers." The six practices:
- IT "enabling" the business. I confess, I talk about "enablement" a lot. And I'm not the only one. In the first of a fine three-part series on a successful three-year IT transformation project at Motorola, Keith Leust refers to IT being transformed "from a cost burden to an enabler of the business through the delivery of products and services, and an active partner in the sales process to drive revenue." The problem with enablement, says McDonald: It "does not connote responsibility for results and that separates the business and IT."
- Defining the business as the customer. This reinforces the idea of IT as only a support function, says McDonald.
- Focusing on requirements. Using requirements means the business must translate its needs into terms IT understands, often using intermediaries like business analysts. The problem here, writes McDonald: "What gets lost in translation separates the business from IT, particularly when the business says the system is inadequate and IT responds that it was built to requirements." I recently shared some tips on creating good business requirements from Erik Van Slyke, a founding partner of Solleva Group.
- Waiting to be asked. IT shouldn't complain about being treated as an order taker if it isn't willing to proactively look for business opportunities. IT is ideally suited to see these kinds of opportunities because of its high-level view of the entire business and its deep insight into operational performance data and its related performance drivers.
- Benefits realization is the responsibility of the business. This tends to come up whenever business leaders try to calculate return on IT investments, writes McDonald, and "sets the context for expensive and timely change management activities."
- Technically oriented IT metrics. "Concentrating on systems availability, IT budget and the status of the investment portfolio tells the business what IT thinks is important," writes McDonald. I recently shared BMC Software's solutions marketing manager Colin Fletcher's thoughts on why there's a disconnect between IT and business metrics, and some great suggestions on creating effective metrics from Diamond Management & Technology Consultants' Jim Quick.