BI projects introduce many new practices: new techniques for business analytics, new prototyping techniques, new design techniques, new architectures, and new technologies. These practices are relatively new not only to organizations but also to the information technology (IT) industry as a whole. In addition, BI projects usually involve a significant level of capital investment. All of these factors add up to make IT managers and business executives quite anxious. When a BI application does not turn out flawless or is not complete on its initial implementation, some IT managers and business executives get very unnerved. A major shift must occur in how IT managers and business executives approach BI projects. The approach of "get it right the first time" has never worked, even though people have pretended for years that it does ”or that it should. That misconception should have been put to rest long ago. No major invention or significant endeavor has ever worked right the first time. Usually, good things evolve over time. Nature evolves. This fact is generally accepted. Technology evolves (Figure 16.1), and this fact is also accepted. But the truth that software evolves as well is usually not accepted, at least not when the software is developed in-house. Figure 16.1. Evolving Technologies
When software is purchased from a vendor, it seems to be more palatable to accept an imperfect and evolving product because a software vendor never promises that the first product release will be the last. Vendors also never claim that their software products will not have to be enhanced; on the contrary, we want them to be enhanced. Why, then, do we have exact opposite expectations of internally developed software? For example, when vendors publish a new release of their products, they include new functionality, new screens, new modules ”and of course some fixes to defective parts of the prior release. Sometimes, the new software release is completely redesigned and is not even compatible with the previous release. We do not hesitate to pay good money to upgrade purchased software products under those conditions. But when the in-house IT technicians have to redesign a BI target database or portions of a BI application after the third or fourth release, the situation is treated like a disaster. Organizations must accept the fact that internally developed applications evolve over time, just as vendor software products do. Hence, it is high time to embrace the application release concept. Guidelines for Using the Release ConceptWhen developing BI applications under the release concept, IT and business management must agree on and follow some basic guidelines (Table 16.1). When following these guidelines, there should never be any concern about the completeness of a BI application on its initial release. Any incomplete functionality that was negotiated out of the scope due to unforeseen roadblocks will be bundled with new functionality in the next release or some future release. Business management gets to decide how long to defer the functionality, and the decision will probably be based on the priorities of outstanding requirements. Table 16.1. BI Application Release Guidelines
|