Starting points for the quantitative CIO: downloadable basic tools

Much as in any field, IT executives constantly have to seek a balance between idealism and pragmatism. Given a particular problem and the range of possible solutions, do we insist on “doing it right”, or do we buckle down and “just get it done”, even with gaps?

There’s obviously no single right answer, which is what makes IT consistently so fun and frustrating at the same time. Over time, though, my own approach has typically been to focus on the continuous improvement aspect of “doing it right”: whenever possible, get something going as a start, then hone it over time as you learn more about the problem and your situation.

Using spreadsheets as a management tool definitely falls on the “just get it done” side of this spectrum of approaches. Spreadsheets are seductively easy, omnipresent, and usable by people with a variety of skill sets and technical savvy.

But there’s a host of downsides: spreadsheets are frail creatures. Errors can creep in fairly easily, even for experienced users, as data and circumstances change, and spreadsheets are especially prone to the incursion of silent errors and omissions when undergoing revision.  And once implemented, in all their imperfection, spreadsheet-based solutions can broaden and become large-scale, long-term systems (I’ve seen this happen again and again).

Yet, I feel that every technology executive should be maximally fluent in spreadsheeting: simple tracking, analyzing, modeling alternatives, understanding costs and risks. The technology provides a readily available, easy way to knock out quick and dirty models that can clarify one’s thinking and approach enormously. They work well, as long as you keep in mind that the spreadsheet is usually a stop-gap, for those times when you are faced with a glaring need and you don’t have time, budget, or staff to implement anything deeper right away.

In an early blog post, I listed the seven areas where a quantitative approach is especially necessary for the technology executive:

[Read more…]

“No IT projects”? A practical take

If you follow the news, it’s quite clear that we’re in the “silly season” of politics, that time when people eagerly grab hold of any questionable statement of their opponent and use it to extrapolate rank incompetence or dastardly intentions (or worse). Language is frequently quoted out of context, definitions become blurred, things get inappropriately juxtaposed. We’ve all seen it.

That’s why they call it silly season. And that behavior isn’t just true of politics, but also can appear in normal business life, on Twitter, and (often) in IT matters as well. When I run across items I disagree with, though, I try to remember that rather than expressing categorical disagreement (let alone outrage), it’s far more useful to look first for common ground, then aim to identify the areas of contention or difference in perspective. That struck me recently when I read Todd Williams’ (@BackFromRed) recent blog post with the title “Stop All IT Projects!” and recalled that another esteemed colleague, Steve Romero (@itgEvangelist), has expressed views along the same lines.

Todd and Steve are both smart, experienced IT professionals whom I highly respect. In Todd’s case, we’ve met in person; in Steve’s, we’ve exchanged numerous emails and blog posts over recent years. Both of them unquestionably “get it” when it comes to IT matters. I generally agree with what they post or tweet; they’ve each written books that I recommend to others. In fact, I even agree with much of what Todd writes in this particular post. But still, with consummate respect, I think these colleagues (and others) are picking the wrong battle when they insist so staunchly on “no IT projects”. Here’s why.

[Read more…]

Valuable vs. fun: learning to love IT Asset Management

My attitude is that if you push me towards something that you think is a weakness, then I will turn that perceived weakness into a strength.

— Michael Jordan

As with so much in life, so it goes with IT: the parts that are fun aren’t always valuable, and the parts that are valuable aren’t always fun. Let’s talk about a hugely valuable side of IT that isn’t really much fun at all. And when it’s not fun, that means that it’s often neglected, and thus turns into a great weakness.

IT assets (hardware, software, systems, services) represent a major investment for most firms today. For “new economy” companies in particular, the cost of such resources (both bringing them on board and maintaining them as corporate assets) often exceeds expenditures in any area other than wages and benefits.

It’s astonishing, then, that firms (not to mention IT management specifically) don’t always embrace the ongoing hard work required to maximize the value of those expenditures and minimize the corporate risks involved. All too often, I see IT asset management (ITAM) neglected by IT executives because, well, it involves a discouraging amount of drudgery to do it right, especially over the long haul. This neglect occurs even more often when an executive succumbs to the latest faddish push for IT to focus on strategy and innovation to the detriment of fundamentals.

[Read more…]

Mending Wall: Matches and mismatches in IT stakeholder expectations

Oil and water? Some days, the disconnect between stakeholder expectations and IT capabilities (and sensibilities) seems staggering.

Case in point: I was shown an astounding list of generic stakeholder expectations a while back, drawn up by an obviously frustrated group and titled “USER REQUIREMENTS FOR IT”.  The list is most interesting in what the items reveal between the lines. Let’s examine what probably caused this group to write down these specific but very abstract needs.

