+1 800 985 8533
 

Simplicity 2.0
A no-holds-barred take on trends in the IT industry

What Should You Use for CIO Metrics?

Mar 26, 2013

What Should You Use for CIO Metrics?

The saying goes, if you can't measure it, you can't manage it. However, when it comes to IT, what exactly is it you're supposed to measure? A group of people on LinkedIn's CIO Network group recently had just that discussion, amounting to more than 100 comments.

The discussion fell into several camps, ranging from the people who measure a wide variety of IT metrics such as uptime, to those who said it actually wasn't the CIO's job to measure the department. "The benefits of IT don't accrue inside the IT department so measuring them is not the job of the CIO," writes Bernard Peek, a hybrid/business manager in Manchester, U.K. "This is a job that should be assigned to the CEO."

Of course, there is no single definitive answer, but the discussion itself was interesting and covered a broad span of IT philosophies.

The first aspect, of course, is what is it you're trying to measure? "I'm shocked how many replies have jumped into metric output without asking the key questions a CIO needs to ask," writes Alison Roberts, IT Management Consulting Director for CIO Advisory in Manchester, U.K. "Who are the stakeholders? What are the drivers/goals/objectives? How far along the strategic roadmap plan for current vs. future state? What are the business defined benefits? Each of these answers would require a specific approach to measurement, by and for specific groups."

The second aspect is figuring out what you have now, so that you can determine what's changed, which means figuring out a baseline, and then determining a way to explain that, writes Scott Paddock, IT director for a health provider in Seattle. "If your organization has made significant progress in the area of incident response, but this is only visible/measurable from walk through exercises (meaning your organization hasn't had a high-profile incident, but your preparedness has improved), the stakeholders may not appreciate the gravity of the gain."

CIOs also discussed to what extent key performance indicators (KPIs) should reflect purely IT aspects vs. business aspects. "I'm not suggesting that IT take ownership of a stakeholder metric," write Michael Henry, a Bay Area CIO who led the discussion. "I'm suggesting that IT work with stakeholders to develop KPIs that show how technology is improving parts of the business." If your key metrics focus only on cost, CIOs can expect to be managed on cost, and if they're focused on technology, then the business part of the organization might not recognize the value of IT, he warns later.

"I've heard many ITers espouse how well they're doing based on the 'quants' they track, and report, only to find the LOBs often disagree with their conclusions," agrees Barry Zweibel, founder of Leadership Traction, in Chicago. "'We'll know you're doing well when we stop hearing complaints about IT,' they often say. 'Until then,' they continue,' your numbers are meaningless.'"

The ultimate measurement, of course, is how much people would miss the IT department if it were gone, suggested several commenters, tongue-in-cheek. "If a group sees no value in IT services, just take them all away and try to ignore the screeching, or suggest the screeching infers some sort of value recognition," suggests Doug Goddard, a Toronto CEO.

Comment (1)
| Post your own

Comments

Submitted by Chuck Karish on

Neither the CEO nor the stakeholders can evaluate IT performance without information about what it costs to provide the services that the stakeholders use or about the risks the IT effort faces. It's fine to say that the CIO shouldn't evaluate his own performance, but nobody else can evaluate it without information that only the CIO's team can provide.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <blockquote> <br> <cite> <code> <dd> <div> <dl> <dt> <em> <h1> <h2> <h3> <img> <li> <ol> <p> <span> <strong> <ul>
    Allowed Style properties: border, border-bottom, border-bottom-color, border-bottom-style, border-bottom-width, border-color, border-left, border-left-color, border-left-style, border-left-width, border-right, border-right-color, border-right-style, border-right-width, border-style, border-top, border-top-color, border-top-style, border-top-width, border-width, clear, color, display, float, height, list-style, list-style-image, list-style-position, list-style-type, margin, margin-bottom, margin-left, margin-right, margin-top, max-height, max-width, min-height, min-width, padding, padding-bottom, padding-left, padding-right, padding-top, text-align, text-decoration, text-indent, visibility, width
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.
Run Smarter®