This is the fourth Advisor in my series on risk management.

This is the fourth Advisor in my series on risk management.

Enterprise application integration (EAI) continues to haunt the thinking of those who are tasked with designing large e-business applications.

Some of you have probably heard of Extreme Programming, or XP, as it is usually called. XP is a lightweight software development methodology that advocates (Kent Beck, Ron Jeffries, and others) claim is a way of developing high-quality software with low schedule and budget risk.

When a company or department becomes single-mindedly obsessed with time to market, it sometimes acts in risky, self-destructive ways that result in the thing it fears most: blowing the delivery date even more than originally anticipated.

What happens when two organizations go bump in the night? Well, if they are boats, they spring leaks, take on water, miss arrival times, and sometimes sink. If they are a client organization needing software and a software organization providing software, they run into trouble, too. The sad experience in 1995 of the Los Angeles County Board of Supervisors and a software contractor reveals what happens when ignorance -- actually, partial knowledge -- bumps into partial knowledge.

The primary reason software organizations are implementing critical chain project management is that it allows them to substantially reduce the elapsed time of their projects without:

Software organizations are implementing software critical chain project management to substantially reduce the elapsed time of their projects without adding resources (or increasing overtime), narrowing the project scope, increasing risk, or cutting quality of the delivered system. As a by-product, late projects are virtually eliminated.

In Cutter Consortium's ongoing business-IT strategies survey, 68% of respondents have formal business strategies, and 61% have formal IT strategies. We might expect these numbers to be closer to 100%, but many companies do not focus their energies on developing strategies. But what about the other end of the planning-doing spectrum -- IT projects? How do companies execute these?

Paul Harmon, Editor