Strategic Application Enhancement: Revitalizing an Aging System Copyright 1990 CAUSE From _CAUSE/EFFECT_ Volume 13, Number 2, Summer 1990. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its dateappear, and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu STRATEGIC APPLICATION ENHANCEMENT: REVITALIZING AN AGING SYSTEM by Donald E. Heller ************************************************************************ Donald Heller is Director of Administrative Systems Development (ASD) -- part of the central Information Systems group -- at the Massachusetts Institute of Technology. ASD is responsible for providing MIT's administrative departments with application development, maintenance, and support services. Prior to his current appointment, he served in various positions in the Department of Purchasing Stores, and was also Assistant to the Senior Vice President at MIT. He holds a BA in economics and political science from Tufts University and is pursuing the M.Ed. degree at Harvard University. ************************************************************************ ABSTRACT: Many institutions face an aging applications portfolio that demands heavy attention and resources from information systems management and its clients. Older applications are often caught in cycles where maintenance and operation become increasingly expensive, yet replacement costs are prohibitive. Efforts to meet changing business needs strain them. To support a major capital campaign, MIT developed a strategic approach towards enhancing an existing alumni/fund- raising/gifts system to extend its life and avoid the capital costs associated with replacing it. This article presents MIT's experiences as a strategy that could benefit other institutions. As they enter the 1990s, many universities find themselves facing a common problem: a portfolio of business and administrative applications that are aging, are difficult and expensive to maintain, and no longer meet the needs of the functions they support. We are in an era when effective tools and techniques to support the design and construction of new applications are commonly available, yet most organizations still spend the vast majority of their programming resources on maintaining existing systems. The commonly held belief among many information technology professionals is that the systems life-cycle costs for application development and maintenance (not including data center operating costs) are heavy during development and comparatively minimal for maintenance. They think that as a new application is developed, the amount of resources committed to the project peaks during the coding phase; as the implementation point of the new system is reached, the level of resource allocations begins to decline; after a large volume of post-production fixes are completed, the level of resources drops to a steady state that is a fraction of its earlier levels; and as long as the volume of maintenance requests stays constant, the level of resources required to maintain the system will also remain constant (as measured in real dollars -- see Figure 1A). [FIGURE NOT AVAILABLE IN ASCII TEXT VERSION] Our experience at the Massachusetts Institute of Technology (MIT) in maintaining older applications, however, is that the true life-cycle costs for most systems are quite different. As an application ages, the real dollar cost to maintain and operate it usually increases each year (see Figure 1B). The reasons include: [FIGURE NOT AVAILABLE IN ASCII TEXT VERSION] * As the application is changed by adding screens, modules, and data elements, it becomes unwieldy, and its original architecture weakens to the point of becoming a house of cards, ready to collapse at the failure of any one component. * As changes are made, technical documentation is often not updated, making maintenance more difficult because of the divergence between the application and its documentation. * As the underlying business processes of the organization evolve and change from those in place when the application was originally designed, the ability of the application to support changing functions decreases. Each succeeding functional change becomes more and more difficult and costly to implement. * Most application support organizations face intense pressure from clients to keep up with their requests for changes. Such pressure forces many application changes to be done on a quick-fix basis without sufficient thought given to the implications for the overall application architecture, often making the maintenance and operation of older applications even more costly and difficult. If the real dollar cost of maintaining an older system is not increasing annually, then one should examine whether or not all maintenance requests are being met on a timely basis. Some organizations will simply dedicate a fixed level of resources to maintaining an older system. As it becomes more difficult and time-consuming to complete maintenance tasks with the same fixed level of resources, the maintenance backlog grows. This may give the appearance of maintenance costs remaining constant, but in reality, the true cost includes the explicit cost of maintenance plus the opportunity cost of the business loss due to the backlogging of maintenance requests. The estimation and examination of the life-cycle costs of each application should be part of the organization's strategic planning process for computer systems. Every application proposal that is being reviewed should have not just an explanation of the costs associated with constructing the system, but an accurate estimate of the ongoing maintenance costs through the entire life of the application. The actual costs for supporting the application, which usually increase over time as described above, should be compared to the original estimates on a regular basis. When the actual costs begin to exceed the original estimates, it most likely is time to examine how well the application is being maintained. This article describes a successful project to improve a major business application and extend its life by applying a strategic approach to breaking out of the typical costly maintenance cycle. This approach has been previously described as a "periodic production review" by Meilir Page-Jones: "A periodic production review is like an annual medical checkup, which is followed up by your doctor's prescribing courses of treatment for any ailments that he identifies. ... Traditional maintenance means waiting for a user request for a fix or an enhancement to a system. Such requests are often irksome, because they may be hasty, ill-thought-out, badly expressed, and so limited in scope that they must be followed by further requests. ... With a periodic production review, by contrast, you in the DP department take maintenance to the users." [1] The extension of the application's life has allowed MIT to postpone the large expense and complexity of replacing it with an entirely new one. The project is an example of the processes involved in enhancing an inter-departmental application. MIT's House of Cards MIT, like most institutions, has an aging application portfolio and spends most of its application support resources on maintaining it. With the exception of three relatively small systems which use vendor packages or service bureaus, all of MIT's key administrative applications have been custom-developed. During its last fiscal year, MIT spent more than $7 million to develop and maintain these administrative applications, with 50 percent of the total spent on low- level maintenance. Many of our applications operate in the IBM mainframe environment and are more than ten years old, with original architectures dating to the 1960s. While some applications have been converted to different operating systems over the years (DOS to VS1 to VM/CMS), their underlying designs and functionality have not been significantly improved. Most maintenance on these applications is done on a tactical basis, in which individual changes are implemented one at a time with little long-range design and planning. The priority for maintenance tasks is established by the client, who responds to changes in business processes and functions. Changes to application databases (as opposed to programs) are also done primarily on a task-by-task basis. Over the last few years, MIT has decentralized the responsibility for support of over 50 percent of its administrative applications.[2] We have found that one of the risks of decentralization is the difficulty of creating and enforcing application standards. With the responsibility for applications support reporting up through different line organizations, there is a good chance that common techniques, tools, and architectures will not be utilized. Unless some type of centralized review and authority over application support is established (by the central information technology organization, for example), there is a greater risk that standards will be ignored. Not adhering to standards can exacerbate the maintenance problem described earlier. The Alumni, Donor, Development, and Schools System In 1979, MIT developed an application to track all alumni and their gifts. Through the years the system, which was designed originally to use the ADABAS(R) database management system and the PL/I programming language, was maintained and enhanced to provide additional functionality as client needs changed. The central application group performed most of this maintenance on a task-by-task basis with little overall strategic direction. During this same period, the Alumni Association also established its own small group of programmers which focused primarily on writing management reports to track data about alumni and their gifts. In addition, this group developed a number of small subsystems that used some of the data in the main system. In the mid-1980s, MIT began to formulate plans for a major capital campaign which evolved into the $550 million, five-year Campaign for the future. As part of the plans, the Resource Development department and Alumni Association increased their staffs to prepare for the campaign. By the campaign kickoff in 1987, the original alumni/gifts system had grown to become the Alumni, Donor, Development, and Schools (ADDS) system. Its purpose was to support the Alumni Association, Resource Development, the Treasurer's Office, and the development officers of the five schools at MIT (see Figure 2). [FIGURE NOT AVAILABLE IN ASCII TEXT VERSION] Although a number of enhancements and modifications were made to the system (such as writing reports using NATURAL(R), a 4th-generation language, to support campaign researchers and solicitors), the architecture, many of the programs, and much of the database structure of the ADDS system remained similar to the original system developed almost ten years earlier. At the time, Administrative Systems Development (ASD) and its client offices believed the system would last through the life of the campaign, even though it would be close to fifteen years old by then. ASD had two programmers supporting the ADDS system, with approximately two-thirds of their time spent on maintaining the online system, and one-third on programming management reports. In addition, one-half of a technical writer's time was spent supporting the system's documentation needs. With the campaign ready to begin, the ADDS system was being used by almost 200 different people in three administrative departments and five schools, with an average of sixty simultaneous users. During the most recent fiscal year the system recorded over 40,000 gifts and pledges with a total value exceeding $131 million. In addition, an average of 170 batch report jobs run against the database each week. The Problems Begin With increased use of the ADDS system following the campaign kickoff, both the clients and ASD staff began to notice problems: * Response time for both the online portion of the system and batch jobs was deteriorating. While this was partially due to the overall load on the IBM mainframe on which ADDS ran, some questions were raised about the performance of the ADDS system itself. In addition, the mainframe costs associated with running the ADDS system were increasing rapidly, and approaching $1 million annually. * The user interface and functioning of the on-line portion of the system were awkward, inconsistent, and did not adequately support the needs of the campaign workers. Menu hierarchies and screen navigation rules forced users through many different screens to enter or query information. * Many of the programs were awkward and difficult to understand for the programmers maintaining the system. Over the years, some inefficient and unstructured programs had been written that tended to be "cloned" by subsequent programmers who needed to develop a similar function or report. This practice perpetuated the inefficiencies and structural problems throughout the system. * The data structures were inefficient and in many cases did not support client business needs. Fields and keys had been added to the database as needs arose, with no overall plan for or redesign of the database. These problems raised concerns over whether the ADDS system would in fact be able to support the Campaign for the future during its remaining four years. We knew we could not implement a vendor package or develop a completely new system without major disruptions in the midst of the campaign. Even if the system did last through the end of the campaign, people thought it could not be used much longer than that if the campaign were extended beyond its original five-year duration (a common event in capital campaigns). Review of the ADDS System ADDS clients and Information Systems (MIT's central information technology organization) hired an independent consultant3 in September 1988 to review the ADDS system and make recommendations for improving it. The consultant, who had in-depth experience in ADABAS and NATURAL, spent approximately six weeks meeting with clients and ASD staff, as well as reviewing PL/I and NATURAL programs, the logical and physical design of the database, and system performance reports. The results of the study were presented to a group that included the senior officer and department head of each of the areas involved with the ADDS system. The key findings of the study, as summarized in the final report, were: * Programs and batch jobs are inefficient ... programs and jobs can be improved 10 percent to 95 percent in execution speed by more structured design and programming techniques. * Programs, jobs, and systems are difficult to understand and maintain ... there is almost no technical documentation. * The database design is inefficient ... there are an excessive number of keys to major files ... . * The user-interface of the online systems is inefficient ... . The user must traverse multiple screens to satisfy their [sic] information request where one screen would suffice ... . Online help is rarely available ... . * Finding problems and determining their cause(s) is difficult and time-consuming ... determining how often programs are run is difficult or impossible ... . There are over forty NATURAL libraries containing over 4,500 programs ... only 1,200 to 2,000 are used in production[4] The report made the following recommendations for eliminating or alleviating the system problems: * Proceed with a project (the "ADDS Efficiency Project" or AEP) to improve the systems, practices, and procedures related to the ADDS database. * Hire a full-time data administrator to manage the ADDS systems and the improvement project. * Provide training to all ADDS development personnel in structured design and programming[5] The major benefits of following the recommendations would be to improve the performance efficiency of the ADDS system, reduce or control the growth of application maintenance and support costs, and most importantly, ensure that the system would last for the duration of the Campaign for the future and beyond. The major incremental costs (beyond resources already dedicated to the support of the ADDS system) would be the cost of the data administrator and the additional resources for accomplishing the report recommendations. The Search for a Data Administrator Among the complexities of the ADDS system are that it directly supports three major departments and five school development offices, and that the technical support is provided by three different departments (see Figure 2). Because of this, governance of the system is relegated to a series of committees (see Figure 3). [FIGURE NOT AVAILABLE IN ASCII TEXT VERSION] In discussing hiring a data administrator, a consensus could not be reached regarding which organization should supervise the data administrator in a reporting relationship. In addition, the question was raised as to whether a qualified data administrator could be retained once the project was completed and a more stable operating environment achieved. We therefore decided to hire a consultant to act as the data administrator and to lead the AEP for its estimated duration of twelve months. The consultant would be funded by and would report directly to the director of ASD, with a responsibility for coordinating his or her work with the three groups that govern the ADDS system. In December 1988, a Request for Proposals was written and distributed to twelve organizations around the country. After a thorough review process, four firms were invited to MIT to present their proposals. The presentations were conducted in January 1989, and the winning firm, selected unanimously, was picked primarily because of the qualifications and reputation of the firm and of the individual proposed as data administrator, the description of the services to be provided, and the proposed cost. The winning proposal was the second lowest in cost of the four finalists. A one-year contract with the firm was negotiated and signed, and the data administrator began work in late February 1989. The ADDS Efficiency Project A project team was formed for the AEP under the direction of the data administrator. The team's members included one mid-level and two senior-level analyst programmers and one technical writer, all from ASD. The AEP team was to work closely with programming staffs from the Alumni Association and Resource Development, though the AEP team would not have direct authority over their work. All parties acknowledged that while programmers from the client departments were to be involved in the AEP, the primary focus of their work would be to continue to support the ongoing operations of the campaign. The first task of the AEP team was to review the ADDS study report and develop a project plan outlining the work to be conducted over the following twelve months. The project plan was completed and reviewed with the ADDS clients within about three weeks. The major activities of the project were divided into the analysis, redesign, and implementation of changes in three areas: the production database files, the large and frequently-run batch reports, and the online entry and inquiry screens of the system. In addition to these activities, education and training of the technical staffs supporting the system were to be addressed by the project. This was done through a variety of mechanisms: informal training sessions targeted at users about the ADDS system and its data; workshops about specific programming topics led by the data administrator and targeted at client programmers; and formal classes on various aspects of ADABAS and NATURAL programming led by an outside training firm. The AEP was scheduled to last for twelve months, through the end of February 1990. To allow for any changes that could occur during the life of the project, the schedule set the completion date for the final task approximately ten months into the project, creating a contingency overrun of two months (15 percent). Because one of the critical problems with the existing ADDS system was the lack of standards supporting its maintenance, one of the project's first activities was to establish standards for the maintenance and documentation of the ADDS system. The consulting firm selected to provide the data administrator was well-respected for its work with ADABAS and NATURAL applications, including the establishment of specific programming standards. The AEP team wisely decided early on to adopt these standards as the basis for much of the work to be done. The standards were modified and tailored to the MIT operating environment, and were published for use on all ADABAS and NATURAL systems at the Institute[6] Analysis and redesign of the database As described earlier, an overall plan for implementing changes to the database files in the ADDS system did not exist prior to the initiation of the AEP. In the past, when an office needed a field added to one of the files, it was usually added to the end of the file because this was the easiest and fastest way to make the change, and therefore met the quick turnaround time required by the clients and the workload of the database analysts. Often there was insufficient time to develop the most efficient and effective solution by conducting an analysis of the requested change and its potential impact. Requests for new keys for the file usually occurred in a similar manner, without reviewing whether existing keys could be combined or otherwise changed to meet client needs. In addition, database problems were worsened because virtually no reviews were conducted to determine whether unused or underused fields and keys could be eliminated. At no point were real attempts made to normalize the data. Compounding problems with the database itself were the numbers of new programmers and users added in the client departments over the previous few years. For the most part, both users and programmers were not provided with enough training to give them sufficient knowledge of the data and data uses to do their jobs effectively. Without a thorough understanding of the logical and physical database design, as well as adequate technical training, programmers could not structure programs to make the most effective use of the data and of machine resources. Similarly, users who did not understand the data often did not know how to accurately formulate requests for information. In evaluating current database use, the AEP team worked with the database analysts in ASD to collect information about patterns and frequency of use of the files, fields, and keys. The team analyzed usage patterns through an iterative process and reviewed this information with the clients to determine possible changes. Early in the project, we decided to combine all of the recommendations into a single major restructuring of the database with the goal of minimizing its impact on our clients. After a thorough analysis of the database, the AEP team developed a list of changes, including removing 100 fields (16 percent of the total fields in the fourteen affected files) and 101 keys (41 percent of the total keys in those files). These changes were scheduled for implementation in the summer, after clients concluded processing to close the fiscal year. Analysis and reprogramming of batch report jobs The ADDS system was used primarily (as measured by consumption of computer resources) to produce various types of reports for management, researchers, and fund-raisers in the client offices. The most pressing problem was that jobs were taking too long to run, even during overnight batch processing. All jobs that needed to be run in one shift could not be completed in a single shift. The AEP team examined the report programs to determine if they could be made more efficient. This task was difficult, because there were literally thousands of programs in scores of libraries. The team identified key tactical improvements that could be made to selected programs, using a performance monitoring tool to analyze the performance of jobs run against the ADDS database, and their resource utilization as measured by physical input/output calls and database transactions. To track which jobs were using the most resources and were run most frequently, the team created a weekly list of the most resource-intensive jobs. Once these key jobs were identified, the data administrator met with the programmer responsible for each job. They examined the programs, and suggested and tested methods of improving their performance. The revised programs were then tested to measure their resource usage. The results showed that some of the most resource- intensive jobs could be reduced by up to 90 percent in both run time and resource utilization. Since many of these report programs had been cloned, fixing one program often led to changes that could be made quickly to others. Analysis and redesign of the online system The largest and most complex activity in the project was the analysis, redesign, and reprogramming of the online portions of the system. The major portions of the online system consisted of approximately 230 PL/I programs that were ten years old. These programs were divided into two main subsystems: BioEntry, used for the entry and display of biographical information about alumni, and GiftEntry, used for recording and querying gifts and pledges made by alumni and others. Both subsystems were largely undocumented and often did not follow good software engineering techniques, resulting in difficult and expensive maintenance. A relatively simple request to change the layout of a screen became a major endeavor. In addition, because user interface standards were not followed, inconsistencies in screen navigation rules and function key definitions existed. Since the scope of the project was primarily to improve the performance and efficiency of the ADDS system, the project team did not set out initially to make major enhancements to system functionality. One of the first decisions made by the team was to discard the PL/I programs in their entirety and reprogram the screens in NATURAL. Prototyping and testing demonstrated that existing programs could be replaced with NATURAL programs without any response-time slowdown (and in fact some improvement). Previous experiences had shown that the time required to write and implement programs in NATURAL was much less than for equivalent PL/I programs. The AEP team began with the premise that it would simply duplicate the existing data entry and query screens by reprogramming them in NATURAL. During prototyping, however, they received many suggestions from users for improving the functionality of the screen navigation and function key usage. During the iterative prototyping, the team determined that it could accommodate the requests of the users without delaying the project schedule. Thus, they decided to incorporate the requests for new functionality as long as the original schedule for reprogramming of the online systems could be maintained. As described above, the existing ADDS system contained two main online subsystems. The original plan was to maintain the structure of two separate subsystems, with the reprogrammed GiftEntry subsystem put into production in August and the new BioEntry implemented in September. Prototyping helped us discover that the two could be combined into one subsystem to support both biographical and gift data entry and query functions. The combined subsystem would minimize the effort spent on reprogramming the screens and also would simplify future maintenance. The project team continued the iterative prototyping of the screens, taking into account the functionality improvements requested by users. A major revision to the technical and user documentation of the BioEntry and GiftEntry systems was done concurrently with the reprogramming effort. Once design specifics were well-established, programming of the screens began. The existing 230 PL/I programs were replaced with 90 NATURAL programs. When the target dates for implementing the new subsystems were delayed until October, it became apparent that these changes and the scheduled implementation of database changes were likely to occur approximately one month apart. Because the system would have to be closed down for a period of time for the production conversion of the screens and the database files, the AEP team and clients opted to implement both the database and online subsystem changes in one conversion. While a combined conversion would be more complex, one shutdown period for the clients rather than two was a more important consideration. Evaluation of the Project The conversion of the database files and on-line subsystems and the reprogramming of batch jobs was completed by November 1989, on schedule. We are still evaluating the performance improvements of the new database structure and online programs. Some of the improvements we have already noted include: * a 25-percent reduction in disk storage for the fourteen files affected by the database changes; * an improvement in response time for both on-line functions and batch report jobs; and * a large degree of user satisfaction with the simpler screen navigation and function keys in the new online subsystem, leading to increases in user productivity. The improvements have led to increases in the productivity of the data entry effort and inquiry capabilities of the system. A recent independent review of the project by MIT's internal auditors reported the following efficiency gains as a result of the AEP: * an approximate 14-percent reduction in database CPU time; * an approximate 22-percent reduction in input/output processing; and * an increase in online use of the system by users due to its improved utility. The audit report concluded: "Our analysis of the available statistics indicates that both computer processing time and ADDS computational charges [costs] have decreased relative to the volume of business activity ... . Our analysis supports the assertion that efficiencies have been achieved as a result of the AEP."[7] The report noted that the reduction in resource use occurred during a time that the business volumes (number of gifts processed, number of reports produced, etc.) in the ADDS system actually increased. Online and batch response times are a factor of both the individual application and the overall load on the computer. Inefficient applications independent of ADDS could slow ADDS response time. Thus, this factor has to be evaluated in examining the long-term response-time performance of the ADDS system. The data administrator completed his work in the first week of January 1990, and the final report and recommendations for the project were issued shortly thereafter -- all about two months earlier than the original twelve-month schedule. Explicit project costs were summarized as follows: Contract with consulting firm for data administrator $147,600 Programming staff from ASD (valued at $54/hour) $207,000 Technical writers from ASD (valued at $41/hour)[8] $31,000 Total $385,600 If the ADDS Efficiency Project had not been undertaken, the budget for the regular maintenance of the ADDS system for the ten months of project duration would have been $143,600. The incremental cost for the AEP, therefore, was approximately $242,000. The total does not include costs associated with time spent by the programmers in client offices for work done on enhancing client subsystems and batch jobs. While these costs were not tracked separately, they are believed to have totaled the equivalent of less than one full-time programmer since none of the clients added additional staff exclusively for this effort. The programming staffs of both the Alumni Association and Resource Development were able to continue to meet the operating needs of the campaign during the entire project. While the quantitative benefits of this project are still being calculated, we do know that the following results have been achieved: * The AEP extended the useful life of the ADDS system, ensuring it can continue to meet the needs of the campaign workers and allow us to avoid the major disruption in campaign operations that would have resulted from implementing a new fund-raising application. The project has also let us postpone the costs of implementing a new system which, given the experience of other universities, would be in excess of $1 million. * Current estimates are that the programming resources necessary for maintaining the on-line portion of the ADDS system in NATURAL will be half of what was necessary for PL/I program maintenance, a savings of approximately $55,000 annually. In addition, programmers joining the project will be productive more quickly because of the fourth-generation language and structured techniques now used in the system. * The functionality and user interface of the system have been vastly improved; users have already acknowledged this change and its positive impact on data entry and inquiry productivity. This improvement can lead to benefits such as reductions in the need for overtime for data entry during peak periods, increased accuracy of the data entry process, and more timely recording of gifts. * Improvements of up to 90 percent in resource utilization and run time of batch report jobs have been noted, and initial indications after the conversion are that online response time has improved also. As the single largest application on the mainframe, this is an important factor. Controlling the growth rate of use of the ADDS system will let MIT postpone the point at which its IBM 3090 computer will have to be upgraded to a more powerful model. Another advantage gained through the implementation of the AEP was that it demonstrated the value of having centralized coordination of all changes to the ADDS programs and database files. One of the recommendations of the data administrator's final report was that MIT should appoint a permanent data administrator to: "... look for gaps where everyone else says, 'not my job,' and ... act as a catalyst for needed action ... propose efficiency improvements to programs... coordinate all changes to the production database files, coordinate all changes to the Bio/GiftEntry programs, coordinate the interconnection of NATURAL applications to the database files and Bio/GiftEntry system. This will be a demanding job, requiring tact, technical competence, aggressive advocacy, and patience, not necessarily in that order ..." [9] We believe that this effort will help us avoid the problems encountered previously with the ADDS system and ensure its structural and functional integrity in the future. Similarly, the final report emphasized the importance of continuing to follow programming and other standards adopted by and used during the project. Our decision to apply a strategic approach to enhancing the ADDS system was a wise one. By extending the life of the system and postponing the capital expense of replacing it, we have made resources available to address priorities in other areas. Other aging applications at MIT are currently being examined to determine whether a similar strategic approach towards enhancing them can yield equivalent or even greater benefits. The knowledge gained by the MIT staff during this project will let us undertake similar efforts without the need for outside consulting assistance, allowing us to reduce the costs of future projects and further improve cost/benefit ratios. Nothing about this project was unique to MIT; similar projects can be equally successful at other institutions. But it takes management and vision enough to step back from the "business as usual" approach to application maintenance, and an examination of opportunities for new ways to revitalize aging applications. ************************************************************************ For further reading: Martin, James. An Information Systems Manifesto. Englewood Cliffs, N.J.: Prentice-Hall, Inc., 1984. ======================================================================== 1 Meilir Page-Jones, Practical Project Management (New York: Dorset House Publishing Co., Inc., 1985), p. 137. 2 For more on how MIT has decentralized application support, see Mary Ellen Bushnell and Donald E. Heller, "Application Development Services in a Competitive Environment," CAUSE/EFFECT, Fall 1989, p. 33. 3 The names of the consulting firms used in this project are not provided here to avoid any appearance of an endorsement by MIT; this should not be construed, however, as a comment on their performance. More information is available from the author. 4 "Management Report: MIT ADDS Database Systems Efficiency Evaluation," internal MIT report, October 1988, pp. 6-8. 5 Ibid., p. 12. 4 Management Report: MIT ADDS Database Systems Efficiency Evaluation, MIT internal report, October 1988, pp. 6-8. 5 Ibid., p. 12. 6 MIT Information Systems, Administrative Systems Development ADABAS/ NATURAL Standards and Procedures, MIT internal publication, 1989. 7 Efficiency Analysis of Alumni Donor Development Schools System, MIT internal report, May 1990, pp. 1-3. 8 The rates shown for internal programmers and technical writers are based on the standard rates charged by ASD to its internal clients. These rates are fully-loaded, i.e., they include salary, employee benefits, share of management time, equipment costs, facilities costs, etc. 9 ADDS Efficiency Project Final Report, MIT internal report, January 1990, p. 8. ======================================================================== ADABAS(R) and NATURAL(R) are registered trademarks of Software AG of North America, Inc., Reston, VA. ************************************************************************