eyetoit

Good Reading for you CIO

There is a great interview in CIO Insight with the principals of CogniTech on analyzing the IS contribution to an organization's performance. Unlike the vast majority of blurbs or articles I see about this subject in the IT press (fodder for a future post maybe), CogniTech's Lodahl and Redditt really get it. They founded their business on the same two premises that I do my writing here: "that businesses were going to become more and more dependent on IT, and that IT was being managed incorrectly."

Project Sponsorship Part I: Selecting a Sponsor

Nearly every technology project of any significance in an enterprise needs a project sponsor. It used to be that the duties of many project sponsors seemed to begin and end with securing financial resources for the project. Beyond that point, the role would often become a largely titular or ceremonial one, typically involving irregular attendance at meetings of the project steering committee that might meet infrequently, unless of course the project experienced some sort of crisis - occasionally leading to the steering committee meeting far too frequently for its own good, with plenty of opportunities for recriminations and "blamestorming" (i.e. a session in which everyone contributes to the finger-pointing).

This is an admittedly critical picture of the process, but I imagine many people in organizations are familiar, directly, indirectly or anecdotally with experiences not too dissimilar to the description. While I wouldn’t characterize it as the rule, neither was it the exception.

However, rather than simply dissect what has gone awry in such situations; I believe it would be more constructive to talk about the project sponsor role from start to finish. This should have relevance to a fairly broad audience, from project managers wanting to help their sponsors to CEOs who recognize that effective sponsorship by business executives and managers is a key ingredient to maximizing the return on technology projects.

Because this is a sizable topic, I will be breaking the discussion into a handful of segments. I’m going to start with some quick thoughts on sponsor selection. In future segments, I expect to cover the responsibilities of the sponsor, tips on fulfilling and evaluating the role of the sponsor, and what to do in cases of sponsor nonfeasance (or less-commonly malfeasance). Please feel free to email suggestions for particular areas of the topic you would like to see addressed.

Thinking about IT and the Board

The point of these writings, for the most part, is to offer some insight and observations that business managers, executives and directors of (primarily) non-technology companies to help better manage the role and function of IT within their organization. In October's Harvard Business Review, there is a quite good primer on board-level IT governance written by Richard Nolan and F. Warren McFarlan.

In "Information Technology and the Board of Directors" (p. 96 in print - subscribers can access here - non-subscribers can view an excerpt) Nolan and McFarlan lay out a succinct yet reasonably detailed framework for thinking about key issues of viewing IT as part of the corporate governance function, such as:

• What is the current role of the firm's IT operation - (Support, Factory, Turnaround or Strategic) -  I have always used somewhat different labels - Cost Leadership (Support), Operational Excellence (Factory) and Differentiation (Strategic). Also, I have always excluded "Turnaround" as a independent role because it should be getting turned around to something (i.e. one of the three other types) - but from a governance perspective, the key point is that board should expect to more thoroughly scrutinize relevant issues in a case of a turnaround.
• What sort of questions should the board ask for each type of IT operation?
• How often should they ask these questions?
• What is the role of a board IT expert? (see some of my comments in "IT Savvy Board Representation" from last year)
• How do you establish an IT governance committee on the board?

There are details within the article about which reasonable people can differ, but overall it is really quite a good piece and I would encourage any senior business manager or director to read it and discuss it with their other board members.

The Danger of Illusory IT Excellence

I remember rolling my eyes in August, reading a piece from CIO Insight ("Overstock.com: Feeling the Need for Speed") on how Overstock.com's CIO Shawn Schwegman was running the rootin'est-tootin'est IT shop around. The reason was that it seemed like something out of a time capsule to the late '90's world of Internet time - in all the bad ways - big egos and an apparent dismisiveness of most of what we know about managing business-critical, enterprise-grade development and implementation.

First there was the Schwegman's chest-pounding about implementing a Teradata system faster than Teradata thought possible. How did he do it? Working harder, not necessarily smarter, seems to be Schwegman's way:

Governance by Committee vs Real Leadership

Many organizations have attempted to develop an IT governance framework, largely with the aim of better aligning IT with the business by selecting the major projects and investments for the IT organization. Since I first started seeing this trend, it seemed almost intuitively flawed to me for two main reasons

