This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Don't stop aligning IT with the business -- change how you do it. Sit down with businesspeople and talk about goals and what IT projects might do to support them.
Recently we have been hearing urges to "stop aligning IT with the business," some in this very column. Since alignment has been our main interest for a long time, we herewith add our flames to this fire. A few key points:
Should you "stop aligning IT with the business?" Sure, if you are doing it the wrong way, relying mostly on requests from business to form the IT agenda. Putting business in the driver's seat does not guarantee good alignment. Businesspeople often ask for the wrong things from IT, because they don't know everything IT can do to solve a problem or help achieve a goal. Besides, business goals are always changing, adapting to shifts in the business environment, so the right projects today are often wrong by the time they get done.
Heavy reliance on the request process (the most common alignment tool) makes this problem worse. It's slow, for one thing, and updated only in the annual budget exercise. So a business guy proposing a project to support a goal has to jump through many hoops, and ends up in a scrum where ROI and the squeaky wheel get the goodies. Besides, everyone knows that most of the winning projects won't be audited for results, so the best sales job wins.
We looked at the relationship between reliance on the formal request process and our measure of alignment (see chart below).
Those who rely most on the formal request process have the worst alignment. The request process puts a formal wall between IT and the business, so communication on what is needed and what is possible is very constrained. The result: big gaps between what might really work and what gets approved. A major weakness of all portfolio management systems we know of is that they start with approved "requests," and if the right requests aren't there, based on shared knowledge of business goals and IT capabilities, the priorities assigned will be meaningless.
Most other alignment methods try to bring IT and the business closer together: This includes use of IT steering committees, IT representatives to units, co-locating developers in units, having the CIO report to the CEO, CIO participating in business planning, and even agile development methods. They all work, more or less. Good alignment -- choosing the right things -- happens when business and IT people interact on project identification and choice.
Ultimate alignment? Enlightened organizations already are merging parts of IT with the business in their customer-facing units. We call this IT diffusion. And in those units, it's hard to distinguish between an IT guy and a business guy. Theoretically, here the alignment issue should disappear, because these people know both where the business is going and what IT can do to help it get there. Diffusion will work for local (business-unit) applications, but then you run the risk of losing alignment with overall business strategy and direction. A major role for enterprise architecture people is to monitor the fit between local alignment and enterprise strategy.
As we move toward SaaS and the cloud, it will be ever easier for businesspeople to get the IT support they need for business projects. The advantage is they can try things out in the cloud, and if they fit the business need they can be subjected to a dose of IT discipline later. (We can hear the IT guys shuddering now: who wants to clean up spaghetti code?) Another advantage for the business: with diffused IT, you can't tell what's a business expense and an IT expense. The CFO will not like to lose such a big cost-cutting target as the total IT budget.
Should IT resist these trends? Nope. Fighting bootleg systems is a waste of time; instead, IT should educate businesses on how to use the new user-developing technologies, on what the tricky spots are and how to avoid them, and exercise close surveillance on what's being done, being ready to help if it looks like the SaaS or cloud-based system is heading for trouble. This involves IT being more like a missionary than a cop, and might require some serious re-training for the IT missionaries. If IT manages this right, alignment will stay on the right track; if not, IT will get blamed for the ensuing chaos.
So don't stop aligning: change how you do it. Instead of aligning IT to business requests, IT people need to sit down with businesspeople, talk about their current business goals and what IT projects might do to support them. Put these in the hopper, prioritize by relevance to business goal achievement (among other criteria), and pick the best. Then to make sure the right stuff gets executed, use agile development principles to get corrective feedback as you go. If you can't get businesspeople to sit down with you, you have other issues that need to be addressed. For a road map on these issues, go to: www.cognitechcorp.com/CogniTech-Improvement.htm.
Lodahl holds a Ph.D. in industrial psychology and held professorships at MIT and Cornell. He was editor of Administrative Science Quarterly; director of office automation for Diebold Group; and co-founded CogniTech Services in 1983 with Kay Lewis Redditt.
Redditt has a master's in econometrics. At American Express she held positions as MIS director and division CFO and joined MacMillan Publishing as division chief operating officer.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.