Method for Planning Administrative Information Systems Development Copyright 1990 CAUSE From _CAUSE/EFFECT_ Volume 13, Number 3, Fall 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 METHOD FOR PLANNING ADMINISTRATIVE INFORMATION SYSTEMS DEVELOPMENT by Dale Bent and William Enright ************************************************************************ Dale Bent is Assistant Vice President for Academic Services at the University of Western Ontario in London, Ontario, where he is responsible for computing for teaching, research, and administration, data and voice communications, libraries, graphics and art, and photography services. He was formerly with the University of Alberta, Edmonton, where he was Professor of Business Administration, specializing in management science, and Director of Computing Services. He is co-author of Statistical Package for the Social Sciences (SPSS), a widely used computer system for statistics and data analysis. William Enright is Director of the Department of Administrative Systems at the University of Western Ontario, where he is responsible for systems development and maintenance, data administration, office automation, and information services for administrative users across the University. He is in his thirty-fourth year in the information systems field, and has been active in Guide, ASM, DPMA, and other professional organizations. ************************************************************************ ABSTRACT: This article describes the situation faced by colleges and universities in general, and the University of Western Ontario in particular, in planning the development of administrative information systems. A methodology to assist decision-making with respect to the relative priorities of alternative (competing) projects has been developed at Western, was applied for the first time in the 1989-90 fiscal year, and is being continued for the 1990-91 fiscal year. The methodology is designed to identify the principal options for information systems development, and to permit the application of executive judgment as to the strategic importance of competing projects. The methodology itself and the rationale for its adoption are described. Experience to date, including problems encountered and their resolution, is also summarized. Planning the development of information systems is a challenging matter in most complex organizations. Colleges and universities are no exception, experiencing a number of common difficulties. * Rapidly evolving technology changes both the nature of the work to be performed and the tools available to do the work. * The growth of decentralized computing using microcomputers and local-area networks creates rising client expectations and multiplies technical considerations. * The proliferation of client demands as computer applications increase both in number and importance points to the need for an overall strategy and a need to involve more persons in the decision-making process. * A backlog of unfinished work creates frustration in client departments. In addition to such commonly experienced difficulties, the organization of administrative processes in higher education institutions presents some special obstacles and considerations. * Administrative processes, and the information systems to support them, are regarded as overhead activities of secondary importance on most campuses, where the primary activities are teaching, research, and direct public service. * Funding is tightly constrained in higher eduction and therefore new funds for administrative information systems are hard to obtain. * Increasing demands for administrative productivity have been experienced with record enrollments, demands for new services, and requirements for information for government-mandated programs. * Participative decision-making is required, due to tradition and the accountability of the institution administration to a legislative- style decision-making system, and particularly in view of the fact that the clients served by information systems are academic departments and students. An important and simplifying factor in administrative information systems (AIS) development in colleges and universities is that many (not all) of the important information systems are fairly stable in purpose and have, in one way or another, been in operation for many years. The major administrative information systems on most campuses include: student admissions, registration, and record-keeping; financial accounting and budgeting; purchasing and physical asset management; personnel administration; fund-raising and alumni records; and physical plant systems. The technical means for development of computerized administrative information systems at the University of Western Ontario is modern and typical of the mainstream. Information systems projects are initiated with a request to the Department of Administrative Systems (DAS), which uses the PRIDE methodology for capturing the information necessary to plan a project.[1] Project committees are formed for major projects to manage the phases of development. In most cases, information systems are developed in-house: although Western attempts to evaluate software available from external sources, we have usually found that already- developed and available software is either unsuitable or deficient, or that in-house development is cheaper or more practical. Western uses IBM computers, the MVS/XA operating system, and the Computer Associates IDMS/R database management software for major information systems. We use a variety of fairly standard means of connecting administrative workstations to the mainframe administrative computer. Most administrative offices now employ microcomputers using the MS-DOS operating system. Uploading and downloading of administrative data to microcomputers is facilitated with Computer Associates' Infogate/Goldengate software and the Kermit software. A catalog of administrative databases is maintained and aided by use of the dictionary capabilities of IDMS/R. These data are regarded as a corporate asset; procedures have been put into place to facilitate and control the use of "corporate" data throughout the University. Determining a Strategy Despite the use of the foregoing resources and methods, Western, like many universities, found itself in increasing difficulties in carrying out systems development in the mid-1980s. Many of our information systems were in need of re-development. Administrative systems staff had to be reduced, in view of the "steady state" budget situation, to pay for adequate hardware and software to run the re- developed information systems and to handle the amounts of data and increasing degree of online access required for administrative operations. New administrative computer applications were being requested, in addition to an already-existing backlog of systems development work (amounting to approximately three years for a systems development staff of twenty positions). In fact, many worthwhile projects had simply been "put on the back burner" awaiting sufficient resources. The Vice President for Administration foresaw that senior executive action was needed to break the logjam. If all worthwhile administrative computing could not be accommodated, there was a need to concentrate resources on the development and maintenance of those information systems which were critical and/or most strategically important. Because of the complexity and scope of the information systems work which could be undertaken, it was difficult to identify the major decisions which were needed, let alone foresee all of the implications for the departments affected. Simplification was needed as a basis for decision- making. A major consideration was the need to involve senior levels of the administration in decisions regarding AIS development. The reasons were: first, the expense of development of information systems was forcing financial trade-offs which would affect all areas of the administration, and second, the information systems would have a major effect on most areas of administrative operations and therefore needed to be coordinated with general administrative planning. We recognized that decisions should not be made, or forced, by DAS. It was not considered fair, or appropriate, to expect this department to single-handedly provide technological leadership, accept responsibility for development of information systems, and make decisions as to the priority and timing of new projects. Especially in the emerging technical environment of distributed computers, these decisions needed to be a result of collective planning throughout the administration. A classical response in many universities to some of the above difficulties has been the introduction of "hard dollar" chargeback. The basic rationale for this has been to provide a simplified planning concept for the AIS department, i.e., provide whatever clients request and can pay for. It also has the effect of putting the onus on the client departments to obtain resources for information systems. However, this approach has been rejected at Western for the following reasons: first, it would not generate more money in total for administrative computing, and second, it would reduce the flexibility of the administration to move information systems resources to the most strategically important or critical projects -- which could very well change quickly according to circumstances. Western decided to put into place an administrative structure to meet the following objectives: * Involve the senior levels of administration in decisions relating to administrative information systems. Accordingly, the Priorities and Planning Committee for Administrative Information Systems (PPCAIS) was set up, chaired by the vice president for administration and consisting of all assistant vice presidents as well as the administrative systems director. Two academic deans are also members of this committee. PPCAIS has become the vehicle whereby major AIS decisions are taken. * Involve appropriate staff throughout the administration in matters relating to information systems development. An advisory subcommittee, the Advisory Committee for Administrative Information Systems (ACAIS), was established, consisting of the directors of most administrative departments and representatives of all academic faculties -- the "end users" for many kinds of administrative information services. ACAIS is consulted with respect to all major policies and procedures regarding AIS. In addition, a number of special study groups and task forces with technical expertise have been set up to consider certain matters, especially in connection with the initiative for office automation which was launched in the fall of 1988. Choosing a Methodology The next step was to conduct a search for methods which would facilitate planning and decision-making for major information systems development projects. After consulting with several vendors, companies, and other universities, we concluded that many large organizations, despite investments of millions in information systems "development methodologies," generally "muddle through" where the big decisions are concerned. We recognized that tools and methodologies such as PRIDE could not help in this regard, even though they are useful, if not essential, once a project has been decided upon. Although "politics" can never be eliminated where major financial decisions are concerned, we hoped to establish a method which would reduce the complexity of choosing among dozens of competing projects, as well as a way of conceptualizing the decisions to be made. Many authors advocate the application of information systems resources to the most strategically important projects, that is, the projects which most directly support the "strategic" goals of the institution. This is undoubtedly a good concept, but like many universities, Western did not have a clear or explicit plan, strategy, or set of goals of direct use in trying to decide which information systems projects should have priority. We decided to apply some methods described in Eugene F. Bedell's book, _The Computer Solution: Strategies for Success in the Information Age_.[2] The methods advocated in this book appeared to address the major concerns described above. Although these methods have been successfully applied in a few large corporations, they are not well- known, nor to our knowledge have they been applied, in universities. Therefore we were breaking new ground in this endeavour. The remainder of this article is devoted to describing in detail the method which we have adopted. The method has some points in common with classical "cost-benefit analysis," but allows a considerable degree of collective executive judgment to be applied. Like any workable decision tool, it is used as a guide, not the last word, in the decisions we make regarding computerized AIS development at Western. Preliminary Steps The first major task undertaken by PPCAIS was a review of the backlog of information systems development work. This was completed in 1987 and used to set the agenda for information systems development projects in 1988-89. In the planning for FY88-89, departments were asked to comment on their information systems development plans, and in the planning for FY89-90, administrative departments and participating academic faculties were asked to include plans for office automation.[3] These plans were collected and provided to PPCAIS for information. Of course, departmental AIS plans are usually developed with the involvement of DAS. In this way DAS has advance notice of client department requirements to prepare its own plans and recommendations, which are also reviewed by PPCAIS. Previously, information systems development work was organized into projects and each project had in turn phases which are the necessary steps in the execution of a project of this nature: preliminary feasibility studies and definition, systems analysis and design, database design, programming, implementation, and maintenance. In the summer of 1987, DAS undertook to review and cull the entire backlog of project work in order to provide PPCAIS with current information. About 100 subprojects (phases) were identified. For each subproject a brief description was prepared, and manpower requirements in man-hours were estimated. Fortunately, Western has enough experience with project planning methodology that manpower estimates are now considered quite reliable. This information, however, proved to be too detailed for PPCAIS to identify the major decision points and trade- offs, so DAS was requested to prepare consolidated "work chunks" -- the goal was to identify twenty to thirty major items of work which could be considered by the general administration. A "work chunk" proved to consist of about two to three man-years of development work -- systems analysis and programming. Based on this information, the work plan for 1988-89 was approved. At the same time, the decision was made to apply the methodology described below in the summer and fall of 1988 to produce the plan for 1989-90. Bedell's Methodology Applied Bedell's methods are based on a principle that "information systems strategies affect the entire organization and cannot be imposed on the organization from below by the information systems manager or by users. Senior management must take control and drive the strategies from its leadership position."[4] Indices are developed to allow the establishment of a model to guide senior management in setting priorities for systems development projects. These indices include: * IAU Index -- Importance of an Activity to the University, * ISA Index -- Importance of a System to an Activity, and * ESA Index -- Effectiveness of a System to an Activity. Using these indices, two additional indices are calculated: * ISU Index -- Importance of a System to the University, and * Change in Effectiveness Resulting from the Installation of a System. Identification and Importance of University Activities The basic concept of the Bedell methodology is that of an activity. An activity is a major function of the university. To understand the importance of alternative information systems to the university, it is necessary to determine first which activity an information system supports, and second how important that activity is to the university (IAU Index). Examples of activities are: recruiting and registration of students, paying staff, financial accounting, and budgeting. It is not necessary to maintain an exhaustive list of all campus activities. Only those activities for which information systems development is proposed need be identified in a given planning cycle. In our first consideration of activities, a list of the principal functions of administrative departments was prepared. Generally speaking, single identifiable departments are the focus of a given activity, that is, a single department usually has the prime responsibility for coordinating and/or carrying out the activity. For each activity so identified, each member of PPCAIS was asked to prepare a subjective estimate of the importance of the activity to the University, using a scale of 0 to 10, as shown in Table 1. [TABLE NOT AVAILABLE IN ASCII TEXT VERISON] The administrative officers applying these ratings must understand the institution's long-term goals, understand the objectives to be accomplished by each activity, and know how accomplishing the objectives will contribute to the achievement of those long-term goals. For their judgements to be valid for the institution as a whole, it is important that the administrative officers be positioned to make these judgements. PPCAIS seems appropriately constituted for this purpose. The scores assigned by the members of PPCAIS were clustered and discussed by the group. The officers were asked to revise their estimates. Based upon the revised scores, a composite score representing the central tendency of all the scores was determined for each activity. It is noteworthy that the officers reached a fairly consistent set of scores for the various activities. The discussions of the officers in compiling this scale were interesting and yielded insights into the importance of the various activities at Western. This suggests that the process has team-building value, quite independent of the application of the IAU scale to information systems decisions. We should candidly recognize that it is difficult for any employee or officer to voice judgements about the importance of major campus-wide activities (particularly outside one's domain of responsibility), and this process is fraught with political, organizational, and interpersonal overtones. This is especially true when carried through for the first time. It was possible at Western because the members of the PPCAIS are officers who routinely work closely together, and because the scores assigned by individuals have been kept confidential to this group. Our plan is that each year the IAU scale will be revised, as necessary, as a first step in the annual planning cycle. We expect that this IAU scale will probably not change significantly from year to year, once established. It is possible that the IAU scale can be applied in other decision-making situations at the University as the officers gain familiarity and comfort with its use. Definition of Projects and Systems The second important concept in our methodology is that of a computerized information system (or system for short). Each proposed project over the period for which decisions are made (fiscal years, at Western) leads to the establishment of a computerized information system. In other words, a project produces a system. The task of the decision-makers is to choose among projects which compete for resources or, equivalently, to set priorities for the acquisition of systems. Each proposed project is given a descriptive title, a short description in non-technical language, and an estimate of manpower requirements and cost. We have calculated manpower requirements in man- hours, and costs are obtained by multiplying man-hours by $40 -- an estimate of the cost per hour of a programmer-analyst. The decision- makers will choose from the list of projects. An example of a project description is shown in Table 2. [TABLE NOT AVAILABLE IN ASCII TEXT VERSION] At Western, departments are permitted to "buy" project manpower from DAS at the rate of $40 per hour. In the past, this has been done routinely for smaller projects and for "ancillary" (cost-recovery) departments. A decision available to PPCAIS is which departments will be required to "buy in" if they wish a project to be undertaken or to raise the priority of their requested work. This allows departments that do not receive priority but believe their project will provide substantial benefits or is of sufficient importance to their department to "trade off" their operating funds to achieve their systems development objectives sooner. Evaluating Importance and Effectiveness of Systems It is assumed that each system will support a unique activity. If a system supports more than one activity, this does not invalidate the methodology, but the estimate of how important a system is to an activity (ISA Index) needs to be revised. Alternatively, the definition of a system and/or the activity which it supports can be revised so that the system supports a unique activity. To estimate the importance of a system to the activity it supports, the ISA Index is prepared, as shown in Table 3. Originally, DAS expected to prepare this index in consultation with the client department requesting the project; however, we found that client department staff tend to overestimate the importance of systems development proposals. To date, estimates prepared by PPCAIS are being used. In subsequent decision cycles, a greater effort to involve client department staff in assigning ISA scores is desirable. In order for this exercise to be productive, however, more clarity regarding the definition of activities will be required from senior decision-makers. [TABLE NOT AVAILABLE IN ASCII TEXT VERSION] To estimate the importance of a system to the University, we multiply the IAU and the ISA indices. The resulting index, which we call the ISU Index, is a value on a scale of 0 to 100. Both the IAU and ISA indices are ordinal scales -- subjective estimates of the kind familiar to social researchers. We are aware that from a methodological point of view, the multiplication of ordinal indices is questionable. We have adopted this technique for the pragmatic reasons that the procedure is simple, that it separates the construction of the ISU Index into two steps involving estimates of two quite different yet important factors, and that it appears to work well enough for our purposes. The final index to be compiled is an estimate of how effectively a computerized information system supports an activity (ESA Index) both before and after its development. The ESA Index is compiled on a scale of 0 to 10 as shown in Table 4. This index is compiled by DAS in consultation with client department representatives proposing the system. [TABLES NOT AVAILABLE IN ASCII TEXT VERSION] To estimate the contribution to overall effectiveness resulting from installation of a given system (i.e., after completion of a project), we weight the change in the ESA Index with the ISU Index (Importance of the System to the University). The two values are multiplied together: Change in Total Effectiveness Resulting from Installation of a System = ( ESA(New) - ESA(Old)) X ISU = (ESA(New) - ESA(Old) ) X IAU X ISA. The resulting effectiveness index is on a scale from 0 to 1,000. It can be divided by the largest value and multiplied by an arbitrary number (normalized) to facilitate comparison. We rank-order the resulting numbers to facilitate consideration by decision-makers. A final step can be taken to introduce a measure of cost- effectiveness for each project. This is obtained by dividing the index of increase in effectiveness by the estimated cost for the project to produce the system. Given the direct relationship between cost and man- hours at Western, we can equivalently divide by man-hours. For convenience, the resulting numbers can be normalized to obtain a Cost- Effectiveness Index. We rank-order the resulting numbers in order to facilitate consideration by decision-makers. Use of the Indices The indices resulting from our methodology are used as a guide to decision-making. The decision-makers must consider how many projects can be undertaken in a given planning period, any logical inter-dependencies among the projects, timing, and any other factors relating to planning outside the scope of this methodology. Using manpower estimates as a surrogate for costs, and assuming that the pool of manpower is known in a given planning period, the projects must be fitted into the agenda for the manpower available. Once priorities have been assigned, the projects can be listed in priority order, and cumulative manpower calculated. In this way, the amount of work that can be accomplished in the following planning period can be readily identified. We consider that a programmer-analyst can produce approximately 1,000 hours of project work in a year, taking into account training time, vacation, average sick time, and other activities which cannot be assigned to projects. Each project can be viewed as a "rectangle" which can be stretched out or shortened according to the number of analysts assigned to the work. The height of the rectangle is proportional to the number of analysts assigned, and the area is proportional to the size of the project measured in man-hours. This, of course, is a standard way of planning manpower assignments. We are now in our third cycle of using our method for planning AIS development. Assessment of our success after the first cycle of use identified that the quality of information coming to PPCAIS needed to be improved. As a result, we have developed a Fast Overall Project Design Process that involves our systems managers earlier in the project proposal process. This process sets out client and DAS management responsibilities. Client management is required to have sufficient knowledge of the project to define what the business problem is and to identify the major benefits of the project, the priorities of the tasks that will be undertaken, and what further management action is required. DAS management coordinates the preparation of the project definition/description by reviewing the request for completeness, reviewing existing systems, writing a short narrative of the requested development, arranging a meeting with client management to verify the extent of the new development, creating a rough design of the system, and preparing an order-of-magnitude estimate. We experienced a tremendous increase in the overall comfort level with the information coming to PPCAIS when projects were thus being assessed. The order-of-magnitude estimates were greatly improved and led to a policy that if the order-of-magnitude estimates vary + or - 20 percent for a given project, the project is reviewed by PPCAIS. Also, the timing of the project is open for review, particularly any project more than a year old. The process also ensures that proposed changes are properly described from a cost/benefit viewpoint and are not "add ons" identified in the systems design stage. Conclusions We feel we have gained enough experience to allow us to more closely tune the establishment of indices to reflect the characteristics of individual projects. We began to understand that we needed a deeper understanding of the activities supported by an information system in order to correctly assess the IAU value. We therefore requested clear statements of the activity supported by each project, rather than asking PPCAIS to infer this. PPCAIS will develop an IAU Index, and the clients and DAS will jointly establish the ISA and ESA indices for each project. We expect this change will result in more judgment being applied to the assessment criteria for each of the indices. Essentially, we are beginning to mature in the use of our methodology through a learning process. As a measure of success, PPCAIS members have expressed strong support for the methodology and feel comfortable in their ability to realistically evaluate and set priorities for systems development work they previously had difficulty in understanding. The methodology is well known by our clients who realize they must conform to a process that senior management has endorsed to assist them in setting priorities for strategically important work. Our implementation of the methodology has received considerable interest from other institutions who are faced with the same problems. The modifications we made to incorporate the Fast Overall Project Design Process have resulted in PPCAIS deciding not to consider project proposals unless this process has been followed. Overall, senior management at Western has a better understanding of systems development activities, costs/benefits, and the associated priorities. We believe this understanding could only have been accomplished through a methodology that is simple and easy to understand and apply. ======================================================================== Footnotes 1 PRIDE is a structured systems development methodology from M. Bryce & Associates of Tarpon Springs, Florida. Western has used PRIDE since 1976. Though we have modified the methodology to satisfy Wes-tern's requirements, we nonetheless follow the basic concepts throughout the nine phases of the methodology. Those basic concepts are: systems structure, project management, data management, documentation/communications, and methodology. The methodology provides planning, control, and direction to the systems effort. 2 Eugene F. Bedell, The Computer Solution: Strategies for Success in the Information Age (Homewood, Ill.: Dow Jones-Irwin, 1985). 3 Western uses an annual planning cycle. Each year, instructions are issued, and in the last quarter of the year, each department submits a plan for the following fiscal year (May through April). Every three years, each department submits a three-year plan, which is thoroughly reviewed by the Senate Committee on University Planning. The annual plans provide an update to the three-year plan and are accompanied by budget requests. 4 Bedell, p. 15. ========================================================================