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."