[Previous] [Next]
III: Structuring and Managing the Project


Determining the Scope of the Project

Two fundamental issues to consider when acquiring or developing any automated system, especially a financial system, are: (1) the importance of recognizing that technology should not drive the systems acquisition process, but should be viewed as secondary to the actual business processes that it will support; and (2) the importance of ensuring that the institutional business processes and practices are as efficient and effective as possible.

Depending upon the principles established by the steering committee and the directions that group has set, the project management team will need to choose an approach to identifying business requirements for new or enhanced systems. In the traditional method of business requirements determination, the existing business functions are analyzed and the specific needs of each application are documented as requirements.

An increasingly popular approach, arising from continuous improvement or quality management concepts, is to review existing business processes prior to defining business requirements. These reviews often include participation from cross-functional teams and identify possible significant improvements in existing processes that might reflect cost containment, additional services, or more efficiency or effectiveness. Depending on the thoroughness of these reviews, the overall process of change can be slowed down by process reengineering efforts; for institutions intending a significant paradigm shift, the longer lead time required for these detailed reviews is a cost to consider. Regardless of the level of effort devoted to these reviews, the technological evaluation will need to take into consideration these newly defined needs.

Clearly, not every institution will be able to or need to conduct extensive business process reviews. If, for example, the steering committee vision process has resulted in a strategy that would point toward purchasing an off-the-shelf system, such a purchased system may not be able to provide the highly customized functional features that are likely to be specified in a process evaluation exercise. In fact, to fully leverage a vendor product, it is often necessary to adapt business processes to fit the product. Like the steering committee, the project management team must recognize this at the outset and make sure that any process evaluation is conducted with appropriate expectations, that is, understanding that not all sought-after functionality may be possible with a purchased solution, and, in fact, that business process change will likely be influenced by the nature of the selected product.

Even when major process changes are not anticipated, it is nonetheless valuable to engage in some business process evaluation while taking a more traditional approach to identifying required functionality. Clearly, the business process evaluation effort, which will prompt broader recommendations than simply the use of new technical tools, will not be solely dependent on eventual responses to a request for proposals for the implementation of changes. Indeed, some of the recommendations for process change can often be introduced before any other significant changes are made, producing the "quick wins" that enable customers to believe that the project will, over time, make significant changes for the institution. The project management team can be working with the appropriate managers and offices to introduce such non-technology-driven changes, regardless of the outcome of the systems project.

In deciding what approach to take to identify business requirements, the institution's leadership must be aware that the costs of introducing new technologies to support the old way of doing business -- "paving cowpaths" -- can include both the inflexibility of the resulting system and the suboptimization of the resulting processes. Opportunities for introducing institutional change of the scope required by migrating or replacing financial systems, as well as by making financial business process changes, are not frequent. Attempting to do one, and then returning later for the other, may require more upheaval than the campus can tolerate.


[Previous] [Next]