CIO job rotation and commitment to IT value

Great interview by Linda Tucci at searchCIO.com (here) with Richard R. “Rick” Roy, CIO at CUNA Mutual Group about his experiences as a line manager and how they’ve transformed his IT leadership approach.  This passage on a shared sense of urgency struck me:

I think the other thing in operations is the sense of urgency. In your customer service centers, the phone rings and you either answer it within your service standards or not; you either resolve the question within your service standards or not, or pass it on to another level of service.

IT operations has that flavor to it, but when you get over into the application development world, it typically doesn’t. They typically are working on projects that can span months, if not quarters, even years. Trying to drive that sense of urgency is probably the other big reminder for me as I have come back into the CIO seat.

Roy also hints at something PMOs need to do better: maintaining the same pace as the business.  A PMO needs processes that are nimble enough to keep up as the business responds to the market, competition, etc. by “adjusting and going perhaps in a different direction.”

Advertisement

IT and matrixed organizations

Comments are great for me, because they remind me to check out blogs and other content I’ve neglected.  To that end, I finally bopped back over to Lui Sieh’s blog (here) and immediately saw a timely post on the role of the CIO and IT in matrixed organizations (here).

IMO, IT is plenty matrixed already in most firms, though I wonder how much thought went into many of these organizational designs.  In particular, there is traditionally a ton of emphasis placed on the direct reporting line of the CIO.  However, is that reporting line really as important as the relationship of the CIO’s direct reports to the business?

In other words, there are always risks in CIO reporting relationships — e.g., to the CEO can mean that IT gets too detached from day-to-day execution, to the CFO can mean too much emphasis on cost cutting, etc.   But a well-designed and well-aligned set of relationships among IT business partners — who should report to the CIO — and senior business leaders can mitigate this risk.  It is this second layer of governance that is critical.

In fact, this approach should extend to PMOs, where the IT PMO should be linked into PMOs covering research, marketing, capital projects, etc. to ensure appropriate understanding and prioritzation of initiatives across the enterprise (where via a formal or virtual enterprise PMO).

The SAP/Oracle Choice re: Integration

With the release of SAP Business Suite 7, the debate about the SAP and Oracle integration strategies has heated up.  Loraine Lawson at IT Business Edge (here) uses two posts by Ray Wang (here) and Dan Woods (here), to contrast the two approaches.

Of course, I agree with Lawson and Woods that the SAP approach is better :-).  I also agree that the Forbes audience — C- or high-level business folks — will eat up the SAP message.  However, IMO, it isn’t quite so simple.  Per a paragraph from Woods’s Forbes piece.

Companies implementing new applications or consolidating many companies must ask which foundation is best: a productized and unified platform for business automation or a collection of products that needs to be integrated. Best-of-breed is another way of saying that the user, not the vendor, is responsible for integration [emphasis mine]. 

My experience is that some firms and industries like to have that responsibility and chafe at having processes “pre-integrated.”  Again, I don’t think that is a great default position — one ends up automating non-differentiating processes nearly from scratch — but many pharma and financial firms in particular have tried to “grow their own.”  It is a legitimate strategy if you are truly creating competitive advantage via custom development and integration.

What SAP has done with the Business Suite and its business process platform strategy is to accommodate that desire to be different.  Enterprise SOA allows such customers to get the benefits of process integration without forgoing the capability to differentiate (by assembling or building enterprise services on top of the platform).

Manager-Leader Gap in IT Strategy

A leader, a manager, and a business person?

An illustration of the manager/leader gap discussed earlier (here) is drawn in this back-and-forth among Glenn Whitfield (here), Andrew Meyer (here), and others.  All good stuff, though the last two comments on Glenn’s post — from Long Huynh at CIO Assistant and Glenn himself — get closest to my perpsective.

The idea that a CIO can perform well by operating with one style is pernicious.  Unfortunately, many reinforce this idea — see this State of the CIO 2007 feature from CIO Magazine that identifies CIO archetypes (and even offers a “self-assessment” tool for self-archetyping).

I wonder…how can a single-archetype CIO be successful when his/her IT portfolio must contain very disparate types of projects and programs (e.g., “stay in the game” vs. “win the game” vs. “change the game” initiatives)?

Podcast on barriers to successful IT/CRM

Michael Krigsman over at IT Project Failures hosted the first in what he hopes will be a regular series of “Town Hall” podcasts (here)  It was originally supposed to be a meet-up, but the weather was dodgy at best so the session went virtual. 

Anyway, Paul Greenberg moderated an excellent discussion that covered a lot of ground.  As Michael notes, Paul’s CRM background focused the conversation

