Campus Financial Systems for the Future

Planning for enhancements and changes

No matter how good the requirements definition or the prototyping, the user will always identify unforeseen design criteria when implementation begins. This is not an indication of flawed design, but rather a natural process. In fact, in the era of client/server systems, it is almost guaranteed to occur. Responsiveness to these changes is key because the attention of the user is more focused now.

If the system is an existing product supplied by a vendor, then the institution should have essentially adopted a policy that behavior will be adapted to the software. In this case, changes to the system are not likely. However, the newer generation of client/server systems offered by some vendors promise significant local customization, and this puts them in the same mold as in-house-developed systems. For these, there will inevitably be the need to deal with unforeseen changes or enhancements during implementation, and to have a process for managing these changes.

During implementation, the system is no longer in the planning stages -- it is actually happening! This is where the stakeholders really show up. Their requirements, priorities, and satisfaction will all come into very sharp focus. Misunderstandings will occur about perceived functionality differences: "This is not what I told you I needed." How the team handles these issues will have a significant bearing on how the users will accept the system in the long run. L.L. Bean has the right attitude here! Unless the suggestions seriously jeopardize the implementation, they need to be accommodated. If the schedule would be adversely affected, then the stakeholders need to be given a complete explanation, and the suggestion must be placed on the prioritized list of enhancements to be dealt with at the earliest opportunity.

Some critics of the inter-institutional development model suggest that the implementation stage is the evidence for why the longer-term benefits of a mutually supported set of code very rarely materialize. It may have been possible to keep the partners together through a design and even a development stage, but when the users at each institution begin to use it and demand local customization, the system can quickly become a unique set of program code that will never again be synchronized with that of the other partners. Hence the importance in a consortial arrangement of establishing change control agreements.

[Previous] [Next]