"If you board the wrong train, it's no use running along the corridor in the other direction," said famed World War II German resistance fighter Dietrich Bonhoeffer.
We in IT boarded the wrong train a long time ago. It's the "standard model" of information technology organisations -- the familiar litany that says CIOs should run IT as a business, meeting the requirements of its internal customers. This refrain has been endorsed by our holy trinity, too: analyst firms, most consultancies, and ITIL.
They call the standard model "best practice." When they're in a different mood, they also call desktop lockdown a best practice, leaving you to figure out how it is that you tell your customers what they can and can't do.
So we've had to run along the corridor, trying to make sense of it all. But you can't make sense of nonsense.
I admit this conclusion is not a growing consensus. It isn't even an emerging trend. It's more a guerilla movement, promoted covertly by some renegade CIOs and supported by a few consultants and commentators who have rejected the conventional wisdom and industry punditry in favour of what their experience tells them works in real organisations.
Bassam Fawaz, CIO of a large global logistics company, is one of the renegades. According to Fawaz: "The IT conventional wisdom that is generously dispensed by many IT think-tanks and opinion makers is largely theoretical and offers little or no practical value."
Businesses are starting to shake off the recession and think about the future instead of simply making it to next week. It's the perfect time to board the right train -- the one headed to the promised land, where IT is a strategic partner to the rest of the business, not a subservient order taker content to process work requests while accepting the blame for everything that goes wrong.
Want to board the right train?
Your ticket to the promised land begins with this: No one inside your company is your customer.
Thinking that they are is the core fallacy of the standard model, and it has caused no end of trouble.
Take the common complaint voiced by (among others) Dirk Huggett, an IT business analyst for the North Dakota Information Technology Department: "You are always too expensive. One classic example is PCs," he says.
"Executives get flyers from different vendors for $299 laptops and get upset when the ones they buy cost them $800. It is tough to explain why the cheaper PC won't run their mission-critical application.
"Or try to explain your file and print server hosting rates. It doesn't matter that part of that rate is full backup and off-site storage. Or as part of a clustered environment you have built-in redundancy and that ensuring the server is updated and secured appropriately is part of that cost. Their friend Joe hosts these things on the side, and it is much cheaper."
There are no IT projects
When IT is a business, selling to its internal customers, its principal product is software that "meets requirements." This all but ensures a less-than-optimal solution, lack of business ownership, and poor acceptance of the results.
Adam Hartung, author of "Create Marketplace Disruption: How to Stay Ahead of the Competition," tells the tale:
"I had an experience with the head of field services for a very large pharmaceutical company. He was working himself ragged, and complaining about insufficient budget to build all the web applications his internal customers were asking for. So I suggested that instead of trying to deliver on 'customer needs,' why didn't he go back to the business with a set of recommendations for how he thought he could deliver a superior set of solutions that would meet their needs in 2012 -- and beyond.
"Instead of reacting to users, he should be their peer. Primarily, I asked him why he didn't transition from building web apps to instead creating a solution using cloud technology and true mobile devices like BlackBerrys, iPods, and emerging tablets. He could offer a better solution, at about a quarter of the cost.
"He told me he had never thought of dealing with the situation that way, but it sure made a lot more sense than letting his 'customers' run him ragged to deliver stuff with a short life."
Tim Hegwood, CIO of MRI Companies, is trying to steer his company's mindset away from a focus on software delivery. "We're still struggling to institute the concept that 'there are no IT projects -- only projects designed to solve business problems,'" he reports. "Our biggest issue is accountability. It's hard to get the business leaders to step up and take control of the project and make decisions."
Larry Sadler, IT service manager at ONFC, experiences similar difficulties. "The 'customer' concept is deeply embedded in the departmental silos here," he says. "This results in an attitude of 'I want this or that aspect done, and without any interruption.'"
Fawaz also sees the damage that comes from limiting IT's role to delivering software to internal customers. "I've spent so much time arbitrating between 'business,' which won't put anything in writing as a requirement, and my IT team, which have been slammed so often for not delivering 'exactly what is needed' that they insist on receiving complete requirements before they make a move."
He likens IT's proper role to that of an engineer designing a car. "It doesn't matter if the 'customer' asks for the horn on the backseat. Placing it there would meet the specs and 'satisfy requirements.' It would also defeat the usability of the horn, render driving the car dangerous, and could lead to a crash that ruins the whole effort.
"I am," he continues, "drawing on real-life examples, where a boneheaded software design was delivered to the requirements of the business process owner but made the software dead on arrival as users shied away from using the nonintuitive and unnecessarily complicated program."
According to Fawaz, "IT should relinquish its increasing stance as an order taker, and earn and advance its intended role as the qualified engineer of what makes a business hum."
Huggett explains what happens when the conversation is about the software: "We have always been good at delivering a quality application. It functions exactly as designed. Unfortunately, that doesn't always line up with what the 'customer' wanted or expected."
His agency is trying a new approach now, built around a more collaborative relationship. "We currently have a large project where we have a partnership agreement with the agency," he says. "The agency is responsible for all business-side decisions, and we are responsible for the IT-type decisions. We were part of the RFP process to select the vendor, and we are working side by side with agency and vendor personnel. I think it is a model we will see more often in the future."
Architecture: Another victim of having internal customers
One of my former clients -- a large financial services firm -- had embraced the IT-as-a-business concept. When my firm arrived on the scene, the client's information architecture was in shambles because IT's internal customers weren't willing to invest in sustainable engineering. Why would they? To achieve a quality architecture, the internal customer of one project pays more so that a different internal customer, some time in the future, receives the benefit.
The client's IT staff described the resulting mess as going far beyond the usual spaghetti or spider web. They called it "The Hairball." In an average development project, much more than half the total effort was devoted to coping with The Hairball, leaving relatively few resources to devote to new features and functionality.
The impact on relationships
Another unintended consequence of running IT as a business with internal customers, while less tangible, might be even more important: Defining IT's role this way creates an arm's-length relationship between IT and the rest of the business. That's a problem. As Jim Struve, director of IT supplier management for WEA Trust, explains, "Relationships matter. A lot. I've seen it a lot in my daily work. When people have built a good relationship there is trust and it's easy to get things done. And it's very difficult to get things done when there is not a relationship built, with the lack of trust that causes."