…on issues drawn from customer relationship management. CRM brings together core business functions — how a company interacts with customers — with technology intended to streamline and improve those relationships. Since these goals are business-oriented, CRM offers excellent examples of non-technical failures connected with technology implementation projects. For example, one participant noted corporate managers sometimes deploy CRM hoping to control end-users, who in turn reject the system in a predictable failure. 

Be warned… I jump in at about the 30 minutes mark!

More on saying “no” to customers, stakeholders, etc.

Pawel Brodzinski had a good comment (here) on my post about saying “no” the right way (here), which links to his post laying out his full perspective on the customer is always right principle.  I replied to his comment — agreeing with the principle, but cautioning on its application — which I’ve posted below:

Sometimes it is about saying no — or as the Japanese say “Yes, but.” There are times when we don’t take business, especially when we are being “forced” to do so. But if we aren’t taking their money, is that customer really a customer? IMO, no, at least not for that topic.

Of course, I agree that the customer is always right — which makes it critical to be choosy about one’s customers. But the application of that principle is tricky. PMs who allow scope creep to happen on their projects often justify it with a customer service rationale — “the users asked us to build it.” But are the users really the customer of the project? Aren’t the executives who chartered the project and the company they represent the customer? Too many IT staff and PMs are very confused about who is the “real” customer.

Troubled Projects and Engaging Change Stakeholders

Glen at Herding Cats (here) points to a Center of Business Practices study (here) on the causes of troubled projects.  I’ve posted on some of our own findings about project success (here and here), but I haven’t elaborated on what we’ve found about the composition of change control boards.  Below is an extract from a comment I made on Glen’s post:

Our project debrief analyses have consistently found that the right level of executive presence on change control boards is essential to ensure change is managed, not simply documented. In fact, the lack of such a presence (or regular absences) marks the project as a potential escalation.

When a senior manager vets the prioritization of changes by focusing the project team on the project’s goals and intended outcomes — one should usually find scope, time, and resource changes easier to manage (with fewer, more salient change orders). It also keeps the business invested in the project. Many IT shops resist this measure, but it works wonders once they “get it”. 

The ultimate in IT inside->out thinking

Geek and Poke exchange IT and business spells

Michael Krigsman post on the IT Utopia (here) makes a good bookend to my post riffing on Esther Dyson’s “worker’s paradise” quote (here). 

Talk about an inside->out perspective!  It is as if the IT person expects that once he/she invokes a technology incantation the poor, slow, business folks will bow to their masters in gratitude.

While business counterparts have an obligation to get the implications of technology, technologists must in turn rouse themselves to help the business make that connection.

IT/Business Marriage Counseling

I agree with most of Susan Cramm‘s pieces, but she goes on a bit of a rant on the role of line managers in making IT’s life impossible (here).  While there is at least a grain of truth in her complaints, the IT “can’t do” attitude that infuriates line executives pervades the piece.

IT managers are tired of being treated like high priced waiters serving technology de jour on a moment’s notice.

Perhaps IT managers should stop acting like waiters and order takers for the business. It would be nice if IT wouldn’t “need to study” a request to deploy only somewhat new technology — e.g., Enterprise 2.0 — then come back and say “yes, but”.  Perhaps IT could anticipate what the business needed, for once?

Luke’s business “partners”… in their single-minded pursuit of customers, products and profit [emphasis mine],… simply forgot about IT.

If only IT knew what it’s like to have a single-minded pursuit of those pesky customers, products, and profit.  Not like that’s where their paychecks come from…

Alignment is meant to ensure that the right IT products and services are available to meet business needs with minimal angst for all involved [emphasis mine].

This definition/goal sounds good, but articulates a common IT mistake about defining alignment — avoiding conflict (“yes, but”). 

The problem w/ “gold-plating”

We had a discussion of gold-plating in project management during my leadership team meeting last week.  To refresh everyone’s memories, here’s a good, if informal, definition of the term (link here):

Gold plating is what we call it when the project team does work on the product to add features that the requirements didn’t call for, and that the stakeholder and customer didn’t ask for and don’t need. It’s called “gold plating” because of the tendency a lot of companies have to make a product more expensive by covering it in gold, without actually making any functional changes.

Andrew Stellman at Building Better Software has a post on why gold-plating is a bad name (post here).  It is an excellent discussion of what the right analogy is — he goes with a combination of gold-plated (a purely cosmetic veneer) and “gilded” (encrusted with useful, but largely-unused features).  Andrew’s bottom line is that such features are “just wasted effort, at least from the perspective of the person paying the programmer’s salary”.

I would say the bottom line is even more stark: gold-plating or gilding not only wastes money, it risks delivery of core deliverables.  Enterprise software projects usually must be delivered by a date certain.  I’ve found that development teams that get distracted by superfluous gee-gaws do so at the expense of priority features.  In other words, not only does gold-plating waste money, it diverts resources from ensuring that deliverables conform to requirements.