Fixing IT – The Importance of Ownership

My home is your castle?

Organizations that have a centralized budgeting and provision of IT services risk creating a disconnect between those that need technology services and those that provide those services. The first post in this series alluded to the problem – those needing the services have too little control over obtaining those services. If there is only a single provider with finite capacity and a finite budget, then there is the potential for consumers to be left out when demand exceeds supply. Governance processes set up to manage the allocation of services may be ineffective and can lead to dysfunctional behavior when business unit leaders attempt to game the system. Lastly, this situation creates a perverse incentive to gold plate projects in order to compensate for the uncertainty over when the business unit might next get the attention of IT.

The DevOps approach I suggested in my previous post only partially addresses the issues. Having a dedicated team means little if the size, composition, processes, and priorities of that team are outside your control. Much is heard about the concept of “alignment”, but mere alignment is insufficient. As Brenda Michelson noted in “Beware the “Alignment Trap””:

I started to use the term ‘business-IT integration’, because I’m thinking beyond traditional business-IT alignment. Alignment refers to the review and reconciliation of independent activities, in this context the reconciliation of business strategy and plans with IT strategy, architecture and plans.

For business to reap the true value of IT, business and IT must collaborate on the development of strategy, architecture and plans. This collaboration, which should continue through delivery and operations, is business-IT integration.

To achieve the integration Michelson referred to, one should bear in mind Conway’s law: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. The reason to do so is elegantly expressed in Ruth Malan’s paraphrase of it: ” if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”. She goes on to say:

The organizational divides are going to drive the true seams in the system.

The architecture of the system gets cemented in the forms of the teams that develop it. The system decomposition drives team ownership. Then the organizational lines of communication become reflected in the interfaces, with cleaner, better preserved interfaces along the lines where organizational distance increases. In small, co-located teams, short-cuts can be taken to optimize within the team. But each short-cut that introduces a dependency is like rebar in concrete–structurally efficient, but rigid. If the environment changes, demanding new lines to be drawn, the cost becomes clear. The architecture is hard to adapt.

Enterprises are systems, social systems, but systems nonetheless. In the case of business units and IT, you have a social system creating, maintaining, and evolving digital systems. Assuming Conway’s law is true, simpler organizational structures should yield simplified systems (in both the technical and organizational realms). The opposite is also true, poor business architecture can actually reinforce dysfunction and prevent progress. Tom Graves post “Financial-architecture and enterprise-architecture” graphically illustrates just such a case where the accounting structure and approval processes conspired to prevent cost savings:

In fact, the business-case was obvious – or at least, obvious to anyone who’d actually looked at what we’d done. The potential savings in licence-fees alone ran into many millions of dollars a year – let alone the more subtle savings from re-using idle servers or freeing-up unneeded real-estate. By comparison, the costs were tiny: in some cases not much more than a few hours of paperwork, and overall perhaps a few staff-FTE for a few months at most.

But the sting in the tail was that requirement for proof, in terms of the organisation’s standard company-accounts. What we discovered, to our horror, was that the accounts themselves prevented us from doing so: the way those accounts were structured actually made it impossible to make almost any business-case at all for ever shutting anything down.

It should be clear that business structures and processes should be designed to facilitate the execution of business strategy. Part of this is putting technology decision-making into the hands of the business. IT is well positioned to inform those decisions in terms of technical trade-offs, but hardly qualified to decide from a business standpoint. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results by Peter Weill and Jeanne W. Ross (excerpted by David Consulting Group – see table 5) shows that business-driven governance optimizes for profit and growth.

When making decisions about how to use technology in furtherance of business goals is coupled with the responsibility for funding those decisions, customers have greater incentive to make more prudent decisions about their use of technology. Additionally, when those costs are borne by the business unit, both the unit and the enterprise have a clearer picture of its financial state than if those IT costs are accounted for in IT’s budget.

When IT is in the position of advising on and enabling, rather than controlling, use of technology, some benefits accrue. When there’s no need to hide “Shadow IT” from the IT department, business units can take advantage of advice re: security, what other units are doing, etc. The same applies to using outsourcing to augment in-house IT. By being aware of these external capabilities, IT is positioned as a partner to the business unit in attaining its goals, allowing IT to play to its strengths. IT departments that can support business goals as advisers and coordinators of technology in addition to being providers can extend their capabilities with external providers without fear of replacement.

Fixing IT – How to Make a Monster (Customer)

he may be ugly, but he is mine

Software development in general and IT in particular seems to have a love-hate relationship with our customers – as in, we really love to hate on our customers. We have Stupid User Tricks, ID10T issues, PEBCAK, and of course, Clients From Hell. Every once in a while, even Dilbert takes a break from bashing managers to take a swing or two at customers.