• The governance framework itself doesn't inherently provide participating business executives with sufficient interest or knowledge to best direct the IT function. The dispersion of responsibility for decision-making across a group inherently reduces individual accountability for outcomes.
• I have a fundamental suspicion of committees as a decision-making tool. My recollection from most organizational behavior research is that committees by and large operate with an effective IQ of the dullest, rather than the brightest, member of the committee.

Now, some might take issue and say that with the right performance measures and incentives, team-level training and selecting the best people, an IT governance committee can provide a reasonable crutch for a CIO unable to really align with the business. I call that making the best of a bad situation.

The (ir)Relevance of a CSci Degree in Corporate IT

Occasionally, someone will express surprise when they learn that I don't primarily hire computer science graduates at my software development and implementation consultancy. In fact, I typically maintain that most organizations would do better to have relatively fewer computer science graduates in their IT organizations than they do. This is one of the reasons I tend to ignore the press about the "troubling" decline in students pursuing C.S. degrees. The only reason it is a fundamental problem is if those hiring the coming generations of IT professionals do not put the relevance of a CompSci degree (or any degree) in context. My hope with this post is to provide readers with some context as to the significance, or lack thereof, of a CSci degree for the typical systems developer in corporate IT.

Why don't I place a premium on specialized study of Computer Science? In a nutshell, it is neither necessary, nor is it typically sufficient, training for a great deal of business systems development.

KISS

This post is neither romantic in nature or talking about the iconic 70's band by the name Kiss. Rather, this is about the good advice of KISS: Keep It Simple, Stupid.

Complexity is one of those paradoxical things that in business tends to be verbally opposed - but actions speak louder than words, and all of us in business have a tendency toward adding complexity just one bit at a time - draining the productive blood from the organization through a series of paper cuts. This month, Ken Keverian, Vikas Tenaja and Bob Victor of the Boston Consulting Group have an interesting article, "As Simple as Possible" [PDF Link] that has some intereresting food for thought on complexity.

While complexity can lurk anywhere in an organization, Keverian et al, seem to see most of it driven by a form of customer-responsiveness. This makes sense, it would be rare (and rather irrational) to introduce complexity for no reason. They provide three quick warning signs to look at your company to see whether you may have too much complexity. Do any of the following sound like your company?

Oversimplified, but true as far as it goes

Paul Ingevaldson has an interesting piece in Computerworld this week, "CEOs: Think Through your CIO Choice," that merit some discussion. In it, he makes the obvious suggestion that choosing a CIO that fits with the firm's needs will make for a longer and more fruitful relationship on both sides.

As my title suggests, Ingevaldson simplifies things a bit too much for my tastes by dividing CIOs into two camps. The first of these is the activist CIO, who in effect says, "Do it my way; no highway option," and expects the organization to agree to his approach. The other type is the collaborative CIO, who seeks to build consensus with other executives and stakeholders to define systems goals.

The Risk of Dark-side CIOs: Crooked Information Officers

The Twin Cities local business paper reported Monday that Buca restaurants announced that they are suing their former CFO (who had resigned) and CIO (who they actually fired after an internal investigation) for all manner of malfeasance including most egregiously, manual journal entries and related party transactions. From the Business Journal:

The complaint alleges that Gadel and Motschenbacher caused the company to enter into unfavorable transactions with companies in which they had undisclosed, material financial interests, causing the company to overpay for goods and services. Buca also accuses Gadel and Motschenbacher of soliciting and receiving undisclosed kickbacks from a vendor, and seeking and receiving improper reimbursement from the company for personal expenses, such as family vacations, that were presented as business expenses.

Hurd Puts In New CIO at Dell; Rethinking Bouchard

Last year, I was a little harsh on HP's CIO at the time ("HP's CIO on the ERP Problem & the Art of Diplomacy") for accepting virtualyl no responsibility for the problems with and fallout from their SAP implementation debacle (which caused them to miss their earnings number because they couldn't ship product (background)).

HP's new CEO clearly felt HP needed a new CIO and replaced Giles Bouchard with Randy Mott (formerly CIO at Dell and WalMart, two companies that effectively use IT to make the trains run on time). Mott's reputation is impressive, and I'm sure he'll do a good job at HP. Of note about this change, however, is that Bouchard is still at HP, as the EVP of Global Operations, which is apparently his area of expertise. The fact that Bouchard was a business manager responsible for IT has caused me to reevaluate my assessment of him, and brings up the whole reason I write here in the first place.