Have you ever been associated with a project where the execution was flawless, but yet you were unable to achieve the business objectives? I have -- as a member of a cross-functional project team, whose charter was to design an electronic business solution for a retailer with hundreds of stores across the Midwestern US.

A couple weeks ago, I received an intriguing e-mail from a total stranger in the northwestern US:

Business uncertainty, accentuated by the recent dot-com failures, seems to be having a paralyzing effect on businesses. The ambivalence between nurturing old business lines and heavy investment in new ones has led to a technological impasse in many organizations. In the name of uncertainty -- or unexpectedly magnified bottom-line deficiencies -- strategy implementations are being halted.

It's past the point at which one needs to describe component applications to prove the technology works or to prove the value of component reuse; most companies are convinced. The problem they are focused on is creating organizational structures to make it happen. Nevertheless, every so often I come across an implementation story that is so good that it's worth passing on.

In Part I of this Advisor (20 December 2000), we discussed the fundamental law of project failure: any project can fail.

Let's now explore the consequences of denying the law of project failure and examine how organizations might approach things differently if they acknowledged the possibility of failure.

Seemingly interminable meetings are often struggling in the "groan zone," Sam Kaner's wonderful term for the time period in which meeting participants are trying to understand each other.

IT has traditionally had three broad categories of functions: setting technical strategy directions for the company, building and supporting business applications, and assembling and supporting the company's technical infrastructure. Although each of these functions remains relevant and necessary, the concept that they are best performed by an internal IT organization is becoming demonstrably obsolete.

As I talk with people at companies that are working on large-scale e-business integration efforts, I'm told, over and over again, that integration is the key. If a company can't get its large, diverse legacy applications to talk to one another in an efficient manner, it can't hope to provide the kind of customer support that Web users want.

The other day, I broke a 12" x 12" x 1" pine board with my bare hand after listening to a 90-minute motivational talk about breaking barriers to achieve goals. As someone with martial arts training, I was less impressed with my own success than I was with the success of a 12-year-old in the group of parents and children.

At a recent IT conference, a colleague of mine who helps companies negotiate large-scale outsourcing deals posed a question to the audience. He mused, "Have we squeezed all the productivity there is to squeeze out of IT?"

I am not a confident cook. My approach at big dinners is to write down everything I want to make, assemble all the ingredients, orchestrate an appropriate set of dependencies (what needs to come out of the oven first, and so on) and then implement with the goal that everything be hot and on the table, hopefully edible, at the same time.

To be effective, business-IT alignment must be practiced as a continuous activity, with the business model being continuously adjusted to reflect changing conditions such as IT developments and market changes. As the business model changes, IT must adapt accordingly. Within this continuous process, complex problems are faced, and identifying the right decisions is difficult.

The recent news of Apple's financial problems makes it hard to resist pointing out that I predicted this three years ago when Steve Jobs became the temporary CEO of Apple. I would never advise anyone to make stock market decisions based on my predictions. The market jerks up and down as participants identify possible short-term gains or losses.

The open source software movement has been catapulted into the limelight over the last two years, as a series of successful projects have captured the attention of corporate America. For example, the Linux operating system, poster-child of the open source movement, took shape in 1991 alongside the GNU Project to develop a freely available operating system.