There’s even some evidence that the feelings are mutual.


How is it that we’ve managed to come to the point where distrust, even open hostility, is the norm? How is it that this situation is allowed to continue? What if we don’t change the dynamic?

To get an idea of how we got here, imagine the following scenario:

  • There’s a restaurant where you’re required to eat.
  • You don’t get to decide when you can eat; you have to ask (and ask) and eventually you’re allowed to sit at the table without any idea of when you’ll get another chance.
  • You don’t pay for what you eat, but you will have to justify each menu item you order.
  • The kitchen staff will be required to say how exactly long it will take to prepare the order, even if the item is not on the menu and no one has ever made it before.
  • The waiter, the chef, and the maitre d’ may not understand or be able to prepare your order, so they reserve the right to alter it without any notice – you’ll find out when it arrives.
  • Waiters interacting with diners after the initial order is considered poor practice; kitchen staff doing so is completely out of the question.
  • If the order doesn’t meet your approval, you can send it back to be fixed as much as you like.
    • Under those circumstances, one might expect the restaurant patrons to be a tad distrustful of the staff, who will probably respond in kind. The experienced patrons will have learned to order as much as possible, regardless of need, subject only to the restraint of getting approval. They will have learned to be vague enough to allow them to keep sending dishes back for fixes that are enhancements in disguise. The bolder patrons will either learn to cook for themselves or find another restaurant, perhaps both.

      Is this starting to sound familiar?

      The second question, how is it that this has been allowed to continue, is something of a mystery. While there has been a growing significant incidence of shadow IT, things still haven’t broken out into open rebellion. How much of this is inertia and how much of this is the current economy holding back expenditures? More ominously, how close to the edge are we?

      This brings us to the third question, the answer to which should be obvious. Trying to maintain the status quo will not work. In fact, doing so will be more likely to hasten the demise of IT as it becomes more of a commodity. Without major changes, IT risks becoming irrelevant and marginalized. Rather than worrying about blame (it should be obvious that this is a systemic problem rather than one or two bad actors), both business and IT need to find a way forward that maximizes value and minimizes friction. The risk to those organizations that cannot make this transition increases with each passing day.

Getting a handle on IT costs by eliminating chargebacks?

A recent article on listed recommendations from Gartner analyst Ken McGee on cutting costs and improving the tracking of the expenses that remain. In all, McGee outlined 16 items:

1. Measure IT projects against the CEO’s priorities and see if they match.
2. Look at how the company makes money and compare that to the projects that IT is working on, and terminate support of projects that will not improve the income statement.
3. Abandon CIO priorities that do not directly support the CEO’s priorities. The CEO’s priorities are predominately revenue-related, where CIO priorities are mostly cost-related. An example might be a CIO who is focused on improving technical infrastructure, versus a CEO who has set a priority of being more open and collaborative with customers. McGee’s advice is “to end those discrepancies.”
4. and 5. These two are combined: Stop recommending IT mega projects. “You don’t have the money,” McGee said. Instead, discover the weaknesses in the existing portfolio and where investment is needed, he said.
6. Make people accountable for IT spending. Have business units acknowledge, with a signature, the ongoing cost of an IT service they need.
7. Terminate applications that aren’t delivering value. Gartner estimates that operating expenses can be reduced by 20% by 2014 by decommissioning applications.
8. Stop the practice of putting all enterprise spending within the CIO’s budget. It obscures the IT cost of business units. “The CIO ends up being a pinata for the entire organization,” McGee said.
9. IT organizations need to create processes that prevent “surprises,” which disrupt the business model. McGee introduced this point by showing the cover page of the Borders Group bankruptcy filing. It took that company three years to respond to Amazon’s Kindle, he said.
10. Eradicate ” cloud -a-phobia.” The number of organizations that will deliver 100% of their IT services internally is over, said McGee, but there remains a stalling phenomenon.
11. Abandon level 1, 2 and 3 tech support, where the more complex the problem the higher the skill level sought to address it until it reaches the people who built it. Calling a high level of support is like calling an automaker to pull the person from the assembly line who built the part to fix the problem. “This is what we do every single day in IT,” McGee said. Most application staffs are oversized to compensate for the interruptions, and operations staffs are undersized because of their co-dependency.
12. Cancel most IT chargeback systems, which take an extraordinary amount of effort and expense to charge back what is a small amount of revenue.
13. Stop seeking competitive bids. Most companies keep their existing vendor. “The number of people who absolutely terminate their network services contract, for example, and go to a new carrier is a very small universe,” McGee said. The multi-step RFP (request for proposal) process is ineffective and time consuming. Instead, users should reach out to a consulting firm or to their peers for insights into the competitive landscape.
14. Stop holding onto unfunded projects and send them back.
15. End discrimination against behavioral skills and social sciences. Social networks and contextual computing will require training and people with new skills to augment IT skills.
16. Abandon IT’s unbalanced support between the front and back office, which might lead to a “back office CIO” and a “front office CIO.”

