In-Depth

BI Product Release Dates: Better Late Than Buggy!

What's the impact to your BI projects if your vendor misses an update schedule?

• By Mike Schiff
• 02/27/2008

The recent announcement that Microsoft SQL Server 2008 will be released in the third calendar quarter of 2008, six months after the previously announced expected delivery date, is causing concern and generating negative comments about the software giant's inability to meet its delivery commitments.

Microsoft is certainly not known for bringing its products to market ahead of schedule and, in fact, has a long history of continually missing its original delivery date estimates. Microsoft is by no means the only company with this reputation. However, I actually applaud Microsoft for admitting that its delivery date will slip and for its willingness to endure the associated heat. After all, who (other than someone whose bonus or job is dependent on meeting the original scheduled release date) would disagree that a relatively clean but late product release is better than a timely, but buggy, one?

One thing data warehouse users insist upon is high quality data for their analysis; "garbage in, garbage out" is a lesson that only needs to be learned only once. If one of a data warehouse's data sources is of poor quality, users will simply learn to ignore it and exclude it from their analyses, at least until the data source literally cleans up its act or an alternative source is found.

The same can be said about high quality software; a company whose released products earn a reputation for being buggy will find it difficult to upsell its installed base or attract new customers. Many companies insist on not purchasing the first release of any product as they assume that it will contain bugs or missing functionality that will be resolved in the second release. While some software vendors have attempted to circumvent this constraint by numbering their initial release as release 2, the real solution is to do it right the first time; quality should be job number one for software vendors as well as automobile manufacturers!

Assuming a product slippage results from needing more time to ensure its quality, let's take a look at some of the ramifications that missed deadlines can have on data warehouse users:

-- Delayed implementations: A complete data warehouse environment is based on a set of software tools that work together to integrate disparate data sources, store it, and then analyze it so that it can be appropriately acted upon. If a critical software component is late, at best functionality will be reduced, at worst implementation will be delayed. While some companies my try to work around a date slippage by using a pre-release beta version of the software, functionality might change in the actual release and most beta software agreements contain clauses that disallow its usage in production environments.

• Delayed training: Although user interfaces continue to become more intuitive, user training should still be part of any data warehousing project. However, training users on a beta interface that might change prior to product release could cause confusion when the system goes live with a released interface that may have changed.
• Loss of project budget: Some companies have a "use it or lose it" budget process whereby a department that doesn't spend funds allocated for a specific project in the current year must reapply to use these in the following year. If this is case, there is some risk that the funding will no longer be available.
• Loss of momentum: There is nothing as powerful as an idea whose time has come; on the other hand, there is nothing as depressing as an opportunity that is lost because the right resources were not in place to take advantage of it. Having an organization psyched about the analytical capabilities that a data warehousing project will provide will soon be lost if a software delay places the project on hold.

For most organizations, these issues will clearly be a problem and they need to be able to protect themselves by minimizing their risk. There are several ways to accomplish this, which include:

• Expectation setting: Establishing realistic or even slightly pessimistic expectations about project rollout dates and building in some slack time for currently unforeseen delays.
• Appropriate vendor evaluation criteria: If the use of a yet-to-be-released software component is on the project's critical path, the software evaluation criteria should consider the vendor's track record for meeting its delivery commitments. A more conservative approach would be to consider only the features in currently released software, not vendor promises of functionality that will be available in a release that the vendor promised to have available in time to be used in the project.
• Establish a contingency plan for falling back to second-choice software: This may not be easy to do, especially if the project is dependent on special proprietary features that are only available in the software of choice. However, by careful planning and avoiding the use of these features, it may be possible to substitute a competitive product, albeit possibly with some initial loss of functionality.

Although from a vendor perspective there may appear to be some short-term advantages to releasing a not-quite-finished product on schedule, the long-term ramifications of releasing a problem product can have serious negative consequences. A company's reputation is based in no small part on the quality of its products. Yes, it will hurt a company's reputation and credibility if it continually misses its schedule commitments; however, it can be even more harmful if the company releases a poor quality bug-filled product on time.

Given the revenue and other pressures to release on schedule, and the political and marketing disadvantages of releasing late, it takes a mature and self-confident organization to face up to the potential negative consequences of a late release.

From a user perspective, there are risks associated with depending upon vendor promises of functionality in yet-to-be-released software. If a vendor has a reputation for missing delivery dates and your data warehousing project is dependent on software that is not yet generally available, you should seriously consider choosing only software that you know has already been released.