The IT project failure dilemma: how to get early warnings

Thinking about how to prevent big system project failure has somehow always reminded me of the Will Rogers quote: “Don’t gamble; take all your savings and buy some good stock and hold it till it goes up, then sell it. If it don’t go up, don’t buy it.”

In other words, with big projects, by the time you realize it’s failed, it’s pretty much too late.  Let’s think a bit about the reasons why, and what we can do to change that.

First off, I’ve never seen a big project fail specifically because of technology. Ever. And few IT veterans will disagree with me. Instead, failures nearly always go back to poor communication, murky goals, inadequate management, or mismatched expectations.  People issues, in other words.

So much for that admittedly standard observation. But as the old saying goes, “everyone complains about the weather, but no one does anything about it.” What, then, can we actually do to mitigate project failure that occurs because of these commonplace gaps?

Of course, that’s actually a long-running theme of this blog and several other key blogs that cover similar topics. (see my Blogroll to the right of this post). Various “hot stove lessons” have taught most of us the value (indeed, necessity) of fundamental approaches and tools such as basic project management, stakeholder involvement and communication, executive sponsorship, and the like.  Those approaches provide some degree of early warning and an opportunity to regroup; they often prevent relatively minor glitches from escalating into real problems.

[Read more…]

Simple, more practical approaches to actual resource allocation

Anyone ever tell you that a simpler approach can often work better than a more complex one? Whoever it was, it probably wasn’t a project management software vendor.  But simplicity has its merits, and I’d like to point out a few of these when it comes to resource allocation.

Project management, at its core, is largely about resource allocation, and this gets tricky when you have multiple projects going on, as most organizations do. Almost as much as I’ve seen organizations drop the ball entirely on cross-project resource allocation (essentially, simply pretending that there will be no contention issues), I’ve seen organizations go to the other extreme: they dive into the depths of intense Project Management, in capital letters: taken too far too fast, this approach can spin up to a high level of rigor and overhead, involving often-expensive software packages, precise low-level estimates, diligent collection of actuals, and ornate project calculations of hours burned and hours earned.  At the end, there you stand, like Goethe’s Faust, “no wiser than before.”

[Read more…]

No silver bullets. Really!

Fred Brooks wrote a seminal essay in 1986, “No Silver Bullet — Essence and Accidents of Software Engineering“, a model of clear and cogent thinking that I consider to be required regular reading for anyone involved in information technology.  Despite the essay’s brilliance, and despite its wide promulgation and deserved fame, the phenomenon it describes seems to have only broadened in the last twenty-three years.  Brooks argues as follows (with bolding added):

The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet—something to make software costs drop as rapidly as computer hardware costs do.

There is no single development, in either technology or in management technique, that by itself promises even one order of- magnitude improvement in productivity, in reliability, in simplicity.”

So this basic tenet has been convincingly articulated by a leading IT thinker for almost a quarter century. Yet, the trend continues: new technologies pop up every couple of years and the hype cycle begins. Evidently, hope springs eternal.
[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…]

Complexity isn’t simple: multiple causes of IT failure

Roger Sessions recently published a white paper on IT complexity and its role in IT project failure: “The IT Complexity Crisis: Danger and Opportunity”.  It’s certainly possible to quarrel with bits and pieces of his analysis, and thereby tweak his numbers, but the overall thrust remains undeniable: IT failures are costing the world incredible amounts of real money. Sessions even sums it up under the dire-sounding phrase, “the coming meltdown of IT,” and says, “the out-of-control proliferation of IT failure is a future reality from which no country—or enterprise—is immune.” And he presents “compelling evidence that the proliferation of IT failures is caused by increasing IT complexity.”  He points out that the dollar cost of IT failure in the US alone is close to the cost of the recent US financial meltdown, and cites indications that the rate of failure is also increasing by 15% per year.

Roger’s paper is excellent and thought-provoking, and I recommend it highly. And I do agree with his view that complexity is the chief culprit in IT failure. That said, I think his argument focuses a little too strongly on one cause of complexity (unnecessary overcomplexity of architecture), to the neglect of other important factors.

[Read more…]

Some timeless IT/tech jokes, and why they’re still relevant

If you’ve been in the information technology industry for a number of years, certain jokes tend to pop up again and again. Why? I’d say it’s because their underlying premises, the things that make them applicable and funny, continue to occur. So even if you’ve heard these before (and that’s probably the case), it’s worth taking a few moments here to look at them again and consider what makes them timeless.  Remember, even jokes have morals to the story. Sometimes especially jokes.

[Read more…]

The title issue revisited: CTO vs. CIO

Key question of the day: given the recognized ascendancy of business/IT alignment and business change management as a vital purview of the effective CIO/CTO, should senior technology executives decrease their emphasis on technology, and focus primarily on corporate strategy and change? Should the company just have one role (call it a CTO, perhaps) do all that technical stuff, and move the CIO role into that of predominantly business strategist?

Let me raise my hand for the Nays. That would be the pendulum swinging way too far in the opposite direction. The problem of business/IT alignment won’t be solved by ghetto-izing technology concerns, and/or pretending that an executive is really only part of the senior team if she/he has a mostly strategic orientation and little responsibility for technology. That’s called a backlash, and it’s bound to lead to trouble. Here’s why.
[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…]

Mastodon