[Previous] [Next]
VI: Implementing the System
Considerations in partnering with peer institutions to develop a system
This option is becoming increasingly popular among the alternatives considered by some institutions. The emergence of object-oriented technology has prompted various consortia to band together to develop what are known as "business objects," packets of program code designed to perform a certain function. The theory is that if they can spread the work of developing these objects among a number of institutions, then all can benefit more quickly by assembling the objects to build the locally appropriate system. The Big Ten IT directors are exploring this possibility.
Of course, the more traditional partnership involving sharing the burden of writing the entire system is also a possibility, although there are not many examples where this has been successful. Some pundits have said that while it may be very difficult to reach consensus at a given institution on these matters of systems design, it is impossible to do so across institutional boundaries!
Some special considerations for project management when partnering with one or more peer institutions include:
- establishing a clear understanding of responsibilities (project management, resource allocation, setting of priorities, and so forth),
- coming to agreement on financial liability, and
- establishing agreement on a project plan and methodology for revising the plan before the project begins.
The same issues noted above for in-house development apply here as well, with two additions.
- Interinstitutional legal factors
There will probably need to be some contractual arrangement among the peers, and care should be taken not to let this step consume too much of the available project time. Obviously the statutory regulations of a state-supported institution may clash with those of a private one, and it would perhaps be wise to test these waters before going too far down this road. One partner may not be able to move as fast as another from a legal standpoint, and that may make the partnership difficult to manage.
- Ownership and support of the system after completion
One of the common failures in this model is the erosion of support by peers after completion. Some institutions may opt out of the project and the maintenance load will have to be spread over a smaller group, altering the resource allocations accordingly.
[Previous] [Next]