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.”

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

So who is the visionary in this bunch?

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)?

Interview on PMOs by Michael Krigsman

Last week Michael and I had a great discussion on PMOs — what they are and how they contribute to IT governance and project success.  In particular, the SAP PMOs have a unique role in optimizing the success of the entire SAP ecosystem…otherwise, relations among the stakeholders can devolve into what Michael calls the IT Devil’s Triangle

The post and podcast (player is at the top of the post), are here.  Thanks to Michael for arranging this and for even taking a good photo of me!

Does a leader change only people?

Eric Dana Hansen added a comment to my recent “Manager vs. Leader definition” post.  In it, he refers to a work of his that touches on leadership.  If I’m reading him right, his take is that

management is based upon processes, order, and controls and that leadership is more about developing the potential in others. 

In my comment, I agreed with the first part about management, especially its emphasis on order and controls. However,

I’m don’t buy into leadership being strictly about people….  The reason I like the “Stultz” definition [referenced] in the post is [that] in changing the system, leaders must acknowledge and address all segments of the “people, process, technology” triad.

Also, the blogosphere must be on a manager vs. leader kick.  I just noted a couple of posts by Glenn Whitfield (here) and Andrew Meyer (here) that touch on an interesting dimension of the topic: IT strategy and alignment.

I’ll comment more directly on those tomorrow.

SAP Business Suite 7.0 — life w/out upgrades?

I haven’t a chance to dig into the details of SAP Business Suite 7, but it looks very promising w/r/t implementation costs and other TCO drivers. The enhancement package approach was a great start, but the new Business Suite should be a more comprehensive breaking of “the upgrade barrier” (per Ed Toben of Colgate-Palmolive).

Here are a couple of videos on the new suite: Jim Hagemann Snabe on the strategy (here) and a SAP Business Suite 7 demo (here).

Transparency in analyst analysis/ratings

Doug Henschen highlights (here) one of the mysteries of the analyst business — just how are those ratings calculated?  To Doug’s eye, Gartner’s 2009 BI platform Magic Quadrant’s rating of the combined SAP Business Objects portfolio does nothing more than split

the difference between its 2008 positions for SAP and Business Objects, as if SAP dragged Business Objects down from its front-runner status. In its “cautions” for SAP, Gartner cited… problems [that] were all evident (and cited by Gartner) last year, so I’m not quite sure what to make of the new position.

I share Doug’s hang-up with these types of rating systems — there’s not enough transparency about the “whys and hows.”  I also share his increased admiration of

Forrester’s Wave Reports, which include scoring grids that detail how the vendors fared and compared on as many as a dozen different attributes.  I know it kind of takes the “magic” out of the rating methodology, but in an age when visibility, auditability and good governance are valued, it just seems like a better approach.

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!

Example of saying “yes, but” to customers…

Per some recent comments and posts (here and here) on discussing responsiveness to customers, Henning Kagermann related a story on a call that I had completely forgotten about.  I’m certain that it has been told publicly before, but I’ve disguised it a bit just in case…

In the early 1990’s, SAP was approached by a delegation of firms w/r/t industry-specific improvements to R/2.  They had a list of demands that they wanted to see implemented in R/2.  Fair enough.  That industry was perhaps the core of SAP’s success to that time, so why not do it?  Except that SAP was in the midst of developing its next generation product, R/3.  We also wanted to expand our footprint to other industries and markets.  There was no way we could do R/3 and satisfy much of that list of demands in the current product.

If you know anything about the history and success of SAP, you can guess the answer.  We chose to spend the preponderance of our efforts on R/3.  While some of the key demands were satisfied, most were deferred in favor of ensuring that R/3 got to market.

This example illustrates the challenge well.  Most of the time you should listen to your customers so you can satisfy and delight them.  But listening for too well for too long can mean that you wake up one day and find that you’ve become a no-growth “legacy” business.  Sometimes you need to say “yes, but.”

Follow

Get every new post delivered to your Inbox.

Join 2,518 other followers

%d bloggers like this: