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 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…]

A rational CapEx purchase and tracking process for IT

How often does someone in your company (often the CIO, or the CTO, or the head of infrastructure) end up running through the halls, waving a purchase order that “has” to be signed off that very day, or else key systems will allegedly go dark? Maybe you’re in the fortunate situation of being in a company where this frenzy doesn’t happen, but in my experience, that’s unusual.

I’ve written before on the importance of technology carefully shepherding its fiduciary responsibilities. Nothing contributes to the IT stereotype/stigma as much as a loud demand for a major purchase, at the last minute, justified solely by dire predictions of doom, and topped (often) with acronym-laden technobabble. Amazingly, it’s not that hard to avoid this situation, if you exercise a little forethought and planning.  The benefits of doing so are indirect as well as direct: you can change perceptions of IT into being viewed as a partner of business concerns, rather than as a troublesome, risk-fraught, and confusing cost center.

It all goes back to Management 101: plan the work, then work the plan. Surprises are a bad thing. Not only do you need a solid plan, but then you want to diligently track actuals against that plan. None of this is exactly a radical idea, yet I’ve served as an executive now in at least three different companies where none of it was happening before I arrived, with respect to capital expenditures.  To the extent there was a capital expenditure plan for the year at all (as opposed to just one big CapEx number!), it had been thrown out the window by February. Sure, this can and does happen in fast-paced Internet companies in particular, but the rankling thing was that no one really was tracking the changes against plan, or could envision how funds were shaping up for the year. Even if a plan has undergone radical changes, there still needs to be a current plan. Walking in, any executive (not to mention any auditor!) should be able to see one or two core documents that detail that current plan, as well as the progress against it.  If that’s not there, then the technology area (and by extension the whole company) is just operating by the seat of its collective pants, and that’s not acceptable.

Here are the minimum elements of responsible CapEx stewardship, in my view:
[Read more…]

Mantra for IT: “Participate in the process rather than confront results”

Let’s sail into a stretch of a metaphor this time. You probably know by now how much I embrace metaphors as a way to impart, often via a concrete example, ideas and concepts that are hard to grasp. So let’s go way back and talk about a metaphorical influence from long ago.

When I was in early high school, we would occasionally spend English class watching and then discussing a variety of short subject films, many of them from the fertile minds at the National Film Board of Canada.  Some of these films, described by the NFB as “socially engaged documentary”, bordered on (or transcended) the bizarre; they thus spurred all sorts of avid arguments among teenagers, easily as much as Ethan Frome or Wang Lung, the more literary staples of the curriculum that I can remember from that year.  There was one such film in particular, in fact, that has stuck with me for decades.  After some digging, I’ve finally been able to identify it by name and origin.  The researchers at the NFB have now kindly confirmed for me that the film is titled “I.B.M.”, and that it was directed by Jacques Languirand. When I reflect on it, the film’s staying power with me makes sense, since it not only features IT elements, but also serves admirably and in multiple ways as a metaphor for IT issues.

As I recall the five-minute film, it features an unchanging close-up view of an automated keypunch machine, punching out a series of IBM computer punchcards with a mysterious and incomplete common message. The film shows the cards sliding into place and getting punched, one at a time, then rolling off into the output hopper. Only parts of the full message can be read at first, since some of the letters of each word are omitted or obscured. Little by little, though, over the course of the film’s duration, each successive card that is punched contains more and more of the message, until it becomes clear at the end of the film that the text reads, “Participate in the process rather than confront results.”

Think about the wisdom and depth of that line: “Participate in the process rather than confront results.” Three ways come to mind of relating this metaphor to IT, to its role across the enterprise, and even to effective IT management of staff. They share a common aspect: the duty (and the reward) of emphasizing participation over passive observation.
[Read more…]

Getting an IT assessment: pitfalls to watch for

One key ongoing goal of mine is that I constantly strive to pay attention. In this case, specifically, through web logging reports, I can see the Google searches that drive people to this blog every day.  One of the most common of these, it turns out, is people searching on the phrase “how to improve IT department”. Another is “IT assessment”.  I somehow picture bleary-eyed CEOs and COOs, late at night, pondering how they can get more throughput or better results from IT, and turning to Google in their frustration.

Since it’s in essence a frequently requested topic, let’s talk about it.  I’ve been on both ends of such assessments, multiple times.  I’ve done them, and I’ve had them done for me.  Before entering into such an assessment, it’s worth considering some of the surrounding issues and common pitfalls.

[Read more…]