While there’s a wealth of debate in that list, I found item 12 interesting when compared to the others highlighted above. How does one balance costs and benefits after killing the system that allocates those costs out? Item 2 contains two obvious fallacies: first, I’m fairly certain that support of the payroll system doesn’t “improve the income statement” (yet who’s willing to propose killing it?) and second, without being able to accurately identify costs of initiatives, how do you calculate an accurate bottom line? Item 6 has the same problem; how do we have a business unit acknowledge their costs if we do not quantify those costs? Item 7 suffers from the same issue as well. I’m all for retiring applications that have outlived their useful life, but without hard numbers on the costs, how do you determine your savings? For item 14, if we’re not charging back for projects, when we have an unfunded project, to whom do we “send them back”?

I’ve saved item 8 for last. I heartily agree that having all IT spending in the CIO’s budget will make it extremely difficult to determine how much of the costs of IT are attributable to the various business units. One way to alleviate this problem might be to have those business units budget for their needs and then have the provider (internal or external) bill them. Of course, that might break down when you kill the system which actually bills the business units. I am at a loss for how someone could put those two items in the same list.

One of the best reasons for charging back IT costs is stated in a January 2007 article by Mark J. Denne:

If IT is to be perceived as valuable, it has to have a price. Usage-based chargeback is the best way to build a price-to-value relationship for IT services, and it is one of the cornerstones for running IT as a business within a business. As long as IT has a solid understanding of its operating costs, it can use pricing as a strategic tool for improving alignment with the business by giving executives better understanding and control over IT resources.

McGee’s item 6, acknowledging costs, is insufficient. Having the business units actually bear the cost is key. When the business unit is actually paying for services received, it becomes invested in getting value for its resource usage. Project cost overruns that affect your own bottom line are much more likely to get your attention than when they impact someone else’s budget.

Another advantage is making IT services fungible (within the limits of the enterprise’s architectural standards). Although this may not sound like an advantage at first blush, in the long run it works in the favor of the internal IT organization. It forces that IT organization to become both customer-focused and cognizant of the need to provide demonstrable value. When the business is put in the position of choosing an internal IT provider rather than being forced to use them, then the relationship dynamic changes. Both parties then have a vested interest in working as partners.

But Chuck Darville says chargeback helps him run IT as a business. “We look to see if someone can do IT better, faster and cheaper,” says Darville, technology planning director at Southern Co., a consortium of five power utilities in Atlanta.

Southern’s approach is driven largely by IT’s desire to offer market-competitive products and services. IT managers benchmark products against those of third-party vendors to “ensure that our internal IT offerings are the best deal for the company,” Darville says.

For example, the cost and quality of a network service performed internally would be compared with outsourced services available from providers such as AT&T Corp. or Sprint Corp., he says.

(from “The Chargeback Conundrum”, Computerworld 2/14/2005)

What you want to avoid is passing on costs without any sense of control on the part of the user (emphasis added):

Ultimately, chargeback is meant to prod users into changing their behavior. If a chargeback system fails to accomplish that, it’s a failure, no matter how good the accounting is. Chargeback is wearily familiar to Keith Kaczanowski, vice president of process improvement at Brady Corp. of Milwaukee, a manufacturer of signs, labels and associated printing equipment. “If all you do is reshuffle costs within the company, then chargeback probably isn’t worth it,” he says. “But if you think that people will make better decisions by being forced to confront the cost, then there is value.

“We used to charge $X per person per year, but found no one changed any decisions,” concludes Kaczanowski. “Instead, they just grumbled about a perception of low value. So now we don’t charge out at all.” It was, he adds, “pretty much a consensus decision. A lot of our IT expenses turned out to be for enterprisewide activities, servers, WANs and enterprise applications. Taking it back does a better job of matching where the decision is taken to where the costs are.

(from “Budgeting – Chargeback for Good or Evil”, 3/1/2003

McGee’s rationale for ending chargebacks is that they “take an extraordinary amount of effort and expense to charge back what is a small amount of revenue”. However, over a third of his points involve getting a handle on costs so as to manage them more rationally. This would appear to be an argument for improving systems to capture costs rather than eliminating them. Automation, which an IT shop should be familiar with, should reduce the expense. And while it costs money to track expenses, at the end of the day, attempting to run an organization (IT or otherwise) on intuition rather than information may well turn out to be the most expensive option of all.