[Previous] [Next]

Considerations in buying an existing vendor product

Presumably, the project management team has evaluated the functionality of the vendor's product against the needs requirements documents and has determined that the product can be deployed either intact from the vendor or after some minor modifications. In the latter case, the vendor or the central IT organization may do these modifications, but they are modifications to an existing marketed product and do not involve the same issues as are implied in a partnership with a vendor to develop a system from scratch. The line between the two may be gray in some cases, but each needs to be addressed as a separate option, because certainly at their extremes they have very different critical success factors and land mines.

Issues surrounding this option include: (1) implied process changes for the institution, (2) integration of the IT organization as a critical partner, and (3) establishment of remedy procedures for performance-related deficiencies.

• Implied process changes for the institution
  Probably the most critical factor involved in the buy option is that the campus community understands that it is likely that some processes will have to be changed to match those the vendor has built into the software. It is highly unlikely that the unique requirements of any institution will be addressed completely by an off-the-shelf product from a vendor. Some compromise will be required, and the objective of the project management team is to get the institution to buy into the model represented in the vendor's product enough to relate to it as the "campus system."

  It is much less expensive to adapt processes to exploit or leverage the new system than it is to modify the system to fit old methods. A potential land mine (which can be avoided by appropriate communications and management of expectations) is that users may insist on adapting the system to business-as-usual, the old way of doing things, rather than change their own patterns. If this occurs, changes may have to be promoted from the top down; using the steering committee to communicate the importance of these changes can help to ensure that they will happen. It is critical to avoid making major modifications to a purchased system. In software development terms, such system modifications -- rewriting code, adding enhancements to existing modules, making site-specific customization changes, and otherwise rewriting the software -- will significantly increase the cost, complexity, and duration of a system implementation. Heavy customization can also make it difficult to use the vendor's upgrades as they are issued.

  Having to adapt business processes to the purchased system can be a positive outcome. In some cases, the processes built into a vendor product may represent "best practices" in the industry. Sinclair Community College is an excellent example of a case where the needs of the institution were met by minor modifications to an integrated set of vendor products, which enabled the college to make a "quantum leap" in systems functionality. In addition, Sinclair negotiated an agreement with the vendor to incorporate the customized portions of the systems into the product code, thus facilitating future product upgrades.

  The most common approach is to balance the costs of creating an exact fit (or the inability to get one) against the time or cost savings associated with buying from a vendor. For some smaller institutions with a limited technology development staff, the buy option may be the only viable one. In many of these cases, moreover, their size and organizational simplicity are an advantage in that there may not be as many conflicting parties whose diverse needs have to be resolved.

• IT function as a critical integration partner
  A buy option is unlikely to succeed unless the central IT organization has agreed to be the integration partner that will perform the necessary tasks to bring in the software. Among these might be setting it up, testing various operational processes, working out backup and recovery procedures, arranging the interfaces with other campus systems if required, and establishing problem resolution procedures to employ when system problems occur.

• Performance-related deficiencies
  The institution should build remedies for product deficiencies into the contract with the vendor. These might be related to actual performance problems such as response times or hardware requirements. More serious deficiencies may relate to actual failure to perform the functional processes of the application. The reference checks with other customer institutions may provide valuable information in this case, including actual contractual documents and information about problems encountered with the software.

[Previous] [Next]