Skip to main content

Dodging the Cutbacks

Dr. Jimmy Schwarzkopf (IT analyst) wrote...

Today I visited a client whose IT budget is no more than 1.6% of its revenues. His boss asked him to cut 20% of the capital investment and 10% of the operational budget (a total of 10% compared to budget 2008). In order to do this the company will stop projects that could have increased revenues, some that could reduce costs and some cuts would increase the risk of IT failures. Now my thoughts: By cutting 0.16% of revenues (as expenses) the company lost much more. Does it make sense to cut IT without a real analysis???


Clearly this company has designated IT as a pure expense center and utility service provider. As far as the business management is concerned, IT is no different than:

Facilities Management - Tell them to cut and they can eliminate the office plants and cut back on window cleaning.

Cleaning Service - Tell them to cut back and have a somewhat less clean office.

Security Service - Lock a few more doors inconveniencing how people enter the building but doing with less security.

Travel Expenses - Tell employees to travel less, stay in cheaper hotels, eat cheaper meals.

In this mindset, from IT... the network won't be any faster next year, the business doesn't really care. Desktop computers may be changed less often, again the business doesn't really care.

This client's IT department has failed to explain or demonstrate that they offer a business advantage, rather than just being a necessary burden for operation. IT management practices have allowed the business to categorize them as expendable. At this organization, interaction with the IT department is a major hassle. You describe what you want, you get something else. You pay IT budgets but see no measurable (from your business department perspective) value.

This IT department is divorced from the business drivers.

The result in the U.S. of such a positioning in the past resulted in complete outsourcing of the IT department at some companies (to EDS or IBM GS or Perot Systems, etc.) In the current downturn, we see some major companies having overall corporate layoffs at one level, say 10%, but IT layoffs at a higher level, say 25% (example of this: Metlife). In this model, improvement of business efficiency or opening of new sales or product channels via IT is not seen as a key factor to business survival.

Alternatively, IT is seen as fat and inefficient. Lack of flexibility of old designs, complete lack of systems architecture (as opposed to haphazard system building), and mis-alignment with business goals has resulted in many an IT organization that indeed is expensive and rather unresponsive to business needs.

However, as Dr. Schwarzkopf noted, a lack of analysis of how or why one's IT department is like this and just going for the big cut (instead of targeted surgery) will hurt many a business's future. (Of course, if a business is struggling to survive the year, such concerns are irrelevant.)

If you want to dodge the cutbacks of the future, make sure you the IT person understand what the business concerns and drivers are, and can demonstrate how you are helping to achieve them. Then DO demonstrate it, both in actions (deliver for your business) and in presentations (make sure they know it!)

A brief expense story: While working for a US Fortune 50, to save money the company decided to relocate several thousand employees out of New York City due to the office expense. The employees were scattered out to different offices depending on where the majority of the department lived - some going north to upstate New York offices, some going west to New Jersey offices, and some going east out of Manhatten to cheaper parts of the city.

The following year the company saw travel expenses explode as employees travelled around between 6 offices to meet and do their jobs. So they announced travel restrictions. The following year the company saw conference calling expenses explode as employees compenstated for the travel restrictions by engaging in long multi-office conference calls to do their job (which went even higher as due to the length of such calls, people wouldn't get together in a conference room but all call in from their desks to multi-task). So they announced an effort to cut down on... Finally they analyzed what groups needed to work together, reduced the number of offices people were spread about, returning to the original efficiency and reducing the travel and conference expenses - 5 years later.

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider