Feed on
Posts
Comments

A Means to an End

The failure statistic is often cited, usually with a moan and a wail. It goes like this: 30, 40, or 50 percent of all IT projects go bad. The rest — the ones that actually succeed — well, they go “slightly bad too.” At least some of them do. In the end, nobody’s happy. Jobs are lost, heads roll, teeth gnash. The statistics are real enough, by the way, although they are often cited incorrectly. I fault leadership and the incessant mixing up of means and ends.

Here are the facts. The original source of those numbers is a 1994 report by the Standish Group called the CHAOS REPORT. The report said this about IT projects (and I’m paraphrasing not plagiarizing):

  • 31% of [IT] projects are cancelled before completion,
  • 88% are over deadline or over budget or both,
  • The costs of such overruns are usually (at least) double original estimates

If you think those numbers are sort of long in the tooth, how about these from 2004.

  • 18 percent of all IT project out and out fail,
  • 53 percent are “challenged” (in other words went awry in some way),
  • Only 29 percent actually “succeed.”

These were updated in 2004. Unfortunately, the damn researchers rearranged the categories, so it’s actually impossible to compare the numbers.

Pie Charts are Fun

Taken another way, 70 percent or all projects go at least slightly pear-shaped. That’s abysmal. It’s no wonder nonprofits are technologically gun-shy. Seventy percent of the time they feel royally screwed. I’d be gun-shy too. The fact is, looking at those numbers, a good E.D. should look upon all IT projects with some degree of skepticism. Imagine if 70 percent of your dates never showed up, or if 70 percent of your email went unnoticed or unanswered, or if 70 percent of the time you ordered dinner in a restaurant you didn’t get what you ordered. It would be enough to give a guy a complex.

“Hey, who ordered the Kansas City rib-eye,” says the waiter. “I did,” you reply. “Sorry,” says the waiter,” we don’t have steak. Here’s some fried city pigeon.” “But, I wanted steak…,” you mumble. “It’s almost the same thing, just as good,” says the waiter. “Besides, it’s local,” he adds, a marketer’s grin plastered ear-to-ear. “You know, it’s slow food, at least this one was slow. That’ll be ten bucks more.”

Why do good projects go bad, and what does that mean?

Usually, the answer is simple — lack of clarity about the goals. People mix up the ends with the means. They garble their goals. They lose sight of the purpose, the raison d’être. They mistake the means for the ends, or they really didn’t have any clear goals in the first place. The fault, dear Brutus, is not in our stars, but in ourselves.  Let me give you an example, mixing up the means and the ends is deadly.

Recently, a friend of mine recounted a story over dinner. He had been at a meeting of international grant makers, funders, and other philanthropic types. Good people all, I am sure. Nevertheless, at this meeting, these folks were busy patting themselves on the back about their successes with Darfur. The successes, it seems, were many — increased public awareness, social networking sites, widgets and mashups, letters to Congress, web site visitors, etc, etc. All their outcomes were terrific; all the measures spelled success, with a capital “S.”

I looked at my friend and said “But…” “Exactly,” he said. “There is still a war. People are still dying. This is not success.”

Writ large, this is also one of my overarching philanthropic fears. I fear the tyranny of false outcomes. I fear an overemphasis on “outcome measurement,” an emphasis that forces the philanthropic world to think and act solely in terms of all things measurable, thus missing the forest for the trees and mistaking the measures or the outcome for the true goals.

I fear this will, in fact, drive us to a place where success is only something that is measurable, that is quantifiable. I fear that it will drive us to tiny measures, to secondary goals, easily measured, and easily met, and that will drive us to tunnel vision, all the while ignoring the true goals, the real ends — declaring the success of a fund-raising campaign and forgetting why we were raising the money in the first place.

If you mix up the means — things like memberships, activists, letters to Congress, and the like — with the ends — people die and freedoms are lost while we count page hits.

In IT, the demons entrance the audience with the shiny and new — we’re distracted, fascinated by the glitter and gleam, and lose sight of the goals. In my mind, any project that begins with a list of gadgets, software, hardware, or more trained monkeys, is the problem.

I blame lack of leadership. Moreover, I blame the IT directors and CIO’s, the project managers, and IT consultants, and, since I’m blaming people, the ED’s too. If a project goes bad, the odds are someone has mixed up goals, and scrambled the ends. I dare say somebody probably over-sold the whole thing too. Beware the marketer; else you’re likely to be eating pigeon.

In a nutshell, this is the reason a lot of nonprofit IT directors or CIOs or the like feel misunderstood, underappreciated, or downright alienated. They talk about the shiny, the new, the means, and forget about the goal, the purpose, the end. Do that and you’ll end up in that 70 percent.

I fault two specific things: dashed expectations and lack of vision. Setting goals, and setting expectations about those goals, is the key to a long life, whiter teeth, and a better love life. Ah, well, maybe I’m exaggerating. But understanding goals and setting expectations is the key to happy — successful — IT projects. White teeth are just a bonus.

It’s pathological, you techies: you over-promise and under-deliver. For many a geek, technology is an end, gadget as goal. If you lose the goal, lose clarity of purpose, your good projects will go bad.

It starts with a project divorced from vision — the vision of the organization — tacked instead to some secondary, usually measurable but secondary, outcome. It ends with what I call the “expectations gap” — the difference between what is promised, what is really possible, and the eventual, actual results.

  • The “promised” — this is what the market usually over promises, whiter teeth, bigger naughty bits of all variety, better, faster, and, of course, you’ll have more friends. Usually it’s absolute hogwash.
  • The “possible” — this is what could occur, if absolutely everything goes swimmingly, and all the stars align just right. This is what should be your goal.
  • The “actual” — this is what gets delivered.

The trick here is to know the goal, keep the vision clear, and to simply not over promise. Success here is to make the “actual” equal the “possible.” But, if you promised too much, you’ve already failed. Be clear — even painfully honest — about what’s possible, and communicate so often that it hurts. Set expectations wisely. Mind the gap.

2 Responses to “A Means to an End”

  1. on 07 Jun 2008 at 1:06 pm Eugene Chan

    This post smells a bit like an ad hominem (or should I say ad geekem) attack against IT projects and managers.

    False outcomes are hardly the province of IT projects or IT tools. Bad or non-existent project management exists everywhere. Think the Big Dig. Rumor has it that the Great Wall was rife with overruns and high fiving until the Mongols just went around the wall.

    Let’s think about it in the reverse: what are ways that IT and communications tools salvaged a project that was in danger of capsizing?

  2. on 24 Jun 2008 at 10:27 am A. B,

    “….a meeting of international grant makers, funders, and other philanthropic types. Good people all, I am sure. Nevertheless, at this meeting, these folks were busy patting themselves on the back about their successes with Darfur. The successes, it seems, were many — increased public awareness, social networking sites, widgets and mashups, letters to Congress, web site visitors, etc, etc. All their outcomes were terrific; all the measures spelled success, with a capital “S.” …”

    I must have been on the same meeting…

    I would agree with your thesis and accept a blame as an IT guy if only all those good non-IT people were able to communicate to me their goals with a basic logic… Your metaphor of the waiter from my perspective is :

    Client: “Bring me something to eat… - I am hungry”
    Waiter: ” we have A, B , C on our menu…”
    Client (breaking the presentation) ; ” Oh, I trust you - you know the best….”

    The dissatisfaction from delivered IT projects is stemming from not knowig at first what was required… THE GOALS are very rarely communicated to the IT guys…

Trackback URI | Comments RSS

Leave a Reply