All Posts in Strategy and Tactics

|In: Career Management|Last Updated:

In May of 1996 my InfoWorld column, then called the IS Survival Guide, introduced the technology life cycle: Hype, disillusionment, application. Several years later, Gartner introduced its highly similar “Technology Adoption Curve,” without, I’m sure, any knowledge of my prior art. Needless to say, the Gartner model is the one that’s cited incessantly in the business and IT trade press.

But am I bitter? Nah. Why would I be bitter, just because they get all the credit (and more important, revenue) for an idea I published first?

I’m not bitter, and I’m hurt you’d think I’m so small that I’d feel that way. I am, however, sore from the strain of patting myself on the back, because in what I laughingly call my spare time I’ve been adding columns to the KJR archives on www.issurvivor.com. There’s some good stuff in there, if I do say so myself — ideas that if not original were at least far ahead of their time.

Since this is the start of my ninth year writing these things, I’m in the mood for nostalgia. In that vein, here’s my personal top five list. Next week I’ll stop bragging and get back to work.

#1: The fallacy of internal customers: If I had to pick the single accomplishment of which I’m most proud, it’s the part my column has played in eliminating this sorry notion. I first mentioned the issue in a guest editorial published in InfoWorld in 1994. My opinion hasn’t changed, although it has, I hope, become a bit more sophisticated.

#2: There’s no such thing as an IT project: As far as I can tell, my first commentary along these lines appeared in 1998, and columns ever since have made the crucial point — that it’s always about changing the business or there’s no point to the effort. In the recent debate over Nicholas Carr’s Harvard Business Review article “IT Doesn’t Matter,” this concept assumed center stage among those of us who have replied, “Don’t be ridiculous.”

#3: Debunking bad measures: I first criticized Gartner’s TCO model, then called the “PC Cost/Benefit and Payback Analysis,” in 1993 in my first guest editorial in InfoWorld. The logic stands up well today despite a decade of Gartner’s refining the model, probably because refinement isn’t what’s needed — the model’s problems are basic and fundamental. And while Erik Brynjolfsson is the most influential critic of another example of bad measures — the so-called “productivity paradox” — I got there early (1996) and can at least claim credit as having irritated Paul Strassmann the most for my critique of his assertion in The Squandered Computer that investments in IT don’t pay off. What’s important in this debate isn’t my ongoing desire to say, “I told you so.” It’s the importance, and the difficulty of establishing well-constructed value-based measures of information technology.

#4: The fallacy of big projects: I recall reading, in the early 1990s, about a decision made by UPS to reject any project more than nine months long. I was very impressed, and started writing about “chunking” big projects into collections of small ones starting in 1996. The notion has since become mainstream, I’m delighted to say.

#5: The Value Prevention Society: The underlying idea of this satire — that it’s worthwhile preserving flexibility for end-users so they can continue finding innovative uses for their personal computers — never did catch on. Perhaps I’m tilting at windmills, but I still think locking down every desktop and preventing end-users from developing their own applications is a bad idea.

Honorable mentions go to a few other notions published early: Marketing yourself as a product (preceding Tom Peter’s notion of personal brand by at least three years); the importance of technical sophistication, along with business acumen, for a CIO (years before the CTO title was first coined); predicting the failure of the Network Computer (as soon as Larry Ellison first mentioned the idea); and the importance of IT’s figuring out how to work with the marketing department (1996, long before this became an industry discussion point).

If you’re feeling nostalgic as well, you can find the first four years of my weekly columns, along with the three Peer to Peer columns that started my publishing relationship with InfoWorld, and every Keep the Joint Running in the KJR archives on www.issurvivor.com. My New Year’s resolution is to get the rest of the archives loaded.

With luck I’ll be more successful with this than I was with last year’s resolution to use the treadmill several times each week.

Comments

|In: Organizational Design|Last Updated:

The internal customer is dead. And it’s about time.

I had the pleasure of facilitating a panel discussion for the local chapter of the Society for Information Management (SIM) last week. On the panel were a CEO, CFO, and three CIOs. One question dealt with the preferred relationship between IT and the rest of the business — should IT be viewed as a supplier, a partner, or an “information utility,” whatever that means?

The panel was unanimous: The business works best when IT operates as an equal partner. “Internal customer” has outlived its usefulness. This is a remarkable transformation: Just five years ago, the notion that IT should view the rest of the business as its customer was pervasive.

IT’s adoption of the internal customer model has always required a degree of schizophrenia. “You’re my customer,” and “You have to adhere to our standards and policies or risk disciplinary action,” are awfully hard to harmonize, as is “We need the authority to stop users from loading whatever software they want on their PCs,” with “Our job is to do more than just satisfy our customers — it’s to delight them.”

The whole thing often smacked of a desire to avoid accountability: When you have internal customers, your role is to process orders. Business acumen is Someone Else’s Problem (SEP).

So is recognizing technology-driven business opportunities. As a nice counterpoint, one panelist described a new strategic initiative — the biggest in his company’s history. It’s a comprehensive redefinition of the company’s business processes, intended to consolidate duplicate efforts among its business units. IT first conceived of the effort, and championed it throughout the company.

Think it’s an inappropriate role for IT to take on? If so, ask yourself this: In a complex business, assembled through a combination of growth and acquisitions, what other organization will be in a position to recognize and champion this kind of opportunity? It’s either IT or accounting, and of the two IT is in a much better position to understand business processes.

In the most effective organizations, change is a collaboration between business and IT at all levels. Business and IT leaders collaborate to provide a shared picture of where the organization is going and how it’s going to get there, and to communicate a strong commitment to the effort, including the investment of money, staff and time. Business and IT middle managers collaborate to add the clarity that comes from knowing how the business really operates, and to provide trained, enthusiastic staff to implement the change, and when the time comes to insist that all employees migrate to the new way of doing business. Business and IT staff collaborate to sweat the details that are the difference between a great-sounding concept and something that works.

There are those who think this means dividing accountability, ensuring failure since no individual is responsible for the success of the program. But then, there are those who think that if everyone just does their job as defined by the company’s organizational chart that the business will somehow succeed. Both views are wrong, and for the same reason: To optimize the whole, designers usually have to sub-optimize the parts.

When the subject is business as usual, viewing your job as optimizing your part of the organizational chart means ignoring the larger needs of the business when the conflict with the needs of your department. When the subject is business change, making just one person accountable means everybody else is only responsible for the tasks assigned to them.

Organizational change does require a business sponsor, with ultimate responsibility for ensuring the program succeeds. That’s vital — the buck has to stop someplace.

Everyone else involved has to consider the success of the whole program to be their responsibility as well. If they don’t, it’s certain you’ll hear the equivalent of the defense contractor’s battle cry:

“Oh … you wanted wings on that airplane?”

Comments