Campus Financial Systems for the Future

IV: Determining Business and Technology Requirements

Assessing the technological scope of the project

Selecting or developing an effective, quality financial information system is not, primarily, a technical decision. It is important, therefore, that the technology team accurately assess the extent of the technology impact on the project. The scope of this team's efforts will be directly affected by work that has already been done by the steering committee, and the ongoing work of the project management team and the business process teams.

The steering committee will have articulated an institution-wide strategy that will enable the technology team to draw parameters around the technical scope of the project. Reviewing these conclusions will provide valuable insight for the technology team in assessing how far the institution wants to push the technology window and, conversely, to what extent the institution intends to be more comfortable with proven approaches.

Review the institution-wide strategy
One approach to reviewing the steering committee's work in establishing an institution-wide strategy is to raise questions about leadership, organizational structure, and access philosophy, such as those listed in the sidebar below. If the steering committee has recommended taking a leading-edge financial system approach, it is important to bring the rest of the institution along with that position. Financial systems have a wider impact today than they did in the past on units outside the traditional financial units. Leading-edge approaches will probably involve imposing learning and expenditure requirements on distributed users that they might not accept. This is why institution-wide consultation is important.
As the team reviews each of the areas in the sidebar, it is important to assign some relative value or weight to each. In determining the relative value of technological approaches, it is often necessary to trade off values and constraints across these various areas. For example, the value of technological leadership and planning for the future might be weighed against the need to resolve some real business requirements issues in a timely manner. If those kinds of weights and priorities have already been specifically stated by the steering committee or the project management team, this certainly will help with the technological evaluation. However, where these kinds of issues have not been spelled out, the technology team needs to arrive at some sense of the relative value to the institution, and feed this back through the project structure for validation. Otherwise, much valuable time and energy can be mistakenly spent on resolving technology issues that are not germane to the work of the technology team.

Technology Leadership Strategy:

Has a desire for the campus to be a technology leader been articulated as part of this project?
Has the strategic vision identified the institutional culture as conservative or leading-edge?
Is the focus on designing for the future or on resolving existing issues and concerns?
IT Infrastructure Strategy:

Is the existing IT infrastructure and method of operation to remain intact?
Have requirements been set that the financial systems applications need to co-exist within the same or different database or technological environment as other core administrative applications?
Has a target information technology architecture been defined as part of the strategic vision, e.g., has the steering committee identified a specific technology strategy-- migration to client/server, outsourcing, leveraging existing mainframe platform?
Does the strategy identify a central or decentralized model?
Information Access Strategy:

How has the steering committee described the institutional culture or philosophy with respect to information access, i.e, how important is access to financial information?
Is ease of use a characteristic found in the conclusions of the steering committee, and how important is user functionality versus technological advancement?

Review project parameters
The technology team will need to establish whether it has autonomy with respect to the definition and identification of technology issues and to identify potential partnerships on technology issues with other teams. The latter can be accomplished by reviewing and aligning roles and responsibilities, identifying its reporting relationships within the project structure, and defining any specific reports or review points that may be required.
Another significant factor is whether the project has encompassed a traditional needs identification approach or a business process evaluation approach. Where there is a need to rapidly resolve a particular set of issues or concerns, and where change in itself will create the necessary results, the technology evaluation team will be looking at fairly traditional technology responses to the business requirements, such as the purchase of an off-the-shelf product.
The technology team will also need to review the timelines that have been established by the project management team. Short time frames for decision and implementation may represent a conflict with a strategy that requires significant technology changes. For example, with the higher risks associated with such technologies as client/server, the technology evaluation team may want to review the steering committee's recommendations regarding the tradeoffs between gradual and discontinuous change. Although it is more difficult to achieve, gradual change has the advantage that it can be "rolled out" on a timetable that is both technologically attainable and organizationally sustainable. People do not change work habits easily, so a gradual approach may afford the time they need to "ease into" the new system rather than changing everything overnight. Discontinuous change, on the other hand, has the advantage that it gets results and gets them faster than with the gradual approach. Often, the needs of the institution are such that large, wholesale, discontinuous change is the only way to achieve the goals of the project.
Having completed all of these reviews and checked the results with the project management team, the technology team will be in a position to accurately estimate the scope of the technology portion of the task. This kind of a review process can significantly simplify the role of this team. The answers on technology requirements become more apparent and the technology evaluation can be carried out fairly easily. For example, the team may have learned that the project must follow existing standards identified by the IT organization or they may find there is a great deal more flexibility to pursue alternatives and arrive at recommendations to change the base for technology at the institution.

[Previous] [Next]