Decades of experience have shown that there are certain policies, attitudes, and practices -- shall we say, "rules of thumb" -- that, taken together, are essential for successful organizational change. And given that outsourcing is a major organizational change process, these rules of thumb seem to apply to outsourcing as well.

[Excerpted from an article in the September 2000 Business-IT Strategies Executive Report.]

Management's attitude toward risk will influence greatly whether risks are identified early and thoroughly enough to take reasonable actions to mitigate them.

I recently published a column in IEEE Software in which I observed that in recent years, requirements and modeling have fallen on hard times and that this is a trend that should be reversed. The article appeared just a few days ago, and I have already received comments from readers who say they are seeing a resurgence of interest both in requirements and design.

Task: To provide cheap e-mail connectivity to four remote sites.

Before reading on, stop and think about how you would do this with your familiar technology.

Now, being a good IT manager, you ask "How cheap?" You discover there is commercial broadband satellite access but it costs more per month than the salary of the local manager. In fact, the budget is nearer to single-digit dollars per month than hundreds of dollars per month.

"So now that we've committed to outsourcing, how do we manage it? We don't need any more consulting about what's the best way to go about outsourcing, now we need some practical guidelines on how to keep from falling on our face!" (Comments heard at an outsourcing conference.)

It's nice to read that SCO is having problems: the company deserves it. A recent survey of IT folks concluded that SCO's CEO, Darl McBride, has surpassed Microsoft for CEOs that most IT folks love to hate. That's quite an achievement for someone who was unknown only a couple of years ago.

[This is the first in a series of three Advisors on software architecture.]

Here's an interesting finding based on the results of a Cutter survey that asked 127 end-user organizations of various sizes located worldwide questions designed to measure the adoption and use of enterprise information portals (EIPs) in conjunction with other information technologies and business strategies.

I have argued that most organizations do not have enough IT project failures. The reason I say this is that, in my experience, most project cancellations (or escalations for that matter) are not true failures but instead represent blunders. There is a big difference. A project failure is one in which most project decisions and actions were correct at the time, but for some reason the project didn't work out.