“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 organizations — 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 favor of what their experience tells them works in real organizations.
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.”
When IT acts as a separate, stand-alone business, the rest of the enterprise will treat it as a vendor. Other than in dysfunctional, highly political environments, business executives don’t trust vendors to the extent they trust each other.
Nor should they.
Chargebacks or effective governance — pick one
Businesses that take running IT as a business seriously have to bill IT’s internal customers for services rendered. That means instituting chargebacks, also known by the more impressive-sounding synonym “transfer pricing,” but more accurately described as “full employment for accountants.”
Most CIOs I know dislike the idea, but the pressure to head down this path is strong.
Its proponents paint it in rosy terms. Typical is a commentary by Dan Woods, CTO and editor of Evolved Technologist. In a recent Forbes editorial “How to run IT as a business,” he wrote, “Right now, about 70 percent of IT costs go toward keep existing systems running; only 30 percent finances new development. Without chargeback, business has little incentive to demand efficiency. The size and scope of existing systems grows, crowding out innovation.”
When the only incentive managers have to promote efficiency is the impact of chargebacks on their departmental budgets, chargebacks are just a Band-Aid. They won’t fix the real problem: that nobody cares about the success of the business, only their own fiefdom.
Anita Cassidy, president of IT Directions and coauthor of “A Practical Guide to Reducing IT Costs,” has seen the damage that chargebacks can do. “Although charging back IT costs can discourage frivolous spending,” she acknowledges, “I’ve seen it create too many undesirable results.
“I watched one company make several poor strategic decisions for the enterprise as a whole,” she adds. “Because of its chargeback system, its managers were more concerned about reducing their individual costs than doing what was best for the enterprise. I watched another significantly increase shadow costs and inefficiencies within the business. Chargebacks had a chilling effect on using the central IT services.”
Chargebacks are an attempt to use market forces to regulate the supply and demand for IT services. If that’s the best a business can do, it means the business has no strategy, no plans, and no intentional way to turn ideas into action.
What works
In my firm’s consulting work, we discuss these concepts on a regular basis. Not only CIOs, but also our clients’ business leaders express relief when we provide alternatives to internal customers, chargebacks, SLAs, and all the other baggage associated with the “standard model.”
The alternatives begin with a radically different model of the relationship between IT and the rest of the business — that IT must be integrated into the heart of the enterprise, and everyone in IT must collaborate as a peer with those in the business who need what they do.
Nobody in IT should ever say, “You’re my customer and my job is to make sure you’re satisfied,” or ask, “What do you want me to do?”
Instead, they should say, “My job is to help you and the company succeed,” followed by “Show me how you do things now,” and “Let’s figure out a better way of getting this done.”
Governance, not chargebacks
Cassidy sees proper governance as the superior alternative to using chargebacks to set IT’s priorities. The company’s leaders have to collaborate to determine how funds are spent, or the company won’t be able to set and implement a strategic direction. “This results in a more productive and effective organization,” she says.
When IT is integrated into the heart of the enterprise, its priorities aren’t defined by who has the budget to spend (by chargebacks). Rather, they’re defined by a company leadership team whose members have a shared purpose, who understand what the company must do to achieve that purpose, and who understand the role new technology will play.
That’s what proper governance requires: effective leadership. It’s the hard work of turning the company’s top executives into a team that agrees on strategy and turns it into a plan for coherent action. IT’s priorities are built into that plan. They aren’t bought and sold by whomever plays the budget game best.
The superior alternative to IT projects
When IT runs as a business, it “sells” software that “meets requirements” to its “internal customers.” Because its product is software, it has no choice — it has to ask the wrong question: “What do you need the software to do?”
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.
