Asking business managers to describe what software is supposed to do is the unavoidable consequence of a relationship in which IT's job ends with delivering software to its internal customers -- in which projects are considered successful when software is installed, users are trained in its operation, and using it to improve the business is someone else's problem.
Companies that have integrated IT and no internal customers define success differently.
Instead of asking what the software should do, they start by asking how their business counterparts run their operations now, what are their biggest problems, and how they want to run things differently and better in the future.
IT's job is to recommend better ways to operate, using technical capabilities business managers might not even know are possible.
These enlightened companies don't have IT projects -- they have business change projects that aren't done until the planned business change has been accomplished, and users are trained, not in how to operate software, but in how to do their redesigned jobs using the new software.
A few IT pundits have been pushing this approach for years. Peter Fingar, for example, co-author of "Business Process Management: The Third Wave," is emphatic that IT's job doesn't finish with software delivery. "Forward-thinking CIOs will change their titles to CPO," he says. "Chief process officer -- for it's agile business processes that companies want to manage, not technology infrastructures."
David Kaiser of SFM Mutual Insurance is one of those forward-thinking CIOs (although without the change in title). "Businesses that get it," he says, "understand that IT is a part of business process change, not the owner, and that success comes in small steps. It's no longer about large projects with specs handed off to IT for implementation. What really works is a strong vision of success shared by everyone involved in a business change, with an iterative process for making the change happen."
When IT is integrated into the enterprise, the CIO acts as a strategic peer of the company's other executives and the clear goal of every project is to make business change happen. The job isn't done when the software satisfies requirements. It's done when the business runs differently and better.
Whose idea was this, anyway?
Where did the standard model come from in the first place? The answer is both ironic and deeply suspicious: It came from the IT outsourcing industry, which has a vested interest in encouraging internal IT to eliminate everything that makes it more attractive than outside service providers.
Operating informally, doing favors, gaining deep knowledge into how the business works so as to offer suggestions on how to make it work better -- these are what people do when they're in the same boat.
Take it all away and start acting like a separate business, and what do you have? A separate business, but without a marketing department, sales force, or possibility of turning a profit.
My advice? Don't act like a separate business. Do the opposite -- be the most internal of internal departments. Become so integrated into the enterprise that nobody would dream of working with anyone else.
The train is leaving the station. There are plenty of seats available.
It's time to get on board.
This article, "Run IT as a business -- why that's a train wreck waiting to happen," originally appeared at InfoWorld.com.