Top 5 CIO Tweets of the Week – September 11, 2009

Share on LinkedIn2Tweet about this on TwitterShare on Google+0Share on Facebook0

The travel doesn’t seem to quit as I hit London this week and will be back next week too.  Here are some of the great CIO and IT leadership tweets of the week that I’ve been able to collect while in the Admirals Club.

[tweetlist:3785207801]

1.  I haven’t heard much from the 1-to-1 marketing guru Don Peppers lately but stumbled on this post.  I like it because it’s not coming from an IT leader, but from someone who advises business leaders and appreciates the strategic role of IT.  One thing that’s wishful thinking for some is that the CIO is a fixture in the boardroom.  I’ve discussed the role of the CIO and IT in innovation with a few clients lately and I think it’s the crux of the challenge.

[tweetlist:3754337838]

2.  IT shops are woefully behind in career development.  Yes, most have some training courses available, but I have not seen one decent example of a career path model that links roles, skills and training.  This is a big opportunity that impacts everything – quality, delivery, staff retention, succession planning, etc.

[tweetlist:3782887517]

3.  This is a great example of the problem with SLAs driven by IT.  Yes, it’s important to have agreements between technology providers and consumers.  So, 5-9s is useful to a small set of enterprise computing staff and vendors.  However, the primary opportunity in making SLAs impactful is in putting service levels in business terms.  “14 minutes down” is a start, but we need to move to SLAs like “100,000 bills per week” and “4,000 customer service calls resolved per month.”

[tweetlist:3895989130]

4.  Jason makes a great point regarding the breadth of roles and responsibilities of the IT function.  I think that the HR function is on par with IT across all of these dimensions, as they have to deal with every employee as their customers, a slew of 3rd party vendors, lawyers and procurement galore and a lot of emotions.

[tweetlist:3797303944]

5.  Russ always makes good, practical points.  Here he argues that stringent requirements for business cases for every project can cause critical projects to be delayed or killed.  I think that some of the challenge here is in the definition of a business case.  All projects are not created equal and won’t yield the same kinds of benefits.  Some are solid ROI projects, some are more experimental and some are costs of doing business.  Each type requires a different kind of business case.  Furthermore, smaller projects need less rigor than do larger, more strategic ones.  I think we need to understand the business impact of ALL projects, but vary the required justification, governance and documentation.

Share on LinkedIn2Tweet about this on TwitterShare on Google+0Share on Facebook0
  • Several comments on this excellent grabbag of CIO-related issues:
    2) Getting funding approved for training in the internet companies I’ve been at, in particular, has been a great challenge. It’s the first thing that goes when budgets are pruned, no matter how hefty the protests. That situation then forces the CIO to pick and choose, from a too-small fund, who will get to go to training this year and who won’t. The CIO can and should champion greater funding here, but in the end, this issue has ownership at the CEO level.

    4) and 1) make essentially related points. And again, in the end it’s the CEO who needs to have the epiphany about the core role of the CIO in the organization’s success.

    5) Countless times, I’ve seen key projects initiated from the top level, absent a business case being even mentioned: i.e., a gut-level strategic decision based on market conditions, competition, etc. That’s certainly their prerogative, and it’ll never stop entirely. That said, it’s still important for the organization overall to instill an ethic of SOME form of business case being completed for every endeavor, and none of us should stop pushing for that. It should never be viewed as slowing down an organization’s agility, except in a good sense: looking before leaping.

    3) I’m of two minds here: yes, business-driven metrics are key, but are also dependent on many external variables, market conditions, marketing drives, new product releases, etc. IT, for all its key strategic value, also functions as a service provider to the rest of the organization, and this shouldn’t be denied in our zeal to be recognized as core corporate strategic contributors. On the services we provide, we need to “show that we’re in control” by monitoring and publishing useful, “full disclosure” metrics. My point in the original tweet was that these metrics should be (as much as possible) in terms that non-technical users can readily absorb and relate to: minutes of downtime in a week are MUCH more “in your face” and obvious than the more abstract representation of “99.45% uptime” etc.

  • Several comments on this excellent grabbag of CIO-related issues:
    2) Getting funding approved for training in the internet companies I’ve been at, in particular, has been a great challenge. It’s the first thing that goes when budgets are pruned, no matter how hefty the protests. That situation then forces the CIO to pick and choose, from a too-small fund, who will get to go to training this year and who won’t. The CIO can and should champion greater funding here, but in the end, this issue has ownership at the CEO level.

    4) and 1) make essentially related points. And again, in the end it’s the CEO who needs to have the epiphany about the core role of the CIO in the organization’s success.

    5) Countless times, I’ve seen key projects initiated from the top level, absent a business case being even mentioned: i.e., a gut-level strategic decision based on market conditions, competition, etc. That’s certainly their prerogative, and it’ll never stop entirely. That said, it’s still important for the organization overall to instill an ethic of SOME form of business case being completed for every endeavor, and none of us should stop pushing for that. It should never be viewed as slowing down an organization’s agility, except in a good sense: looking before leaping.

    3) I’m of two minds here: yes, business-driven metrics are key, but are also dependent on many external variables, market conditions, marketing drives, new product releases, etc. IT, for all its key strategic value, also functions as a service provider to the rest of the organization, and this shouldn’t be denied in our zeal to be recognized as core corporate strategic contributors. On the services we provide, we need to “show that we’re in control” by monitoring and publishing useful, “full disclosure” metrics. My point in the original tweet was that these metrics should be (as much as possible) in terms that non-technical users can readily absorb and relate to: minutes of downtime in a week are MUCH more “in your face” and obvious than the more abstract representation of “99.45% uptime” etc.