Conventional wisdom that fails for IT

I’ve done several posts featuring what I call “Peterisms”, which are basically aphorisms I’ve adopted that encapsulate hard-earned IT lessons. Let’s turn it around this time, and talk about two sayings that sound equally folksy-sensible, and that I hear again and again, but which I feel are actually dangerous to apply to information technology work. And, of course, I’ll discuss why that’s so.

  • If it ain’t broke, don’t fix it
I know of very few aphorisms that tend to be repeated as smugly as this one, particularly by scared people. The implication is that action is generally to be avoided, that the status quo is probably just fine, and that one should wait for a true crisis before intervening. And, of course, that it’s your fault if you’ve ignored this sage advice and intervened anyway. It’s ironic, then, how IT departments themselves end up complaining endlessly about how they’re always in fire-fighting mode.  This prevailing attitude evolves among (and is a telling symptom of) burned-out sysadmins and developers, especially those who are stuck maintaining systems they didn’t themselves write or engineer. It can be equally summed up as a “don’t touch it, don’t breathe on it” kind of superstition. Or, perhaps, it’s akin to the proud but defensive statement that “we’ve always done it that way.”
[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…]

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

Serving your IT customers: be careful of being The Wizard of Oz

Cultural references are among the most powerful language tools around.  The old cliche may be true that a picture is worth a thousand words, but equally, a well-targeted cultural reference, used as an analogy, can stream light onto a subject better than dozens of droning paragraphs of prose.

So here’s one that comes to mind over and over again in the course of IT management: the Wizard of Oz.  And it’s not a flattering analogy; in fact, it serves more as a warning or a reminder of what not to do.

Specifically, think about the Wizard of Oz’s behavior when Dorothy asks him to help her and her friends.  She gets upset when it seems that the Wizard isn’t going to help them, but he assures them that he will, if they do just one little thing:
[Read more…]

Nuts: the biggest trap of all for IT stakeholders

As I promised last time, there’s one more key way, the biggest way of all, not to get what you want from your IT organization.  This is, in fact, the trap I have seen virtually every entity I’ve ever worked for fall into to some degree, some to the point of actually destroying the company.

The trap is perhaps best communicated first via parable (no religious implications here, mind you!), and then I’ll give some concrete examples and some brief advice on how to avoid (or at least mitigate) it.

Few people realize how well many of Aesop’s Fables apply to IT situations: after all, as Apollonius of Tyana noted, Aesop “made use of humble incidents to teach great truths.”  One of my favorites along these lines is Aesop’s fable about the boy and the nuts in the jar.

[Read more…]

How not to get what you want from IT

As much as any part of your company that supports the key prongs of the corporate mission (deliver product, sell the product, support the product), IT is constantly on the hook to deliver more and more.  As I’ve written before, expectations are deservedly high, and getting higher all the time.  And when expectations are so high, and the stakes for success equally so, the possibilities for disappointment are numerous.

No one wants to be disappointed, and no one wants to disappoint.  Here’s how you, the business stakeholder, can help yourself and the company: don’t fall into the common traps with IT that will likely lead to you not getting what you really want.

Here comes a David Letterman list of these traps, consisting of only three items.  There are, of course, a lot more traps than just three, but in my experience, these are the main ones.

3. Push hard on your IT organization to deliver on “trick plays”. Sorry for the sports metaphor, but it’s applicable.  With respect to IT, “trick plays” mean mission-critical, high-profile projects like constructing new web sites or instituting major new back office systems such as a data warehouse or a new CRM system.
[Read more…]

Mastodon