User requirements for IT

  • Must be adaptable to business situation
  • Must be able to employ multiple SDLC (Software Development Lifecycle) techniques as the situation dictates
  • Must be able to work in a highly parallized (sic!) environment
  • Must be able to accept and adapt to last minute scope
  • Should have multiple channels for functionality development both in terms of large releases and off cycle enhancements that occur in parallel.
  • Must provide the ability to externalize functionality to external teams to quickly develop new functionality
To most IT professionals, these come off as “unreasonable” demands at first examination. But they’re both understandable and revealing, if you take the stakeholder point of view, and if you remember the oft-cited adage that all progress depends on the unreasonable man.

The CIO and the fine art of vendor negotiation

“Don’t write about that,” I’ve been told by several colleagues, when I’ve mentioned that I was working on a post about how best, as the senior technology executive, to negotiate with vendors.  “You’ll give away all your tricks!” they’ve said.

Well, actually, no.  Here’s the main trick: this particular CIO doesn’t have any “tricks”, if by tricks you mean ways to outfox the opposition, or anything else that is best kept secret.  In fact, I’m not a natural avid negotiator. I’m not one of those people who looks forward to buying a new car because of the thrill of haggling with the salesperson.  But I’ve learned over the years how negotiations can best be structured for the optimal outcome.  Like cryptography, where greater obscurity isn’t equivalent to greater security, successful negotiation isn’t dependent on tricks or subterfuge.

I’m quite content to tell any vendor or salesman how I go about negotiating, because doing so doesn’t provide them any kind of advantage.  If anything, it’s beneficial to me and my company that all parties in the negotiation understand clearly the basic principles and approach that I’m using; it cuts a lot of the normal gamesmanship out of the equation.

[Read more…]

IT transparency is good. But how transparent should you be?

A few years back, I had an extremely surprising and unpleasant experience as CTO. The director of my Program Management Office ran a weekly status meeting for project stakeholders, where we’d all methodically go through the current project portfolio, in order to communicate on issues, gather necessary feedback, and align everyone’s expectations. I typically attended in order to provide input and executive-level decision participation, but left it to the director to actually run the meeting and present the topics.

Unfortunately, immediately before one of these weekly meetings, that director was given bad news (in a brief hallway conversation, no less) about a major bug that had just been discovered in the software for our highest profile project, which was currently in testing and due to launch in just a couple of weeks.  This project, with its strategic and revenue-enhancing potential, was foremost in the minds of everyone in the company.  Stakes were high, in other words.

[Read more…]

The Practical CIO: Difficulties in project prioritization & selection, part 2

OK, let’s assume you’ve gotten great at picking the right projects to do to benefit the company. How do you know you can actually accomplish the ones you’ve picked with the resources you have? If you’re like most companies I’ve seen, it’s done on a wing and a prayer. But there’s a better way.

Last time, I wrote about ways to pick projects that satisfy the company’s “SHOULD do” dimension: ones that are strategic, financially beneficial, risk mitigating, or legally mandated, for example. I set out practical guidelines for the process of selection in that dimension, to ensure as level a playing field as is possible.  And I left it for this follow-on post to discuss prioritization from the perspective of the other dimension, the “CAN do” dimension, which needs to calibrate the list of chosen projects to what can actually be accomplished by the available resources.

Both dimensions inform each other, of course; they’re not independent or sequential. In other words, the company might be able to tackle five smaller projects rather than one huge project, and figuring out if it’s a good idea to actually make that trade-off will be based on executive judgment of the benefits in both scenarios.
[Read more…]

The Practical CIO: Difficulties in project prioritization & selection, part 1

How does your company pick which projects to undertake?  Demand outstrips available resources: nearly always, there are far more “good ideas” for things to do than can actually be done in a given time period.  So how do you decide which ones you take on?

If you research this general topic, you’ll find a lot of rather intricate, idealistic screeds that detail how to model an admixture of financials, market potential, risk factors, etc., and promise that this will get you “the” answer.  I don’t dismiss the importance and general validity of such approaches, but let me be frank: that’s actually not what usually happens at most companies. Not even close. Here are some real-life (albeit generally unsuccessful) approaches to project selection that I’ve seen in real companies. In no particular order:

1) Do ’em all: everything proposed by anyone goes on a list, and people just work like crazy and do the best they can to accomplish whatever;
2) Let a single executive (CEO, CIO, CTO, whoever) decide. That’s what executives are there for, right?
3) Insist that all proposed projects be evaluated for ROI, and do the ones that produce the biggest ROI number.
[Read more…]