Campus Financial Systems for the Future

Considerations in developing or migrating a system in-house

For whatever reasons among those listed previously, your institution may have decided to develop a system in-house. As noted earlier, this solution actually represents a partnership between the information technology (IT) organization and the finance organization. In this case, your institution's information technology personnel will likely have a development methodology they intend to employ in developing a new system or migrating a current system to a new architecture to meet the needs outlined in the requirements document.

It is not the intention of this book to cover in depth the issues surrounding a systems development project; indeed, there are many books available on this topic, and your institution would not have chosen this solution if your internal IT organization was not highly competent to undertake such an effort. There are, however, a couple of success factors and potential land mines to consider.

Clear leadership roles
Traditionally, the institution's technology department has been the dominant player in this kind of partnership. Most of the reasons for this are historical and may no longer be relevant at your institution. In today's more complex environment, however, the finance organization must play a leading role in any internal development project to ensure that the business problems will be properly addressed by the proposed system and that the project stays on target and within budget guidelines.
A key question for the chief financial officer to answer is who will be held responsible for the success or failure of an in-house initiative? If he or she is the one, then complete delegation of this responsibility to the IT organization may be a questionable decision. Unquestionably, the chief information technology officer needs to have a major role, but if the accountability lies with the finance organization, then ultimate decision-making needs to lie with the CFO. An argument could even be made that if the CFO or his or her delegate is incapable of leading the project or understanding the technology issues sufficiently to make such important decisions, then the build-in-house option is perhaps not right for the institution. The responsibility lies with the CFO to ensure that such technological sophistication exists in the finance organization before taking on such an effort.
Clear project milestones with dates
This advice might sound like motherhood and apple pie, but the reality is that in-house-developed systems are sometimes prone to delays in completion. The reasons for this are legion. It may be scope creep, where the finance organization continually requests additional functionality in the specifications during the development phase. It may be due to insufficient technology resources on the project, or this may be the first use of a certain technology at the institution. While all of these reasons may appear valid to those actually involved in the project, the patience and indulgence of the institution will be eroded very quickly if delays occur.
The project management team must have clear milestones at key points in the project timeline, and the importance of meeting these cannot be overstated. The experience and skill of the project manager (who may not be the same individual who has led the project through the selection phase) will be of paramount importance on this point. He or she must know how and when to compromise, and when to hold firm. There is a school of thought in the IT world that says the probability of success in a development project is inversely proportional to the duration of the project. That has serious implications for a project that cannot keep on schedule.
Importance of prototyping
Some consideration should be given to the merit of pilot projects, prototyping, and using small group experiments to test the waters, rather than going for the "big bang" approach of all or nothing, all at once, undertaking so much that there is no chance to find potential problems on a smaller scale. It is far less risky to develop and implement at least one component quickly (for example, on a prototype basis) and work with it to identify potential problems in the approach.
For example, North Carolina State University has successfully used the rapid application development (RAD) methodology to develop several client/server systems through an internal Administrative Computing Services self-directed work team. This protoyping approach enabled the team to quickly develop new client/server-based systems while continuing to maintain legacy systems and respond to ongoing customer requests.

[Previous] [Next]