How can IT management fail to understand business goals?

Now more than ever, IT must invest the time to understand specific business goals and translate IT metrics to reflect an impact against these business goals.  Often there is a gap between what IT reports and what is of interest to the business.”   — An Introductory Overview of ITIL V3, itSMF, 2007, p. 38

There’s been a lot written about how IT and business are misaligned.  See for example, Susan Cramm’s excellent book.[1]  But how do they get that way?  One cause is that many IT people don’t understand business.  Another is financial invisibility of IT due to budgeting processes.  But these are not the big killer causes.

I believe there are three major causes:  physical distance, psychological distance, and IT overload.

Physical distance of IT from the business leads to isolation in many ways.  One of my client companies had their IT people in a city 750 miles away from the home office.  Not only did this impose communication barriers, it meant that the IT people were living in a different culture from the home office people – even though both locations are in the United States.  Of course, when you add in the distance to some of the offshore contractors who are handling some IT services, physical distance means even more cultural distance.

Psychological distance can be caused by having objectives that don’t relate to business goals and by being managed in a “silo.”  For example, IT may report in to the CFO, and management metrics may relate only to financial performance.  As long as IT is budgeted as an operational expense, then no amount of encouragement will get IT managers to view what they’re doing as a strategic investment.  This can be aggravated by failing to include IT people in business planning.  Finally, I’ve seen IT organizations where the business tools used by the rest of the business are not in use in IT.

IT management overload is the third major cause of misalignment.  Beyond the usual overload caused by rapidly changing technology and shifting responsibilities (associated with Cloud services, for example), IT management is typically trying to do more with less budget.  As the pressure to perform increases, IT management concentrates on operational measures rather than business metrics.  In addition, technology shifts are raising the cost and complexity of legacy system support.  So IT managers tend to focus on reducing these burdens, rather than looking for new initiatives to support.

Where can we start to correct the lack of alignment between IT and business?  After addressing physical location and reporting structures, the most productive way to get alignment is with common metrics.  Look for business metrics that are relevant to concrete business results and are particularly dependent on IT service delivery.  Then make sure that IT managers understand the business metrics.  Finally, make sure that they buy in to being measured by these metrics.  To do that, of course, it is best to include them in business planning processes – and not just as number-providers.

What are your experiences with IT – Business alignment?  I welcome your comments.

[1] 8 Things We Hate About IT by Susan Cramm, Harvard Business Press, 2010

Be Sociable, Share!
About John Levy

John Levy, Ph.D. is an expert in computers, software and storage who is available for consulting in patent litigation.

For more information, email him at, or call 415 269-4096.
And check out John's profile on LinkedIn!


  1. John,

    Very interesting perspectives. You have definitely hit on some of the key contributors to the misalignment.

    This is an interesting problem, dating back to the very early days of “IT”. Remember 6-9 month (or even longer…) development and release cycles? By the time new capabilities were ready they were already out of sync with the business needs. And we weren’t even living in the age of “web speed”.

    Fast forward through the years and the problem remained, but the drivers of misalignment changed. We learned that client/server and the internet/web gave us more flexibility, but it also gave us sprawl and complexity. And all those old systems now became “legacy maintenance” costs, eating into the IT budgets as you mentioned.

    Now we’re in the age of cloud computing, and the situation remains basically the same. We now have layers of legacy – all that client/server and internet/web stuff is now piling on. We have more sprawl – both physical and virtual. And, as we spoke about last week, we now have “C4” (credit card cloud computing), with the potential to cause a significant explosion in the business model. And as we all know, IT will have to fix the problem.

    Moving at “web speed” is good, but as you mentioned, not being able to measure the impact of all the elements that make up your product/service supply chain creates a lot of finger pointing when things go bad, and even when they don’t in some cases. The key, and I applaud your insight on this point, is to link the value and the measurement of IT to the business drivers and success factors. While measuring cost per MIP or cost per terabyte of data stored is interesting, it provides little value in determining if IT is adding to or detracting from the performance of the lines of business. Determining which factors are important and can be linked needs to start way up front in the planning process. All too often we design a solution and then go back and try to figure out how IT impacts its performance. Rarely works.

    But the real trick, and I’m interested in hearing your thoughts on this, is how you instill a sense of discipline and reasonable control in defining these relationships in the age of “agile” development. Not an easy task by any means…

  2. Thanks for the commentary, Robert.

    It’s a long road to get metrics that do what IT needs and still represent real business objectives. We have to start somewhere, so I recommend getting a much stronger dialogue going between the business sponsors and the IT service implementers. And somewhere in that loop the IT management should be listening and contributing, too. In my mind, Agile is all about having those dialogues active and effective while maintaining a disciplined development and operational environment.